Project myth: Resource Critical Path matters only when resources are overloaded

Project myth: Resource Critical Path matters only when resources are overloaded

by | 16 Jan, 2026 | Blog

Why can’t a project be effectively managed using Critical Path Method (CPM) alone?

Let’s examine a common project-management myth: Resource Critical Path matters only when resources are overloaded.

A resource-loaded schedule calculated using CPM can show the demand for each resource type. If no resource appears overloaded, and assuming there are no cash-flow gaps, the schedule is often declared feasible. This creates an illusion that CPM is sufficient for managing project delivery as long as resources are adequate to support the critical path. This assumption is flawed.

For effective management, it is necessary to understand the flexibility level of activities – how changes in start and end dates impact project duration, cost and benefits. The Network Analysis metric, Total Float, provides an opportunity to understand the impact on the end date and is an important proxy for cost and benefit analysis.

The problem is that CPM-based Total Float can be misleading.

It is calculated under the implicit assumption that resources are unlimited. In reality, no project has unlimited resources; at least some resources are always constrained.

Let’s illustrate why CPM-based Total Float can be misleading with a simple scenario.

This project has adequate resources – while two resources (Alex and Julia) are limited, they are not overloaded.

Under these conditions, the duration-driven critical path coincides with the resource-driven critical path.  Let’s also compare Total Float calculated in both methods:

  • DCPM (Duration-Driven Critical Path, i.e. CPM)
    Under DCPM, Activity D appears to have three days of Total Float. This result would only be valid if the project had additional resources, which it does not.
  • RCPM (Resource-Driven Critical Path)
    When the fragment is recalculated considering resource supply limitations, Activity D has zero Total Float. Any delay in this task will delay the project end date.

This demonstrates the core issue: CPM may be sufficient for developing a wishful delivery plan under the assumption of unlimited resources, but it is not sufficient for effective project delivery because it ignores existing project constraints.

The fundamental metric, Total Float, can be misleading when resource limitations are ignored.

Still, projects continue to use Total Float as the reliably base for both predictive and descriptive analysis. Planners and forensic scheduling consultants often make a convenient assumption that the project has unlimited resources, implicitly ruling out the possibility that delays may be caused by resource limitations.

As a result, resource critical path analysis is systematically ignored. Any variance is then attributed to external events, even when constrained resources are the real driver.

By treating unlimited resources as a given, Total Float loses its meaning as a measure of real schedule flexibility. What is presented as “analysis” is often nothing more than the behaviour of an oversimplified model, detached from project realities.

In practice, projects are delivered by finite people, crews, and equipment. Ignoring those limits does not make delays disappear. It simply makes them invisible in the analysis. Effective project delivery requires Resource Critical Path management.  

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

“B” for Bottlenecks

“B” for Bottlenecks

by | 15 Jan, 2021 | Blog

Majority of projects/programs manage critical project-related live data via project registers, known as DRICA, RAID, etc.

Each letter represents a type of project metadata: R – risks, I – issues, A – assumptions (or actions), D – dependencies, C – change requests, etc

The list of registers varies based on:

  • Nature of the portfolio
  • Type of project
  • PM delivery methodology
  • PPM tool
  • PMO experience

Apart from traditional registers there are other types of registers which could add value to each project team…

Project Registers
If your Sponsor asks you to speed up your project and complete it earlier, could you present a list of project limitations and explain how the project could be sped up if additional resources and/or financials are available? If not, you may consider this additional type of register to manage your project.

“B” for Bottlenecks

Project bottlenecks is a list of project limitations which prevent the project from earlier completion.

Project bottlenecks could be build based on project resource critical path.

“Bottleneck” register typically includes the following fields:

 Activity

Name of project activity on resource critical path.

Duration
Physical duration of the activity.

Limited by: process/resource/contract/financial

If applicable, “Resource” limit type could broken-down to:

  • People
  • Equipment
  • Material

Resource: resource name (or role)

Critical skill: type of skill

Fast-tracking:
Is it possible to apply fast tracking technique? If yes, how many days (hours) could be saved?

DRAG:
Amount of time that an activity or constraint on the critical path is adding to the project duration.

FLEX:
Amount of time that could be saved by optimising resource allocation.

Project bottleneck optimisation recommended best practices:

  • Ideally, we want all bottlenecks to have technical or contract types. It means that project resources are fully optimised. In that case project resource critical path and project critical path will include the same activities.
  • Not all bottlenecks are bad. Some projects use planned bottleneck to smooth project delivery. For example, we do not want to spend all funds until the next financial tranche is available. Or we limit the number of changes per release.
  • Activity DRAGs help to select the best way for the schedule crashing while activity FLEX helps to optimise project resource assignment. 
  • DRAG can be positive or negative. Negative DRAG shows the amount of time that could be saved if activity duration is increased. 
  • FLEX can be positive or negative. Negative FLEX shows the amount of time that could be saved if the number of assigned resources is increased.
  • It is valuable to understand vendors bottlenecks and whether they could be removed by additional funds.
  • Agile projects always have bottlenecks, otherwise, the whole backlog could be delivered in one sprint. Usually, Agile projects are constrained by a particular type of skill. Often it is not obvious as everyone is working hard which creates an illusion of productivity.
  • Some project managers prefer to keep an eye on near critical path activities and to be aware of a type of resources which could be critical. 
  • Some projects use criticality index in their “bottleneck” register or directly in the schedule (if their scheduling tool supports it). Criticality index takes into account project risks data. It informs how often a particular activity was on a critical path during risk simulation calculation. Non-critical activities may have a higher chance of becoming critical during project execution and need special attention.
  • DRAG, FLEX and Criticality index for Primavera and Microsoft Project schedules could be calculated with a schedule optimisation tool, like Spider Project. Spider Project supports resource critical path, DRAG, FLEX and Criticality indexes.
  • Project “bottleneck’s optimisation” is a repetitive  process. After the current project bottlenecks removed, the analysis gets repeated until all possible and desired “bottlenecks” optimised.

Alex Lyaschenko

PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma