Hi, Jean-Yves.

I sent you an email a few days ago responding to your new structure diagram at 3D-WBS, which I liked a lot (especially the link between the VBS and the CBS and schedule). I hope you received it.

To respond to your questions about critical path drag:

1) what is the drag?

Critical path drag is the amount of time that an activity (or a constraint or resource unavailability or a "sprint" or a handoff or... potentially anything that is adding time to the duration of the longest path) is delaying project completion. In a sense, it is the opposite of float, in that float (1) is only on things that are not critical and (2) is (usually) not costing the project investor time and money and drag almost always is! So we need to paln and manage drag.

The vast majority of software (Spider Project, Sumatra.com's Project Optimizer add-on to MS Project and the new release that Bernard Ertl's InterPlan Systems has announced are exceptions) does not compute drag, but almost all the software computes float. This is, as we sometimes say in English, bass ackwards (erriere en darriere?). While an activity's float is a nice thing to know, what's critical(?) is what's adding time to a project, not what could take more time. Since the important info about a project is what takes the most time, computing float but not drag is like reporting which runner in a race finished last and how much behind the winner, but not reporting who won and by how much!

2) what is the formula of the drag into a "PERT" diagram?

For finish-to-start relationships, the drag of an activity is whichever is LESS: its duration or the total float of the parallel activity that has the least total float (where "parallel activity" is defined as any activity which is neither an "ancestor" nor a "descendant" of the specific critical path activity). For complex dependencies (SS, FF, SF and lag), it's more complex. A fairly easy way to compute drag in SS or SS + lag relationships is explained on the Wikipedia page for critical path drag. 

3) Why do we calculate the drag?

Because the value of a project's product, service or result is almost always (99.7% of the time?) impacted by the duration of the project. The vast majority of the time, sooner means greater value and later means less. What sponsor or customer would EVER fund a project if, for exactly the same cost, s/he could right now purchase a magic wand that, when waved, would create the exact product, service or result s/he wants? The value/cost of time on projects is a HUGE factor, and it is usually left as an externality -- the project team doesn't know what it is. And from Economics 101, the value/cost of all externalities is treated as zero. It is, in my humble opinion, no coincidence that the BEST scheduling work is being done on nuclear plan and oil and gas refinery turnarounds  where almost every manual laborer can tell you exactly the cost of each day and/or hour.

Every day of duration subtracts from the project's expected value – if it doesn’t, that almost always means that the project is not on the critical path of the larger programme! Finishing earlier almost always means: earlier deployment, longer till obsolescence or patent expiration, earlier use in enabled projects (see below), and retirement of the risk of being later! On some projects (emergency response, defense, immunological programs), that “drag cost” can also be measured in lives lost or saved. And on most enabler projects within a larger program, the value/cost of time is hugely multiplied because the value producers being enabled are dependent on the output of the enabler.

In and of itself, an enabler project may generate little or no value – but within the rest of the programme, it may add huge value! Examples can be product development, patent approval, advertising – but these are all relatively easily recognized. The enabler projects that are often problematic from a value recognition viewpoint are the ones that are often regarded as “subsidiary” and therefore their contribution is not fully appreciated: training, obtaining resources, deployment of a platform, and regulatory approval are just a small sample of these. 

And this, of course, is where the value breakdown structure at both the project and the programme level comes in, by quantifying the value of a work item and thus its acceleration premium/delay cost. Which when driven down to the critical path allows us to compute the drag cost for specific activities. And that in turn allows us to justify additional resources -- why would a sponsor reject $20,000 of additional expense if the benefit will be $200,000 of reduced drag cost?

Honestly, Jean-Yves, there's a lot more than just this in the book you've already ordered, Managing Projects as Investments: Earned Value to Business Value. But that simple concept, the importance of estimating the value/cost of time on projects and using that info as the primary (not sole!) input for all decisions, is probably its most important concept.

BTW, Jean-Yves (and anyone else from around the world who sees this), if after reading it you think a French translation would be successful, please let the publishers at CRC Press know -- I truly believe that using these methods can save lives in many project management applications and I'd be delighted if some of those lives saved don't speak English!

Fraternally in project management,

Steve the Bajan