Who finished fourth in the last Olympic Men′s 100 metres track and field race? What was that runner′s time? How many people know?
It so happens that the fourth place finisher, Tyson Gay, is the American record holder for the 100 metre sprint. In the London Olympics, his time of 9.80 seconds would have won the gold at many previous Olympiads. Yet on this occasion he finished only fourth, didn′t win a medal, and so his performance has been forgotten by all but the keenest fans. More people recognize Usain Bolt, the winner with a time of 9.63 seconds.
Why? Why is Usain remembered while those of the later finishers are forgotten? The reason is because all the other competitors completed the race after the event had already been won! Certainly the performances of the silver and bronze medal winners, and even of the last place finisher, are worthy of respect. But the reality is that once one individual has broken the tape, the rest of the race is an anticlimax. The winner is critical.
The Project Management Race
Managing a project is the precise opposite: it′s the last work activity or path to finish that (1) determines the duration of the project and (2) is critical. Time on a project is driven by its critical path. Every project is exactly as long as the sequence of work, constraints, and other delays that comprise its longest path: not its planned longest path, but its actual longest path. Or, as it′s called in the construction industry, the As-Built Critical Path (ABCP). Every project will have a critical path which determines its duration. We can attempt to predict, optimize and manage that path or we can ignore it. But it′ll always be there!
Unfortunately, in the second decade of the 21st Century, a large percentage of project managers still choose to ignore the techniques of critical path scheduling and analysis. Why? Do they not know about this technique that was developed more than a half-century ago? Do they not understand its metrics and its potential benefits?
One cause could be that the key metric of critical path scheduling pays more attention to Tyson Gay than Usain Bolt! It treats a project as though it were a race by measuring how much time elapses between Bolt breaking the time and when the other participants finish. I′m referring to the metric called total float, or, in Microsoft Project, total slack. This metric, which every CPM algorithm computes and every scheduler knows, ignores the critical element in the project schedule: the path that finishes last!
Float, Drag, and Critical Path
Every software package computes float, often in many flavors: total float, free float, terminal float. But where is float always found? OFF the critical path. It′s the difference between most important finisher and another finisher: the 0.17 seconds between Usain Bolt′s 9.63 and Tyson Gay′s 9.80 seconds. But what does the software tell us about the work that is on the critical path? Answer: zero. It tells us that its float is zero. What should it tell us? It should tell us how much time each critical path activity is delaying the project, i.e., its drag. That extra time in the project′s duration is critical and is costing us both time and money, reducing the return on our project investment. Yet the software (with about two exceptions) (1) doesn′t tell us the drag; (2) project managers don′t know how to compute it; and (3) the PMBOK ® Guide doesn′t recognize it.
What′s measured is what gets the attention. Since float is measured, and float is off the critical path, the scheduler′s attention is drawn to the noncritical paths. As Bill Duncan′s 2009 article “Scheduling is a Drag!” points out, the attitude becomes: “Oh, it′s okay if this activity slips ten days because it′s got twelve days of float.” In fact, the exact opposite should be the approach: “This (critical) activity has twelve days of drag. If we can compress it, we can shorten the whole project by up to that amount of time.”
As long as all the dependencies are finish-to-start (FS) relationships, drag can be computed by following three simple rules:
- Drag is only on the critical path.
- If a CP activity has nothing else in parallel, its drag is equal to its duration.
- If a CP activity does have something else in parallel, its drag is whichever is less: its duration OR the total float of the parallel activity that has the LEAST total float.
In Figure 1 below, we have a traditional network logic diagram where we′ve computed the early starts and finishes and the total float of each activity. Question: how much time is each activity adding to the total project duration of 33 (or, alternatively how much would the project be shortened if the duration of a given activity were compressed to zero)?
Figure 1: A network logic diagram with early starts and finishes and total float computed
By definition, two activities are parallel if neither is an ancestor nor descendant of the other (and thus are not on the same path of arrows. Thus:
- Everything is a descendant of A and it has nothing in parallel.
- Everything is an ancestor of E and it has nothing in parallel.
- B is a descendant of A, an ancestor of C, D, G and E, and parallel with F and H.
- C is a descendant of A and B, an ancestor of D, G and E, and parallel with F and H.
- D is a descendant of A, B and C, an ancestor of just E, and parallel with F, G and I.
As shown in Figure 2:
- A and E, with nothing in parallel, each has drag equal to their durations, 10 and 4 respectively.
- B has drag equal to its parallel activity with the least total float, F with TF of 6.
- C would be the same as B, except C′s duration is only 3, which is less than F′s total float. Thus C is only adding drag of three to the project duration.
D is parallel with all of G, H and I, and I has total float of just 1, so D′s drag is 1.
Figure 2: A network logic diagram with critical path drag computed
Let′s imagine that the above network represents the schedule for bringing a new medical device to market. Let′s also imagine that every unit of time before the device reaches market, we are losing $500K in revenues. And further, this device will save an average of five lives per day.
The cost of each activity′s drag can be measured as drag cost, in both dollars and human lives lost. The calculations are shown in Figure 3, and represent a way of justifying the cost of additional resources on the critical path activities if they would shorten the activity and project durations.
Figure 3: A network logic diagram with drag cost computed
As we′ve seen, computing critical path drag in a network of all finish-to-start relationships is manageable, at least on a small to medium-sized project. On projects of over 1,000 activities, or with complex dependencies and lags, it′s very difficult. However, it′s exactly the sort of thing that computers are designed to do. We can only hope that more computer programs will soon be available to calculate this critical metric.
For further information on critical path drag and how to utilize it, I recommend the article “The Drag Efficient: The Missing Quantification of Time on the Critical Path” in the Jan/Feb 2012 edition of Defense AT&L Magazine and my chapter “Time is a Killer” in the book Handbook of Emergency Response (ed. by Badiru & Racz), due for release by CRC Press in August 2013.
Author of this post, Steve Devaux, PMP, MSPM, is Adjunct Instructor at Suffolk University and President of Analytic Project Management, Swampscott, MA, a PMI Global R.E.P. Author of numerous articles and PMI webinars, Devaux has consulted for 25 years with Fortune 500 clients, and is the author of Total Project Control: A Manager′s Guide to Integrated Project Planning, Measuring and Tracking (John Wiley & Sons, 1999). He has contributed chapters on critical path drag in two new CRC Press books: Project Management in the Oil and Gas Industries and Handbook of Emergency Response. He can be reached for questions concerning this guest blog at apm7@ix.netcom.com.