Why Won’t We Recognize the Value/Cost of Time on Projects?

A few weeks ago, I engaged in an Internet discussion with a very knowledgeable project management thought leader. Make no mistake – this is someone for whom I have a great deal of respect. But when the topic of the cost of time on projects came up, he was dismissive, stating that the value of early completion on most of the projects on which he consults is very small or non-existent.

Let’s think about this: for several years, he has been residing overseas and consulting on projects many thousands of miles from his home. And his consulting fee is definitely not cheap! How important would a project (or program, or portfolio) have to be in order to justify the fees of such a consultant? How large its budget? How great the expected value of the investment?

One of the fundamental aspects of any type of investment is that the length of time to “maturity” is a key variable. The return/benefit that any smart investor will demand is always based in part on how long the wait for that return is likely to be. (There’s an old Bajan saying: “Wait is a heavy load!”) The longer the wait, and the more money that will be “tied up” in that investment, the higher the rate of return that the investor will demand as justification for the project/investment.

One thing of which you may be sure: organizations do not engage expensive overseas consultants to work fulltime on a project with a million dollar budget. Whatever the projects/programs on which this consultant has been working, the budgets are almost certainly over $10 million, and likely over $50 million.

Let’s take conservative numbers: even at just 3% interest, the cost of tying up $10 million is $300,000 per year. That’s $25,000 per month. For a $50 million project, that would be $125,000 per month.

And that does not include:

  1. The opportunity cost of not having that money to invest elsewhere sooner.

  2. The risk of taking longer than planned, a risk that is retired immediately if the project finishes early. Almost everyone would agree that there is a significant cost to finishing most projects late. How much is it worth to eliminate that particular risk?

  3. The “marching army” costs of overhead and level-of-effort activities to support the project. These costs often add up to 10% – 20% of the total cost of a large project. These are costs that continue, week after week, until the project ends. Finishing earlier usually truncates these costs.

  4. The very large reduction in value if the project in question happens to be an enabler project. This is a topic I cover extensively in my book Managing Projects as Investments: Earned Value to Business Value. A delay on an enabler project means a postponement in the value delivery on all the other projects that it is enabling. For example, inkjet printers are often sold at break even or less – their profit comes from the ink cartridges whose sale they enable. Delay printer production and you delay cartridge revenues.

  5. The loss of flexibility that a shorter schedule would allow. Blake Sedore pointed this out to me in conversation: a shorter schedule can sometimes have value not so much by finishing earlier but by allowing the project (or manufacturing process) to start later! This delays committing to a specific strategy and maintains flexibility – perhaps the extra time will allow for better targeting of product scope, or even permit cancelling the project if a sudden change in market conditions makes it no longer a sound investment. (I plan to discuss this interesting idea further in an upcoming blog article.)

(I make no pretense that the above list includes every possible benefit that a shorter schedule would bring — but it’s a start! If you have any additional benefits to a shorter project schedule, please go to this discussion thread in the FORUM and list some of them. perhaps together we can create a useful checklist.)

So why did this very competent consultant not recognize the value of a shortened project duration? It’s simple – he wasn’t looking for it. The PMBOK Guide ® does not discuss the value of project acceleration. The vast majority of project management software provides no field that allows the user to enter a value/cost of time, either acceleration or delay. (And that omission combines with the almost universal failure of software to compute critical path drag to prevent the crucial calculation of the drag cost of critical path activities, a data item that can justify added resources.)

So is it possible, however unlikely, that on the consultant’s specific projects there was no value to the sponsor/customer of an earlier finish? Absolutely! There are indeed projects where there is no advantage to a shorter schedule. There are even projects where finishing earlier has a negative impact on the project investment! (This is particularly true if a project is not on the critical path of the program of which it is a part. For example, early completion of a satellite to be launched on a rocket does nothing to shorten the program if the critical path goes through the preparation of the rocket. The satellite project would have no drag on the program’s critical path, so that finishing it early would only increase its program float, as well as perhaps require additional storage.)

However, such projects are so unusual that it becomes all the more important to clearly identify these exceptions to the rule. It is critical to perform the necessary cost/benefit analysis for earlier completion, taking into account all of the issues I’ve mentioned above, and more. If after all that analysis there really is no advantage (or perhaps a disadvantage) to the sponsor/customer from an earlier completion, that fact should be made known to key team members: “This is one of those rare instances where we won’t be looking to shorten the project!”

But the rule should always be to analyze and quantify the value/cost of time and, if there is a contract involved and value to early delivery, to seek a win-win arrangement: an early completion incentive to the contractor based on a portion of the value to the customer of such a happy result.

Have a great weekend!

Fraternally in project management,

Steve the Bajan

Blake Sedore Blog on Drag Cost: Applying Critical Path Drag in Manufacturing

The first-ever Guest Blog is now up at the Total Project Control website, available for reading and discussion. It is by Blake Sedore, the manufacturing engineer whose recently published MIT thesis on using critical path drag analysis to accelerate semiconductor production and increase throughput has received a ton of attention. You can click on the Guest Blog here, and also make comments or ask questions of Mr. Sedore in the discussion FORUM on this site.

In this Guest Blog, Mr. Sedore explores the experience both for himself and his customer of recognizing the opportunities for improvement pointed about by the drag analysis:

“The results of my project were quite eye opening, both for me and for my client, and I believe that this effort shows that the critical path method and critical path drag have a strong application to the manufacturing industry.”

And he goes on to write:

“I have come to realize that the analysis has the potential to go much further. MUCH FURTHER. The analysis does not end with calculating the critical path drag – this is actually just the beginning. The drag is merely a stepping stone to get to drag cost, which is the metric that truly matters, as it allows you to determine the impact that the drag of a critical path item has on the bottom line.”

And he goes on to discuss how the drag cost savings opportunity offered by reducing Work in Progress:

“And in manufacturing, when you repeat the process again, and again, and again, and again, and again…that drag cost is going to add up. BIG TIME.”

Mr. Sedore’s thesis article  “Assembly lead time reduction in a semiconductor capital equipment plant through constraint based scheduling” can be downloaded from the MIT website here.

Read his entire Guest Blog and post questions for him in the FORUM thread.

Fraternally in project management,

Steve the Bajan

What’s Costing Time? CPM vs. Critical Path Analysis

The most recent article on this blog, regarding the MIT paper about using critical path drag to optimize manufacturing throughput, generated a number of interesting reactions. First, it has been very popular, attracting well over 100 views per day and several “Likes” in the LinkedIn discussion forums where I mentioned it. However, some people seem to have negative views about the value of such a process. All these people seem to be conflating critical path analysis and CPM and they specifically reject CPM as a worthwhile scheduling technique, expressing a preference for critical chain scheduling or one of the flavors of agile methodologies.

So let me try to improve my communication technique: there is an important difference between CPM and critical path analysis!

  • The former is a technique for developing a schedule for a project, and is almost always performed upfront.
  • The latter is a technique to analyze the detailed aspects of any process (like manufacturing), project or program, upfront, during progress, or after completion, with the purpose of identifying, measuring and perhaps reducing the total duration of execution.

Why should we want to reduce the duration of a process or project? Because, to paraphrase what a really smart guy wrote over 260 years ago: “Time is a whole lot of benjamins!” If we start recognizing that all projects and programs are, as my book emphasizes, investments, then we will quickly conclude that two major factors that impact project investment value are:

  • Scope; and
  • Total duration.

Along with that important but often over-emphasized third constraint of cost, these are the parameters over which project teams have some control, and that project and program managers are paid to manage. And we control completion date through the critical path – of any process, project or program!

Whether a project is scheduled using “naked” CPM or resource leveling or critical chain or agile or darts at a dartboard, at the end it still will have an “as-built” longest path (comprised of activities, constraints, sprints, stumbles, dropped batons, feeding buffers, schedule reserve, hesitations, and any other delays) that always determines its total length. Surely if time has value (as it does on 99% or more of projects!), then it must be worthwhile analyzing:

  1. What items are extending the duration (i.e., have critical path drag)?

  2. By how much?

  3. How much is that extension reducing investment value?

  4. What might we be able to do to reduce that negative impact?

traffic jam

It doesn’t matter what method of scheduling we used! Even a serial string of sprints, if analyzed, will usually reveal a place where we can shorten the critical path by adding a resource, or dividing the process into parallel streams, or deciding not to include functionality whose value-added is worth less than the time it consumes (i.e., its drag cost). And if someone says that doesn’t happen, how do they know unless they do the analysis and determine which sprints/activities/resources/rework have how much critical path drag?

If some item that you need to perform your project is really expensive, wouldn’t you try to see if you could get it for less? Well, how is that any different from using critical path analysis to identify the big drag cost items and seeing if you can perform them for less?

That is part of the beauty of Blake Sedore’s analysis for his MIT Master’s thesis. It’s entirely possible that the manufacturing organization was comfortable with their process, and felt that it was optimized. Then he performed the critical path analysis, identified where the drag was, figured out how to reduce it, and voila! – throughput and value were increased!

Whatever the scheduling method, critical path analysis has always had value. I remember reading an article over 20 years ago about how Motorola used it to increase throughput on the shop floor of their pager division. But the enhancement of critical path drag computation puts the emphasis where it belongs: not on what can take longer without causing delays (i.e., float), but on what’s causing how much delay. The technique for computing it is straightforward, if somewhat brain-intensive in a complex process or project.

A process that is both brain-intensive and can add a lot of value – gee, that sounds like just the sort of thing software packages should compute!

Fraternally in project management,

Steve the Bajan

New MIT Paper: Using Critical Path Drag to Optimize Manufacturing Throughput

Eureka! Through the wonders of Google, I have just discovered a new paper describing the practical application of the critical path drag metric to optimize a manufacturing process. The paper is by Blake Sedore and the paper was his thesis for his Master’s of Engineering degree in Manufacturing. It’s titled: “Assembly lead time reduction in a semiconductor capital equipment plant through constraint based scheduling.” You can find the abstract through the Massachusetts Institute of Technology website at the URL below. You can download the complete PDF file by clicking on the download link at the end of the abstract.

http://dspace.mit.edu/handle/1721.1/93851

Manufacturing semiconductors

As far as I know, this is the first time that someone other than yours truly has analyzed a manufacturing process using this metric, and certainly the first time someone has written a paper about it. The paper is 83 pages long and, by my count, mentions drag about 37 times.

From the abstract:

“A preliminary build schedule was developed that prioritized critical path procedures. A trial of this build schedule achieved an assembly lead time of 39 hours, resulting in a 70% reduction from the current average of 5.5 days. This trial was also accomplished with 76% of the average labor hours for assembly. A production build schedule with a lead time of 43 hours was developed based on the trial results. This schedule allows for production rates of up to 5 machines per week to be achieved with the current shift structure of the company, without the incurrence of overtime. A critical path drag analysis identified critical procedures with the highest potential for lead time reduction. The highest drag of a critical path item was 260 minutes, accounting for 10% of the assembly lead time.”

In the paper, Mr. Sedore then goes on to describe how he analyzed the possible ways of reducing the drag and made recommendations based on considerations of greatest drag reduction, lowest cost of additional resources, and shortest disruption of the manufacturing process. This last item seems to me to be a new enhancement in the application of critical path drag analysis specific to the manufacturing industry, and I am very excited about it!

I contacted Mr. Sedore and asked him about his experience calculating drag “manually”, as the critical path software he was using (MS Project), like most, doesn’t perform the calculation. He said that it gave him some trouble until he laid it out in Gantt chart form, when the drags on the critical path became more obvious. He also agreed that it would be so much easier if only the software would compute it!

A Gantt chart is usable on a manufacturing project which is likely to consist of no more than a couple hundred steps. But for a project with over a thousand activities, I have found network logic diagrams (aka PERT charts) to be necessary (provided I am not using Spider Project which computes drag automatically). But it’s certainly high time that MSP, Primavera, MicroPlanner, Asta, Safron and all the others started including this functionality. (They will eventually – but when?)

Seeing drag analysis being used by engineers at the most prestigious engineering university in North America is extremely exciting to me! Yes, it should be used by all project and program managers – but it also should be standard usage for analyzing and optimizing circuit board design, software algorithm optimization, disaster emergency response: any procedure with integral steps. Maybe Mr. Sedore’s article will kickstart its usage in manufacturing.

I have invited Mr. Sedore to write a short guest blog for this website about his experiences in using drag analysis. I hope he will do so some time in the next few weeks.

Fraternally in project management,

Steve the Bajan