For starters, let’s make an important distinction: there is a difference between CPM scheduling and critical path analysis.
- CPM is a technique for developing a project schedule by estimating the duration of each activity and then sequencing them in the logical order in which they can occur.
- Critical path analysis is the process of analyzing any schedule, no matter how it was originally developed – traditional CPM, resource-leveled critical path, CCPM, agile, or darts at a dartboard – in order to make improvements.
If the duration of the project is significant, then it is always important to perform critical path analysis, because every project’s duration will be exactly equal to its actual longest path, or what in the construction industry is referred to as its as-built critical path (ABCP). That path may include activities, constraints, resource bottlenecks, sprints, stumbles, dropped batons, rework, or any other type of delay. But the analysis of those delaying factors should always be a prime concern of the scheduler and project team.
And although there is certainly value to be gained through a post mortem process, mightn’t there be even more value in doing it while the patient is still alive?
Why is critical path analysis so important? Because:
- On the vast majority of project investments, expected value/ROI is impacted by completion date. Earlier completion usually leads to:
- Greater total value;
- Faster generation of that value; and
- Elimination of the risk of later completion!
- If there is value in shortening the project duration, that can only be accomplished by reducing the length of the longest path.
So what is the most important metric of critical path analysis? It’s certainly not float, either total or free. Float is a measure of the extra time you’ve got, and is (almost always!) on activities that are, specifically, off the critical path.
If critical path analysis is intended to increase the value of the project investment by shortening the schedule (perhaps up front, perhaps after slippage), then the most important metric is surely one that applies to the longest path! It’s the one that will help the project team to identify how much time each critical path activity, constraint, resource bottleneck, sprint, stumble, dropped baton, rework, or other delaying factor is currently adding to the remaining project duration! It’s the one that, when changes are made to pull in the longest path thus making another path longest, will identify how much time each item on the new CP is delaying completion! And when you make changes on that new CP and are now constrained by yet another longest path, will quantify the delays that its items are causing!
That metric is critical path drag, and I maintain that it is, by far, the second most important (critical?) metric in critical path analysis. Why only the second most important? Because the most important is drag cost, i.e., by how much is the drag of a critical path item reducing your project’s expected value. That is the most important metric because that’s the one that will allow the project team to optimize the project investment (the ultimate goal of every project!) by justifying the cost of resources by $X to reduce the drag cost by $2X! But of course you can’t get drag cost until you’ve first computed drag.
Let me make one point clear: Steve Devaux did not invent drag! Drag is always there, and has always been there – on the items (activities, etc.) on the longest path of every project, going back to the building of the pyramids and before! We can compute it or we can ignore it – but it’s still there! All that I did is figure out the rules for computing it as I helped my consulting clients compress their schedules. How did I figure it out when others hadn’t? Because as an engineer in one of my corporate classes said to me about five years ago: “Y’know, Steve, you have an amazing grasp of the glaringly obvious.” And critical path drag and its value as a metric is glaringly obvious!
So why is critical path analysis, for the most part, not being performed? Because the project management community, more than half a century after the initial principles of CPM were published, 16 years after the first edition of my Total Project Control book came out, six years after Bill Duncan’s article “Scheduling Is a Drag” appeared at ProjectsatWork.com, three years after Defense AT&L Magazine published “The Drag Efficient: The Missing Quantification of Time on the Critical Path”, five years after Spider Project released a software version that computes critical path drag, and two years after I presented this webinar for PMI’s Scheduling Community of Practice, remains blissfully unaware of the key enabling metrics.
So I conclude with four questions:
- Despite the fact that so many people pay lip service to critical path analysis, why would anyone perform it on a network of 1000+ activities when their software does not support the metrics that make it valuable and simple?
- Why would project management professionals perform such analysis when the supporting metrics are not in PMI’s PMBOK® Guide, nor in its Scheduling Standard, nor in any of IPMA’s published methodologies?
- Why do software companies and project management professional organizations not support/publicize the metrics that enable this analytical tool that is fundamental to the discipline of project management?
- Why do slipping project schedules so seldom recover?
If you want to learn how to compute drag and drag cost manually, check out the exercises (with answers) on under the EXERCISE tab at the top of the page.
Fraternally in project management,
Steve the Bajan