Okay, so I’m asking.
And this question and article are timed to inaugurate the new discussion forum part of this site, where readers can now go to:
- Respond to discussion topics like this one and others I will be launching, and
- Start their own threads to discuss Total Project Control techniques and/or other project management (or other!) topics that are of interest.
Just click on the FORUM tab, and please keep all discussions respectful and courteous. Now back to the point of this blog, to which you can then post your reactions in the Discussion Forum.
Critical path drag is not, in my opinion, the most valuable innovation that I have included in my books Managing Projects as Investments and Total Project Control. I think the focus in those books on defining and planning projects as investments and then tracking them in scope/cost/schedule integrated fashion through the DIPP and the DPI indexes is what can take project management, and the project manager role, to the next level of professionalism. But critical path drag is the metric and technique whose value is the most obvious and whose omission from critical path analysis is the most glaring! Why no one previously “discovered” it and its implications, or figured out how to calculate it, is a complete mystery to me. (A student of mine once remarked that I see things that are glaringly obvious!) Yet, 16 years after the first edition of Total Project Control was published, the metric is still not in the PMBOK Guide ® and only one PM software package (Spider Project) currently computes it. In the past two or three weeks, I have published a number of articles on drag and drag cost. Here are a bunch of them if you want to read them again, all gathered together under the “drag” tag. If you haven’t read them yet, you might want to go from bottom to top, in the order in which I wrote them. I honestly believe that anyone who understands critical path analysis will immediately appreciate the value of this new metric:
- Unlike the non-critical metrics total float and free float (which every PM software package computes and which are undoubtedly a part of every PMP exam), drag is critical! Why on earth do we quantify the non-critical stuff but not the critical?
- Unlike float, drag is always costing our project time and almost always costing it money, in both the form of reduced expected value and in the form of increased overhead through indirect costs. Why wouldn’t we want to compute these costs so that perhaps we can reduce them?
- Drag cost is a crucial metric for justifying resources. The true cost of a critical path activity is the sum of its resource costs plus its drag cost. Shouldn’t we want to measure this so that we might be able to lower the true cost by increasing resource costs but thus reducing drag costs by even more?
- As every project is an investment, all project work should be adding more value than it costs. We should therefore want to ensure (by combining the value breakdown structure with true cost) that no optional work is included on the critical path whose value-added is less than its true cost. (Here are some blog articles with VBS tags.)
- Project managers often have trouble generating an initial schedule that will meet the date target the sponsor/customer has specified. On a large project, drag computation is a crucial metric for seeing opportunities for schedule compression.
- Even if we start the project with enough time, what happens when the schedule slips? Every experienced project manager knows that feeling of searching for opportunities for schedule recovery. Again, critical path drag is the crucial metric for seeing the opportunities to iteratively pull in one critical path, then another, and yet another until an acceptable schedule has been achieved.
So I ask the readers of this blog: having published lots of books and articles about drag, having presented many PMI webinars and chapter dinner presentations, what should I do to get this information out into the wider PM world and to spur software companies to start measuring this critical metric that’s always there and costing time and money (and maybe human lives!) whether their software deigns to measure it or not? Fraternally in project management, Steve the Bajan