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

Disable de Sirens — But Put Out de Critical Path Fires, Too!

I share, with many others of the anglophone Caribbean culture, a propensity for exaggerated over-the-top hyperbole. And no, I’m not being redundant – any one, or even two, of those three terms would often be insufficient to describe the extended lengths to which we will sometimes go to draw attention to the point we’re trying to make.

As an illustration, there is the old story of the Bajan visiting London who is trying to describe the wonders of his home isle.

“In Barbados, we have mountains of sugar, rivers of rum, and fish that fly!”

To which, of course, the Englishman replies: “I might believe in the mountains of sugar and the rivers of rum, but I’m damned if I’ll believe in fish that fly!”

Slide1

So in my previous article, “Whaddya Do When the Critical Path Changes?”, I resorted to a little (for a Bajan!) hyperbole. I wrote that when the critical path changes, “sirens should wail.” And I was, quite properly, taken to task by a couple of people, including Shelley Horowitz in the Comments following that article, for suggesting the need for a state of alarm or danger due to such a change. And the criticism is quite correct. A half century spent in US cities, where sirens are an everyday occurrence, has perhaps combined with my West Indian exaggerations to dull me to the fact that, for many people in the world, sirens really do represent danger and appropriate panic: fire, tornadoes, tsunamis…

So I am taking this opportunity first to apologize, and then to explain in greater depth exactly what I meant.

The exact sentence in that previous article was:

“What should happen immediately is that sirens should wail, warning the project manager that Activity H, with a value-added of just 20% of $350K, or $70K, now has a negative NVA due to the fact that it now also has drag of 2 days and thus drag cost of $50K.”

So let’s eliminate the need for sirens. What I was suggesting is that a change in critical path during project execution can have a major impact on the future project plan. Work that made sense to perform in a certain way may now be a significant drag (!) on our project investment, requiring new analysis.

Figure 4 full network diagram after slippage

Notice, the key event as described in the quoted sentence above is NOT that the critical path changed — it is that this change caused specific activities to now have a negative impact on the project’s expected value! The project would now be better off without the optional Activity H, because its true cost is now greater than its value-added. And this is a potential hazard any time that the critical path changes.

But the problem is that such an event, as described in the linked article, would most probably not even be recognized. Or if it were, it would only be after a great deal of “manual” analysis. Even on a schedule of 100 activities (never mind a medium-sized project of 2000+ activities!), the chance of the scheduler or project manager noticing that one or more activities are suddenly costing more than they are worth is vanishingly small. Why? Because few of the techniques that would allow such a negative anomaly to be noticed are being used:

  1. Projects are not being defined as investments, so that expected monetary value (EMV, or NPV or ROI or any other investment value term you like) and its changes are not being incorporated into the PM software and tracked and optimized either upfront or during performance. The vast majority of commercial software packages do not provide a project-level field for attaching quantified investment value to a project, nor the functionality to manage and track changes that might affect it.
  2. The value-added of specific work packages is not being estimated and assembled into a value breakdown structure (VBS), so that in the diagram from the previous article the value-added of Activity H would be unknown.
  3. The value/cost of time, which usually has significant impact on project EMV, is not being estimated or tracked on most projects, and certainly not in the software. This in turn makes it impossible to compute either the drag cost or the true cost of an activity.
  4. Even on that small minority of projects where the value/cost of time is estimated, critical path drag and drag cost are not being computed. This means that the true cost of Activity H, and the fact that the slippage it is now making the net value-added (NVA) of Activity H negative, is therefore completely unknowable!

Notwithstanding my previous remark, what should happen when such an event occurs is not wailing sirens. Rather, the user’s PM software (MS Project, Primavera, or whatever) should take the info that was entered up front regarding the VBS and the value/cost of time, compute the new drag, drag cost and true cost totals for each new activity on the new CP and kick out an exception report, calling attention to Activity H, perhaps by highlighting it in red (preferably, fire engine red!). And now the team/PM can reassess and amend the plan.

But first, the team has to recognize the issue. And currently, none of that can happen because with the exception of one software package (Spider Project), none of the others (not MS Project, not Primavera, not Asta, not PlanView, not Safron, NONE!) is even computing critical path drag, far less supporting a VBS or drag cost, true cost, and net value-added computation! (And they should, because every project has a critical path, and critical path items have drag and drag cost!)

And that’s why projects are being performed all the time that generate less expected project profit (EPP) than they might because they include work whose true cost after a critical path change outweighs the value that it adds.

If you want to learn more about assembling a VBS and the other techniques mentioned above, they are explored in much greater detail in the new (2015) edition of my first book, Total Project Control: A Practitioner’s Guide to Managing Projects as Investments.

Again, thank so much to those who criticized my “siren” hyperbole and for making it clear that I need to post another article pointing out the implications (and cures!) listed above.

Fraternally in project management,

Steve the Bajan

“Whaddya do when the critical path changes?”

The title of this blog post may, alas, be a surprise to some less experienced project managers. “What – you mean the critical path might change?” Not only might it change, but if you did a good job of schedule optimization during your upfront planning, it very likely will change!

That’s because time is money and project value is usually increased by a shorter project schedule. The optimization process is usually one of iteratively squeezing critical path drag out of the longest path through fast tracking and added resources, thereby reducing float on the other paths. With less float, it often doesn’t take much delay for a secondary path to become critical, even though the entire project duration is still a lot shorter than it would have been without optimization, and the project will be more profitable.

But when a secondary path becomes critical, lots of important things change. Not only do activities that had drag now have float, but activities that had float now have drag! And drag cost! The basis for our critical path analysis is altered, and should require examination and re-evaluation of all our critical path activities, constraints and resources.

Let’s start by looking at a simple project network diagram as shown in Figure 1:

Figure 1 The VBS with Network

This diagram may contain info which some readers are not familiar with seeing in a project schedule. First, it includes the output of our value breakdown structure (VBS). As you can see, each box contains a letter, either M or O.

  • M stands for Mandatory and means that the activity must be performed as part of the project or the project will have no value. The value-added of all mandatory activities is equal to the project’s expected monetary value (EMV). Since the information at the top of the figure says that the project will have an expected value of $400K if completed on Day 55, and since the current schedule is 55 days, all mandatory activities have a value-added of $400K.
  • O stands for optional. These are activities that add value, but the project would have value even if they were excluded. All projects have such activities, and it is important both to recognize them and to estimate the value they are adding to the project. In Figure 1, Activities C, D, E and H are all optional, with value-addeds estimated to be 50%, 40%, 80% and 20%, respectively, of the project’s value.

In Figure 2 below, I have computed the drag, drag cost and true cost (TC) (TC = drag cost plus budget) for all the activities. If you want, do those calculations for practice before you look at Figure 2.

Figure 2 The VBS with drag drag cost and true cost

Notice that the planned true cost of activities that are not on the critical path is equal to their budgets, as they have no drag and thus zero drag cost.

With both the value-added and the true cost of each activity computed in Figure 2, we can now compute the net value-added (NVA) (NVA = value-added minus true cost) of each activity and ensure that each is worth performing. This is displayed in Figure 3.

Figure 3 Full network diagram including value addeds

As shown in Figure 3, all the activities have a positive NVA. The lowest NVA is Activity H, which has a value-added of only 20% of the project’s EMV, or $80K, but a TC equal to its budget of only $30K, for a net value-added of $50K.

Okay, so all is hunky-dory and we start the project with this plan. And then things start to happen. To be precise, Activity C, planned to take 13 days and finish at the end of Day 23, takes an extra 7 days and does not finish until the end of Day 30. As shown in Figure 4, this can change everything that’s important!

Figure 4 full network diagram after slippage

Suddenly, the critical path has changed and now goes through Activities F, H and I. Additionally, the project’s planned duration has slipped by two days, with a delay cost of $50K per day. As a result, the project’s EMV has slipped to $350K and the value of each activity, both mandatory and optional, has slipped accordingly.

What should happen immediately is that sirens should wail, warning the project manager that Activity H, with a value-added of just 20% of $350K, or $70K, now has a negative NVA due to the fact that it now also has drag of 2 days and thus drag cost of $50K. Its true cost is $80K, $10K less than the value it is adding. Either figure out a way to change the schedule (adding resources or changing the network logic) or jettison Activity I – the project will generate $10K more expected profit without it!

Two final points:

  1. $10,000 may not seem like much – but this is just an example. Projects are being performed every week that include work which, for the same reason as shown here, costs millions of dollars more than its worth.
  2. The only way to identify when this is happening is to have all the Total Project Control (TPC) data for both activity value-added and drag cost estimated and computed.

Fraternally in project management,

Steve the Bajan

What is the most important metric of critical path analysis?

For starters, let’s make an important distinction: there is a difference between CPM scheduling and critical path analysis.

  • CPM is a technique for developing a project schedule by estimating the duration of each activity and then sequencing them in the logical order in which they can occur.
  • Critical path analysis is the process of analyzing any schedule, no matter how it was originally developed – traditional CPM, resource-leveled critical path, CCPM, agile, or darts at a dartboard – in order to make improvements.

If the duration of the project is significant, then it is always important to perform critical path analysis, because every project’s duration will be exactly equal to its actual longest path, or what in the construction industry is referred to as its as-built critical path (ABCP). That path may include activities, constraints, resource bottlenecks, sprints, stumbles, dropped batons, rework, or any other type of delay. But the analysis of those delaying factors should always be a prime concern of the scheduler and project team.

And although there is certainly value to be gained through a post mortem process, mightn’t there be even more value in doing it while the patient is still alive?

Why is critical path analysis so important? Because:

  1. On the vast majority of project investments, expected value/ROI is impacted by completion date. Earlier completion usually leads to:
  • Greater total value;
  • Faster generation of that value; and
  • Elimination of the risk of later completion!
  1. If there is value in shortening the project duration, that can only be accomplished by reducing the length of the longest path.

So what is the most important metric of critical path analysis? It’s certainly not float, either total or free. Float is a measure of the extra time you’ve got, and is (almost always!) on activities that are, specifically, off the critical path.

If critical path analysis is intended to increase the value of the project investment by shortening the schedule (perhaps up front, perhaps after slippage), then the most important metric is surely one that applies to the longest path! It’s the one that will help the project team to identify how much time each critical path activity, constraint, resource bottleneck, sprint, stumble, dropped baton, rework, or other delaying factor is currently adding to the remaining project duration! It’s the one that, when changes are made to pull in the longest path thus making another path longest, will identify how much time each item on the new CP is delaying completion! And when you make changes on that new CP and are now constrained by yet another longest path, will quantify the delays that its items are causing!

That metric is critical path drag, and I maintain that it is, by far, the second most important (critical?) metric in critical path analysis. Why only the second most important? Because the most important is drag cost, i.e., by how much is the drag of a critical path item reducing your project’s expected value. That is the most important metric because that’s the one that will allow the project team to optimize the project investment (the ultimate goal of every project!) by justifying the cost of resources by $X to reduce the drag cost by $2X! But of course you can’t get drag cost until you’ve first computed drag.

Let me make one point clear: Steve Devaux did not invent drag! Drag is always there, and has always been there – on the items (activities, etc.) on the longest path of every project, going back to the building of the pyramids and before! We can compute it or we can ignore it – but it’s still there! All that I did is figure out the rules for computing it as I helped my consulting clients compress their schedules. How did I figure it out when others hadn’t? Because as an engineer in one of my corporate classes said to me about five years ago: “Y’know, Steve, you have an amazing grasp of the glaringly obvious.” And critical path drag and its value as a metric is glaringly obvious!

So why is critical path analysis, for the most part, not being performed? Because the project management community, more than half a century after the initial principles of CPM were published, 16 years after the first edition of my Total Project Control book came out, six years after Bill Duncan’s article “Scheduling Is a Drag” appeared at ProjectsatWork.com, three years after Defense AT&L Magazine published “The Drag Efficient: The Missing Quantification of Time on the Critical Path”, five years after Spider Project released a software version that computes critical path drag, and two years after I presented this webinar for PMI’s Scheduling Community of Practice, remains blissfully unaware of the key enabling metrics.

So I conclude with four questions:

  1. Despite the fact that so many people pay lip service to critical path analysis, why would anyone perform it on a network of 1000+ activities when their software does not support the metrics that make it valuable and simple?
  2. Why would project management professionals perform such analysis when the supporting metrics are not in PMI’s PMBOK® Guide, nor in its Scheduling Standard, nor in any of IPMA’s published methodologies?
  3. Why do software companies and project management professional organizations not support/publicize the metrics that enable this analytical tool that is fundamental to the discipline of project management?
  4. Why do slipping project schedules so seldom recover?

If you want to learn how to compute drag and drag cost manually, check out the exercises (with answers) on under the EXERCISE tab at the top of the page.

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

“Delay always breeds danger”

“Delay always breeds danger; and to protract a great design is often to ruin it.”

Miguel Cervantes, Don Quixote

Chesswithdeath

***

There is no lack of historical and literary quotes, going back centuries, about the cost of time. And yet in our 21st century, rare is the project on which the value/cost of time has been estimated, or is tracked on project progress reports. And rarer still are those projects where that estimate is known by members of the project team.

There are exceptions. In my experience, every member of a team executing a refueling shutdown of a nuclear power plant knows exactly what the cost is of each day off-line. In the US, it ranges from $400K to $2.5M depending on the grid and the size of the plant. Oil and gas refinery maintenance projects are managed in much the same way. It is surely no coincidence that these industries run their schedules with greater discipline than any other.

There are other projects where the cost of time is even greater: new pharmaceuticals or medical devices, smartphones, and other products for the commercial market have their revenues hugely impacted by the duration of their development projects. Additionally, on many projects, the cost of time can be measured in lost human lives: hospital construction, healthcare information systems, emergency response, vaccination programs. Yet on all these, no one bothers to quantify the value/cost of time, to optimize the schedule (using critical path drag) based on that cost, nor to disseminate that information to the team members who are often the very people who can use it to compress the length of the critical path.

Recent posts on this blog have led to discussions in other forums about the need for computing the value/cost of time on projects. Some have argued that such cost is often insignificant.

  1. First, if finishing earlier or later on a given project will have little impact on its value, that very fact is vital information! Let such a project take an extra month or three – what difference would it make? Why would we assign resources to such a project if they could be assigned to another project where time is valuable (and there are plenty of such projects!)? We’ll get back to that time-insensitive project eventually. Oh, you say, but if we wait too long, a delay of maybe two months, time will become important. Okay, then, tell us the value/cost of time after that two-month-delayed target date, and we’ll plan our critical path to achieve that. Meanwhile we’ll use our resources on projects where time is
  2. But there is a much more important factor. Unless adequate business analysis is performed on a project, how do we ever know that time “isn’t that valuable”? And the value of time is often grossly underestimated! It can include:
  • The inability to use the product of the project, and thus generate its expected value, until the project is finished. This can be tremendously valuable, especially if that project is what in my book Managing Projects as Investments I term an “enabler project”. On pages 25-36 of that book, I explore all the hidden cost of delays on enabler projects. The value/cost of the time that the enabler’s critical path requires is multiplied by its impact on how soon all the enabled work can start creating value. Yet enabler projects, which are uniquely valuable and uniquely sensitive to time, are rarely even identified as such and almost never planned, scheduled and optimized in a way that befits their value.
  • The “marching army costs”, of overhead and project LOE activities and opportunity costs, that accumulate as long as the project continues. Until the project finishes, we have to feed, clothe, and shelter the “army”, and the soldiers can’t go off to till the soil, raise a crop and feed their families for themselves! Marching army costs on large US Government programs can run anywhere from 10% to 20% of the weekly “burn rate” of costs. But interestingly, on smaller labor-intensive corporate projects (just the sort that have made no attempt to estimate the cost of time and therefore aren’t doing rigorous schedule analysis), the cost of overhead can be even greater! The cost of the “overhead burden” for a programmer in a big city office building, for example, is often estimated to be 100% of salary. All else being equal, any time that this type of project can be shortened by a week and the resources assigned to other valuable work, the savings can be estimated at about 50% of the concluding burn rate of that project. And that can be substantial.
  • The retirement of risk of being late! Even on that small percentage of projects (and to the customer/sponsor, it’s small!) where there is no added value from finishing early, there is often huge cost to finishing beyond the target date (yes, I hate the term “deadline” for reasons I discuss in my book). 99% of the risk of being late is retired whenever we finish early. (And that is another reason why schedule compression to create schedule reserve, and then not needing to use it, is so valuable!)

Estimating the value/cost of time is something that needs to be included in the documentation for every project initiation. Yes, it’s only an estimate – but so is pretty much everything else at the start of a project investment! This is what will give the project manager and team the ability to do their jobs better – to provide the sponsor/customer with the greatest possible expected return in value on the project investment.

And yes, critical path drag is an important technique in that effort. But even more important is the computation of drag cost which the estimate of the value/cost of time will enable, pushing the cost of project time down to the individual activities and resource bottlenecks causing it.

I will write more about these topics in the coming weeks. But you can get it all in more coherent and comprehensive fashion in Managing Projects as Investments. And if anyone has read that book and wants to discuss anything about it on this site, I will be only too pleased.

Fraternally in project management,

Steve the Bajan