Stormy Weather

I’m teaching this week in UMass/Lowell’s Executive Education Project Management Certificate Program. Great students, very bright and motivated, but the result is that I probably won’t have time for a full blog article this weekend.

However, I had decided to write a brief article at the formal start of the Atlantic hurricane season (June 1) referencing the fact that it is likely that some city or country will be devastated in the coming months and that, unfortunately, emergency response that specifically uses PM techniques such as critical path analysis and drag, drag cost in human lives saved, and resource leveling will not have been planned and optimized in advance by the relevant governments and organizations.

Hurricane damage

This morning I read that the first named storm of the season, Ana, has formed off the Carolina coast, three weeks before the formal start of the season. I hope that this is not a sign of a coming season of extensive lethality. But meanwhile, I would urge all readers interested in either critical path analysis and/or emergency response to read this chapter linked on my webpage “Time Is a Murderer: The Cost of Critical Path Drag in Emergency Response” that  I wrote for the CRC Press’s 2013 Emergency Response Handbook. The article is written with a Bay Area earthquake response in mind, but the planning process should be little different for a hurricane, tsunami, volcano, epidemic or any other catastrophe. And it demonstrates the practical use of the critical path drag metric in optimizing any project schedule.

And alas, these techniques are substantially unknown in emergency response planning.

Fraternally in project management,

Steve the Bajan

What is the True Cost of an Activity’s Work? Is It Worth It?

I have been delighted that my recent blogs about aligning the program and the project, the sponsor and the project team, have gotten a very positive response. In particular, the value breakdown structure (VBS), as a tool for accomplishing this, seems to have been very well received. So this article explores the next step, how to combine the VBS with other new investment-based techniques and metrics, to ensure that project effort and money are not being frittered away on low value products and work.

It is no revelation to the business community that projects are being completed every day that fail to generate the intended benefits. Many of these can be categorized, from an investment viewpoint, as “losses” – they cost more than they turn out to be worth.

The same principal that says that such project investments are losses also says to me that, on every calendar day and throughout the world, there will be a substantial number of projects completed that include work that costs significantly more than it is worth. No, I have not conducted a study to see if such is the case (although I think that it would be a very fruitful topic for research!). Rather, I deduce this from the fact that the following important steps in measuring both value and cost on projects are simply not being done:

  • Most projects never bother to create a value breakdown structure (VBS) and so have not even a guesstimate of what the value is of any optional scope;
  • Most projects do not bother to estimate the value/cost of time;
  • Many projects (and programs!) fail to perform even rudimentary critical path schedule analysis; and
  • Even on those projects that do perform critical path analysis, they rarely compute critical path drag and drag cost up front, and almost never re-calculate it during project performance. Such re-calculation is especially crucial when the critical path changes during execution.

If all of the above techniques are not used on a project (or program), then it is very likely that the effort will include products and work that cost more than the value they add.

My recent blog articles have discussed the essence of the first of the above points, the value breakdown structure (VBS). This is a tool for prioritizing project work packages and activities by estimating their relative importance and value. Some project components (like both the left wing AND the right wing on an airplane) are mandatory: the project cannot be completed without both of them. Other components are optional, included not because they are essential but for the value they are expected to add. If you have not yet read this blog article on the VBS, I urge you to do so now and then return to the rest of this article.

The True Cost of Work (TCW)

If would-be project sponsors could simply buy the exact product they want and have it immediately delivered and ready for use, they would elect to do so almost every time. In fact, they would usually even be willing to pay a significant premium for an off-the-shelf product that precisely meets their needs rather than funding a project to create it.

Why? Because (1) there are many more risks in creating the product than in buying something that has already been made and quality-checked, and (2) the time that it takes to create something you want almost always has a cost, and sometimes a great deal of cost!

Time is money, wrote Benjamin Franklin, and it is rarely more definitively so than when the sponsor/customer has to wait for project completion. But how much money is time worth on a given project? How much would the sponsor be willing to pay for each week earlier that they would be able to deploy the desired product?

Occasionally, it’s worth very little. Rarely, it might even be worth less if delivered early because its internal systems will start to run down and/or become obsolete. But such situations are so unusual that, when such is the case, it is crucial that the project manager and team know that this project is one of those “exceptions”! (And, by the way, it is almost always due to the fact that the specific project is part of a program but not on the program’s critical path!)

In the vast majority of cases, the value/cost of time on projects ranges from moderate to, yes, vast!

  • Our intended new product can generate no value until it’s deployed.
  • Our new product is an enabler and other revenue generators need it.
  • Competitors enter the market and make our product a “me-too”.
  • Market windows are missed.
  • Market share is lost.
  • We lose weeks in implementing a tool that will result in weekly cost reduction.
  • And sometimes humans die because of the delay.

Yet, sad to say, projects are initiated with arbitrarily-chosen “deadlines” and without any attempt to quantify the value/cost of being earlier (or, indeed, later!) than that target date.

So if an earlier deployment of a product would be worth $40,000 per week to a potential sponsor/customer, surely we can see that they would be delighted to consider an off-the-shelf product that costs $2M rather than execute a 30-week project with a $1.5M budget to create a similar product. All else being equal, the project approach would have a true cost of work (TCW) of $1.5M + (30 * $40,000) = $2.7M.

The TCW is the overhead-burdened cost of resource usage plus the value/cost of the time we lose in waiting for the work to be completed. If the work is serial in nature (i.e., one activity only, or simply one activity after another), it is easy to measure the time we must wait and “charge” each activity’s duration with the cost of that time.

But what if the work comprises a project that is part of a program that has other projects occurring in parallel? Or, onion-like, if the work is an activity in a project and it has other activities occurring in parallel?

As project managers understand, the determining factor of the duration of every project (and program!) is the work, constraints, re-work, dropped batons, and other delays that comprise the longest path, i.e., the as-built critical path (ABCP)! Activities and other delaying factors that are not on the critical path (even if with only one day of float!) are not delaying completion, and in TPC (i.e., Total Project Control) terms have zero drag – and thus zero drag cost! Therefore the true cost of work that is not on the critical path (either of the program or of the project) is simply the cost of resource usage.

But the TCW for each item of critical path work is the sum of its drag cost plus its resource usage costs. Thus comes the importance of computing these on every project and program, because without that computation, you really don’t know what each item of work is costing! And if the true cost of a work package, activity or project is greater than the value that it is adding (per the value breakdown structure), we should either figure out a way to reduce its true cost (perhaps by electing to use the DRED) or jettison it from the project (or program)!

In my next article, I will talk more about how work with negative value-added (value-subtracted?) often arises. But meanwhile, you might want to take a look at this article on drag (published here in Portuguese by Peter Mello) and perhaps at the drag cost and true cost exercises on the main page. (Or just read my two new books, Managing Projects as Investments: Earned Value to Business Value or the second edition of Total Project Control).

Fraternally in project management,

Steve the Bajan