Critical Path Explained Without the Mystique
The word critical has done the technique a disservice. It suggests importance, and the critical path has nothing to do with importance: an activity can be the most consequential thing the project does, carry the greatest risk, and sit nowhere near it. What the critical path describes is arithmetic about time, and it answers one question precisely.
That question is where a day lost is a day lost. The critical path is the longest chain of dependent activities through the schedule, which makes it the shortest time in which the work can finish, and activities on it have no spare time in front of them. Delay one and the end date moves, immediately and by the same amount. Section 2.3 of the PMBOK® Guide Eighth Edition deals with producing schedule information people can act on, and this is one of the few pieces of it that is genuinely mechanical.
What it gives you
A place to put your attention. On a schedule with four hundred activities, knowing which forty govern the finish date is the difference between managing a project and monitoring one. It also tells you where compression money is worth spending, because shortening anything off the path buys nothing at all.
A way to read a delay quickly. When something slips, the first question is whether it was on the path, and the second is how much float it had if it was not. That two-step reading takes seconds with a properly linked schedule and is impossible without one, which is why a list of dates with no logic behind it cannot answer the simplest question anybody asks about a slippage.
Three things it does not tell you
What is risky. The path is calculated from durations that are treated as certain, and certainty varies enormously between activities. A chain with four days of float made up of activities nobody has done before is a larger exposure than a critical chain of well-understood work, and the calculation cannot see the difference. Watching only the critical path is how projects get surprised by something that was never on it.
What is resource-constrained. Classical calculation assumes whoever is needed is available. Where one specialist is required by three parallel chains, the real sequence is longer than the arithmetic says, and it only becomes visible once the schedule has been resource-loaded and levelled. Plenty of projects have a critical path that is technically correct and operationally fictional for this reason.
What it will be next month. The path moves as work progresses: an activity finishing early releases its chain, a slippage elsewhere promotes a different one, and a levelled resource changes the picture again. A critical path identified at baseline and never recalculated is a historical document, and the project is watching the wrong forty activities.
A payments migration and the chain nobody watched
A bank was migrating a payments platform, with a hard external deadline set by a scheme mandate. The schedule was properly built, the critical path ran through the core migration and cutover activities, and it was reviewed weekly in detail.
The chain that nearly stopped the programme was not on it. Reference data cleansing, third-party file format changes and the accreditation testing with two correspondent banks sat on a parallel chain with about nine days of float, which is why it received a fraction of the attention. Every activity in it depended on organisations the bank did not control, and the durations were estimates with no history behind them.
Accreditation with the second correspondent took eleven weeks against a planned four. The nine days of float went in the first fortnight, the chain became critical, and by then the mitigation options had shrunk to one: paying for a parallel run the programme had not budgeted for.
What the programme changed afterwards was its reporting. The weekly review covered the critical path and every chain with less than fifteen days of float, with the variance history of each activity shown beside it. On the following release, a supplier chain was promoted into that view eight weeks before it would have become critical, which was enough time to start the conversation early and to avoid paying for anything twice.
The processing floor downstairs made the point in a more literal way every morning. Work arrived in trays along a bench, and when one tray in the middle stood empty, everything past it stood empty too, whatever the state of the trays before it.
Keeping it meaningful
Build logic, not dates. A critical path calculated from a schedule where activities have been pinned to dates by constraints is arithmetic performed on somebody's wishes. If moving an activity does not move its successors, the schedule has no logic in it and the path it reports means nothing.
Recalculate, and watch the near-critical. Refresh the path with actual progress, and report the chains with small float alongside it. The question worth asking of any schedule is not only what is critical today, but what is about to become critical, and the second question is where the useful management time goes.
For a PMP® candidate, what matters is that the critical path identifies where delay is felt one-for-one and says nothing about risk or resources, so a scenario where a project was surprised by a non-critical delay is describing a schedule being read too narrowly. A response that focuses effort further onto the critical path repeats the omission. Situations where the arithmetic is right and the exposure sits elsewhere are handled at length in a structured PMP exam preparation course.
On a live project, ask for the chains with the least float after the critical one, and look at who owns the activities in them. Where a low-float chain depends on organisations outside your control, that is where the next surprise is being prepared, and it is visible now at no cost.
Interested in going further?
The critical path is easy to calculate and easy to over-trust, and most schedule surprises arrive from the chain just behind it. Omega's PMP® Exam Preparation works through schedule analysis as a question about where the exposure actually sits.
Schedule logic, float and path analysis are covered in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A110: The PMBOK 8 Schedule Performance Domain: What It Really Covers
A121: When a Schedule Baseline Needs to Change
A120: Schedule Compression: Fast Tracking vs Crashing
A117: Velocity: Useful Planning Aid or Dangerous Target?
A113: Float Explained: How Much Delay Can You Really Absorb?
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
