Every project manager I've ever met planned to finish on time, most didn't.
After thirty years working inside project-driven organisations — manufacturing plants, retailers, IT rollouts — I've seen the same pattern repeat itself with remarkable consistency. The plan looks reasonable at the start. The team is capable and motivated. And yet, somewhere between kickoff and completion, things slip. Deadlines get pushed. Resources get stretched. The final delivery lands late, over budget, or both.
The tempting explanation is execution failure: the team didn't work hard enough, the estimates were wrong, the risks weren't managed properly. In my experience, that explanation is almost never correct. The problem is structural: it's built into the method most organisations use to plan and manage their projects.
That method is the Critical Path Method. And it has a fundamental flaw.
What the Critical Path Method Gets Right — and Where It Breaks Down
The Critical Path Method (CPM) was developed in the 1950s and remains the dominant approach to project scheduling today. It identifies the longest sequence of dependent tasks in a project — the critical path — and uses that sequence to calculate the minimum project duration.
It's a logical framework. For simple projects with stable resources and predictable tasks, it works reasonably well. The problem is that real projects don't look like that. In practice, CPM has three structural weaknesses that consistently cause projects to run late.
1. It assumes unlimited resources
CPM schedules tasks based on dependencies — task B can start when task A finishes. What it doesn't adequately account for is who is doing the work. If the same engineer is needed on three tasks simultaneously, CPM doesn't flag the conflict. The schedule looks fine on paper, whereas reality looks entirely different.
2. It encourages padding at the individual task level
When you ask someone how long a task will take, they don't give you their best estimate. They give you a safe estimate — one that includes a buffer for unexpected problems, interruptions, and uncertainty. This is rational behaviour, but it creates a plan full of hidden safety time distributed across every single task.
And here's the cruel irony: that safety time gets consumed anyway. Not by the unexpected problems it was meant to cover, but by two very human tendencies that Goldratt identified precisely.
- Student syndrome — the tendency to start tasks late because the deadline feels distant. Just as students leave essays to the last minute, project team members delay starting work until the buffer has already been eaten.
- Parkinson's Law — work expands to fill the time available. If a task has a two-week estimate, it takes two weeks — even if the actual work could be done in eight days.
Underlying both of these is a deeper structural problem: CPM assigns a fixed start date and finish date to every task. This creates a subtle but damaging psychology — the start date becomes permission to wait, and the finish date becomes the real target. The work fills the window between them, regardless of how long it actually needs.
3. Multitasking destroys productivity
CPM allows — and often requires — team members to work on multiple tasks simultaneously. This feels efficient. It isn't. Context switching has a measurable productivity cost, and when people are spread across multiple projects, nothing moves as fast as it should.
The result of these three dynamics combined: a project plan full of individual task buffers that get wasted through late starts and scope creep, while the overall project has no protection against the variability that actually matters.
What Critical Chain Does Differently
Critical Chain Project Management (CCPM) was developed by Eli Goldratt – the father of Theory of Constraints, and introduced in his 1997 book Critical Chain and it starts from a different premise: the problem isn't the people, it's the system. And it redesigns the system accordingly.
CCPM makes three fundamental changes to how projects are planned and managed.
1. It builds the schedule around resources, not just tasks
The critical chain is defined as the longest sequence of tasks considering both task dependencies and resource dependencies. If two tasks on the critical path require the same person, that constraint is built into the schedule from the start. The result is a plan that reflects reality — one that can actually be executed.
On top of that, CCPM breaks totally the "start-finish date" logic. Once a project has been kicked off, tasks have no fixed start date because what we care about most is project's deadline, not tasks. Therefore, work is passed from one person to the next as soon as it's ready — the baton moves the moment a runner finishes their leg. There is no scheduled handoff time, no waiting for the clock to reach a predetermined date. If a task finishes early, the next task starts immediately. That early finish — which CPM would squander through Parkinson's Law — becomes a real gain that protects the project buffer.
This single shift in thinking, from a calendar-driven handoff to a relay race mentality, is one of the most practically powerful changes CCPM introduces.
2. It removes individual task buffers and replaces them with shared project buffers
In a CCPM plan, task estimates are set at approximately 50% probability — aggressive but achievable. When project teams first encounter this, the reaction is often resistance. Cutting estimates in half feels like pressure — like being asked to do the same work in less time, with less margin for error. This is one of the most common points of friction when introducing CCPM to an organisation, and it deserves a direct answer.
The 50% cut is not about working faster under greater pressure. It is about being honest about where the safety time actually goes.
In a traditional CPM plan, every team member buries their own safety margin inside their individual task estimate. That safety time is invisible, unmanaged, and — as we've already seen through student syndrome and Parkinson's Law — almost entirely wasted. It protects no one, because it disappears before it's needed.
CCPM doesn't remove that safety time. It moves it. The time taken out of individual task estimates is pooled together and placed explicitly into shared buffers at strategic points in the plan. Crucially, that pooled time is available to anyone who needs it — not locked inside a single task owned by a single person.
This matters more than it might initially appear. If ten tasks each carry a two-day personal buffer, and only three of those tasks actually run into difficulty, the other seven buffers are wasted. Under CCPM, those same twenty days of total safety time sit in a shared project buffer — available in full to whichever tasks actually encounter problems. The team is not exposed to more risk. They are collectively better protected, because the safety time is deployed where it's actually needed rather than distributed arbitrarily across every task.
Those buffers are placed at three specific points in the plan:
- The Project Buffer sits at the end of the critical chain, protecting the final delivery date from accumulated variation along the critical path.
- Feeding Buffers protect the critical chain from delays arriving from non-critical paths — the side chains that feed into the main sequence.
- Resource Buffers ensure that key resources are available and ready when the critical chain requires them, eliminating the handoff delays that CPM leaves unmanaged.
The result is a plan that makes uncertainty visible and manageable, rather than hiding it inside individual estimates where it quietly evaporates.
3. It lower down harmful multitasking
CCPM explicitly prioritises tasks. At any point in the project, each team member knows exactly which task is their current priority. Work is completed and handed off — the baton moves, not the juggler. Will people still multitask occasionally? Of course they will. The goal is not perfection — it's reducing the structural pressure that makes harmful multitasking feel necessary in the first place.
The Buffer Fever Chart — Managing by Exception
One of CCPM's most practical tools is the buffer fever chart. It tracks how much of the project buffer has been consumed relative to how much of the critical chain has been completed.
If a project is 50% complete and has consumed 20% of its buffer, things are on track. If it's 30% complete and has already consumed 60% of its buffer, that's a warning signal — action is needed now, not when the deadline is a week away.
This is fundamentally different from traditional progress tracking in tools like Microsoft Project, which measures progress as percentage completion of individual tasks. In practice this creates a well-known and deeply frustrating phenomenon: projects that appear to be progressing smoothly on paper, with tasks reporting 70%, 80%, 90% complete — and then stall. The final 10% somehow takes as long as the first 90%. Percentage completion is a lagging indicator that tells you where you've been, not where you're going. It gives you no warning until the damage is already done.
CCPM's buffer fever chart works differently. It distinguishes between normal variation and abnormal variation — giving project managers an early warning system rather than a post-mortem. The chart is divided into three zones:
- Green — buffer consumption is proportional to progress or better. The project is healthy. No action needed beyond continuing to execute.
- Amber — buffer is being consumed faster than progress warrants. This is a warning signal: begin planning corrective actions now, while there is still time to act.
- Red — buffer consumption has exceeded the threshold. Immediate intervention is required. The plan needs to change.
The critical difference is when these signals arrive. In CPM, you discover a project is in trouble when the deadline is close and the last 10% refuses to close. In CCPM, the amber zone triggers attention weeks or months earlier — when there is still room to recover. The fever chart doesn't just measure progress. It measures risk in real time, giving management the information they need to act before a delay becomes irreversible.
Results — and Who This Is For
The research on CCPM outcomes is consistent. Studies report 25–40% reductions in project duration, on-time delivery rates above 90% in multi-project environments, and significant reductions in work-in-progress — the number of projects running simultaneously without completing.
In my own practice, the pattern I see most often is this: organisations implementing CCPM for the first time are surprised not by how much faster individual tasks complete, but by how much faster projects finish. The bottleneck was never the work itself. It was the system around the work.
CCPM works best when:
- Resources are shared across multiple projects simultaneously
- Project timelines are consistently slipping despite competent teams
- The organisation has a culture willing to work with aggressive-but-honest task estimates
- There is management commitment to protecting the critical chain from interruption
It requires more up-front discipline than simply drawing a Gantt chart. The planning process is more rigorous, the conversation about estimates is sometimes uncomfortable, and the cultural shift away from multitasking takes time.
For organisations willing to make that shift, the results are not marginal. They are structural — because the change is structural.
A Note on Software
CCPM can be implemented manually for simple projects. For multi-project environments — where resource conflicts across simultaneous projects are the primary constraint — dedicated software makes a significant difference. I work with Lynx CCPM by A-dato, which I can support you with, because it was built specifically for CCPM rather than retrofitted from a traditional Gantt-based tool. The distinction matters in practice.
The Real Reason Projects Run Late
It is not the team. It is not the estimates. It is not bad luck.
It is a planning method designed in the 1950s, before we understood the psychology of task estimation, before multi-project environments were the norm, and before Goldratt gave us a better framework.
Critical Chain doesn't require more effort from your team. It requires a better system for the effort they're already making.
If your projects are consistently finishing late despite good people and reasonable plans, the method is worth examining. I'd be glad to walk through what CCPM would look like in your specific environment — whether you're running engineering projects, IT implementations, or complex operational programmes. The method has been the same since the 1950s. The results don't have to be.
