Is the deadline the problem — or the capacity behind it?

A critical activity is five days behind schedule.

The sponsor asks the project manager to recover the lost time.

The team responds:

“We cannot go any faster. The same specialist is assigned to several activities.”

At first glance, this looks like a schedule problem.

But the schedule may only be showing the symptom.

The underlying cause may be insufficient capacity, unavailable expertise, unrealistic planning assumptions, or something else entirely.

That creates the real PMP® reasoning question:

Is the schedule itself the problem — or is the schedule revealing a constraint somewhere else?

A useful Project Reasoning Lab principle is:

Do not manage the date before understanding what is driving the date.

---

1. Start With the Symptom — Then Find the Cause

A schedule problem appears when actual or forecast performance threatens planned timing.

Examples include:

• an activity starts late,
• a milestone is forecast to slip,
• critical-path work is delayed,
• float is being consumed,
• the forecast completion date moves beyond the target.

But these are often effects.

A late activity tells the PM that something is wrong.

It does not automatically explain why.

Possible causes may include:

• insufficient capacity,
• unavailable skills,
• underestimated duration,
• dependency failure,
• rework,
• scope change,
• technical problems,
• delayed approvals,
• procurement issues,
• unrealistic sequencing.

So:

A schedule problem shows where timing is under pressure. Diagnosis determines what is creating that pressure.

---

2. What Is a Resource Constraint?

A resource constraint occurs when the people, equipment, facilities, materials, or other capacity needed to perform work are not available when required.

Examples include:

• several activities require one specialist at the same time,
• a key engineer is available only part-time,
• equipment is shared across projects,
• too few qualified people are available,
• a critical skill is unavailable during a key period.

The distinction is:

The schedule tells you when work needs to happen. Resource capacity helps determine whether that timing is feasible.

---

3. Resource Availability Is Not the Same as Resource Capability

Suppose five people are available.

Does that mean the activity has enough capacity?

Not necessarily.

If only one person has the required certification, authority, experience, or technical expertise, then the true constraint may be capability, not headcount.

This matters because:

More available people do not help if they cannot perform the required work.

So before concluding that the project needs “more resources,” ask:

• Are the right skills available?
• Can the work be divided?
• Does the activity depend on specialist knowledge?
• Is approval authority concentrated in one person?
• Can substitutes perform the work effectively?

A useful distinction is:

Capacity is about how much work can be performed. Capability is about whether the available resources can perform the right work.

---

4. A Schedule Can Be Logically Possible but Resource-Infeasible

Consider two activities.

Activity A

Requires the same specialist Monday through Wednesday.

Activity B

Also requires that specialist Monday through Wednesday.

The network logic may allow both activities to occur in parallel.

But there is only one specialist.

The schedule is therefore logically possible from a dependency perspective but impossible from a resource perspective.

A logically possible schedule is not necessarily a resource-feasible schedule.

Moving bars on a schedule does not create capacity.

---

5. Resource Leveling vs. Resource Smoothing

Two common ways to address resource pressure are resource leveling and resource smoothing.

Resource Leveling

Resource leveling adjusts the schedule to reflect resource availability or limits.

It may change:

• start dates,
• finish dates,
• sequencing,
• the critical path,
• project duration.

If one engineer cannot perform two activities simultaneously, one may need to be moved.

Resource Smoothing

Resource smoothing uses available float to reduce resource conflicts while preserving the critical path and project finish date.

For example:

Activity B needs the same specialist as Activity A but has five days of total float.

Activity B may be shifted by three days.

The conflict disappears without necessarily moving the project finish date.

The distinction is:

Leveling may change the schedule to match available capacity. Smoothing uses existing schedule flexibility to resolve the conflict.

---

6. Float Can Absorb Some Resource Conflicts

Suppose:

• two activities need the same analyst,
• Activity A is more time-sensitive,
• Activity B has four days of total float.

If Activity B moves by two days, the resource conflict may disappear.

The project completion date may remain unchanged.

But two days of float have now been consumed.

That means:

• less flexibility remains,
• future delays become harder to absorb,
• the path may become near-critical,
• schedule risk may increase.

So:

Float can absorb a resource conflict without making the constraint irrelevant.

---

7. When the Constraint Hits the Critical Path

Now consider:

A resource-constrained activity is on the critical path and has no usable float.

Moving it may move the project finish date.

At that point, the PM should evaluate what can actually change.

Possible options may include:

• obtaining additional qualified capacity,
• reassigning resources,
• reducing competing demands,
• changing sequencing,
• overlapping feasible work,
• using schedule compression where appropriate,
• changing the plan through the proper process.

The key point is:

A critical-path resource problem cannot be solved merely by changing the date on the schedule.

The PM must address the resource, the work structure, or the plan itself.

---

8. Is the Problem Capacity — or an Unrealistic Plan?

Sometimes there is no unexpected resource shortage.

The schedule may have assumed more output than the available capacity could ever support.

Suppose:

A team can sustainably complete 10 units per week, but the project plan requires 18.

Calling this a resource shortage may be misleading.

The team may have had exactly the capacity known from the beginning.

The problem may be the planning assumption.

So ask:

Is capacity unexpectedly unavailable—or was the schedule never feasible with the capacity that existed?

This is a crucial distinction.

Extending the deadline may sometimes be necessary.

But it should follow diagnosis, not replace it.

---

9. Adding Resources Helps Only When Capacity Is Truly the Constraint

A project is late.

Should the PM add people?

Not automatically.

Additional capacity helps only when:

• capacity is genuinely limiting throughput,
• qualified resources exist,
• the work can be divided,
• onboarding will not consume more time than it saves,
• coordination overhead remains manageable.

Consider:

A critical testing activity needs three qualified technicians. Only two are assigned, and another experienced technician is immediately available.

Adding the third technician may reduce duration.

Now compare:

A review can only be completed by one certified specialist.

Adding three unqualified people will not help.

So:

More resources solve a capacity problem only when additional qualified capacity can actually accelerate the work.

---

10. Before Changing Resources, Confirm Capacity Is Actually Limiting Throughput

A late activity does not automatically mean:

• the team is understaffed,
• the team is underperforming,
• the deadline is unrealistic.

The real issue may be:

• unclear requirements,
• repeated rework,
• delayed decisions,
• unresolved approvals,
• external dependencies,
• poor sequencing,
• technical uncertainty.

Before changing the resource plan, ask:

Is capacity genuinely preventing more work from being completed?

If not, changing resources may solve the wrong problem.

---

11. Schedule Compression Comes After Diagnosis

Fast tracking and crashing may help recover schedule time.

But they should not be automatic responses.

If the real problem is:

• an unavailable specialist,
• unresolved approvals,
• excessive rework,
• unclear requirements,

then schedule compression may not address the root cause.

A better sequence is:

Diagnose first. Compress only if compression fits the actual constraint.

This connects directly with our Fast Tracking vs. Crashing article.

---

12. Resource Decisions Can Change the Schedule

Suppose resource leveling moves one activity to resolve an over-allocation.

That may:

• consume float,
• alter sequencing,
• change the critical path,
• extend project duration.

So:

A resource decision can become a schedule decision.

After significant resource changes, the schedule should be recalculated.

Resource management and schedule management are tightly connected.

---

13. Project Reasoning Lab: Five-Question Capacity Test

When a PMP scenario shows schedule pressure, ask:

1. What work is late or threatened?

Identify the schedule consequence.

2. What is preventing the work from progressing?

Find the underlying cause.

3. Is resource capacity or capability genuinely the limiting factor?

Do not assume lateness means understaffing.

4. Can existing flexibility absorb the constraint?

Check:

• float,
• sequencing,
• dependencies,
• available capacity.

5. If not, what response addresses the actual cause?

Consider:

• reassignment,
• additional qualified capacity,
• leveling,
• smoothing,
• sequencing,
• compression,
• scope or schedule changes where appropriate.

The reasoning sequence becomes:

Impact → Cause → Capacity → Flexibility → Response

---

14. Five Common PMP Traps

Trap 1: Project Is Late = Extend the Schedule

Too fast.

First, understand why the work is late.

Trap 2: Team Is Behind = Add People

Not necessarily.

Additional people help only when capacity genuinely limits the work, and they have the required capability.

Trap 3: Resource Conflict = Project Delay

Not automatically.

Available float may absorb the conflict.

Trap 4: Resource Leveling = Resource Smoothing

No.

Leveling may alter the critical path or project finish date.

Smoothing works within available schedule flexibility.

Trap 5: Schedule Shows the Cause of the Problem

Not necessarily.

The schedule may show where the consequence appears while the underlying cause exists elsewhere.

---

Final Takeaway

When a project falls behind, do not immediately:

• extend the deadline,
• add people,
• crash the schedule,
• move activities.

First determine what is actually limiting progress.

Ask:

What work is affected?

What is preventing it from progressing?

Is capacity or capability genuinely the constraint?

Can available float absorb the issue?

What response addresses the underlying cause?

The central distinction is:

A schedule problem shows where timing is under pressure. Resource analysis helps determine whether capacity is actually causing it.

And the broader Project Reasoning Lab principle is:

Do not manage the date before understanding what is driving the date.