How to Make Critical Path Drag a Standard Scheduling Metric?

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:

  1. 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?
  2. 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?
  3. 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?
  4. 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.)
  5. 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.
  6. 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

3 thoughts on “How to Make Critical Path Drag a Standard Scheduling Metric?

  1. Hi Steve,
    I am sure that you noticed that competition on American project management software market is very low. In most projects using MSP or P6 is required and thus both Microsoft and Oracle are not motivated to improve the functionality of their PM software. Today’s tools are even less functional than the tools used 25 years ago (Artemis, P3, Open Plan, CA SuperProject, etc.). Now they included much more collaboration possibilities but produce poor schedules when resources are constrained and have very limited modelling capabilities.
    Calculating DRAG is not easy, so why bother when the usage of certain tools is mandatory in most projects?
    It looks like now most companies use PM software not because they want to improve their performance but because it is required by their contracts. And requirements are limited by the capabilities of existing software tools. A circle.

    Like

  2. Hi Steve,
    As usual, Vladimir has some interesting things to say. As a consultant and user of the scheduling tools, I have also been frustrated by the lack of functionality of the dominant players.
    Consequently my firm converted some of our internal tools into an Add-In for MS Project called BPC Logic Filter. It’s essentially a logic tracer with some added functionality for Longest Path, driving path, path relative float, and bounded network analysis (i.e. how does one particular task affect another in the schedule.) It’s just an MSP Add-In, so MSP’s built-in limitations are still there. BPC Logic Filter is currently undergoing closed beta testing and is targeted for general availability in late 2015.
    While we have not typically used DRAG in our practice, after reading your article I had our code changed to incorporate it for those who want to see it or report it. (It’s computation was easy in our algorithm.) I even included “Driving Path Drag” in the main bar chart on the web page: http://boyleprojectconsulting.com/new_site/Software.html
    Peruse the “Links” section of our site if you want to know more.
    Rgds, tmb

    Like

Leave a Reply to Vladimir Liberzon Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s