Estimating the Cost of Time When Ain’t Nobody Told Ya!

“Time is a long rope.”

                                                        – Another old Bajan proverb (We got a ton of ’em!)


Okay, so from the discussion in my recent blog posts Time Is a Cost Even When Nobody Says How Much and Project Managers Should Revel in Time Analysis!”, estimates of the expected monetary value of the project and of the value/cost of time should be the responsibility of the sponsors/customers, those who are investing in the project in hopes of a greater return in value. That return is almost always impacted by completion date – acceleration usually adds value and delay subtracts value. And it is those in the trenches, the project managers and SMEs on the team, who can see how to use that information to eliminate drag and maximize the expected value of the project.

But what if the sponsor/customer doesn’t understand how important this information is, or how to build incentives around schedule into the charter or contract? What if the sponsor/customer relies on the customary but often deeply damaging artifact known as the deadline?

As we saw in the last post, a project manager knowledgeable in critical path analysis (and especially in the new metrics critical path drag and drag cost), can demonstrate his or her value by making trade-off decisions that maximize value to the sponsor/customer. But if that information is not provided, what can the project manager do? One of the sharpest arrows in her quiver is largely negated.

The cost of time is different on every project, and the factors that go into generating an estimate vary considerably by application:

  • Market window and order-to-market in commercial new products.
  • Inability to generate revenue due to a maintenance shutdown of a major piece of equipment (e.g., power plant or refinery).
  • The value of lives saved in healthcare, and lives and property saved in emergency response.
  • Delay in using the product of a project due to later deployment.
  • Delay in the schedules of other projects in the program due to later completion of an enabler project.
  • Retirement of the risk of being late when a project is completed early.

In the LinkedIn discussion group The Project Manager Network, Norman Patnode made a very interesting comment, suggesting that the cost of a unit of time on new product development projects could be approximated as the projected average revenues for a similar unit of time for the peak sales year. This is very interesting to me and I’m hoping to discuss this at length with Norman. But that still leaves us needing to estimate the value/cost of time on all the other types of projects.

Let us take as an example one of the more difficult projects for which to estimate the value/cost of time: implementation of an organization-wide software system such as SAP, Oracle or Peoplesoft. What would it be worth for every unit of time that such a project is accelerated or delayed?

We don’t know. Someone may have a general idea – perhaps the senior managers who approved the project. But even if they do, they have seen fit to leave us in the dark.

It is in a case like this that I recommend doing some back-of-the-envelope calculations designed to generate a very conservative estimate. This estimate can then be used to raise the topic with the sponsors/customers in order to generate a more precise estimate.

So we don’t know the value/cost of time on our ERP system project, or even how much value the whole project is expected to generate. But even while being kept in the dark, the project manager typically knows two items of information:

  • She knows the budget – let us assume $5M.
  • She knows the target duration or “deadline” – let us assume 12 months.

There is one more thing she may know – the “payback” period that is customarily used in her organization to justify new systems such as this one. Capital equipment such as blast furnaces may have a required payback period of as much as 40 years – but that certainly isn’t the case with software systems! Any software system that isn’t obsolete in three years will be in five – and those are the two most common payback periods for such systems.

If the project manager knows that the system was likely justified on the basis of a three-year period, she should use that – but otherwise, I advise going with five years. Remember, we’re looking for conservative numbers, just to get the discussion started.

If the budget for the project is $5M, the one thing everyone knows is that the value it is expected to produce will be more than $5M, because every project is an investment and no one knowingly makes an investment that is expected to generate less value than it costs.

Five-year rates on US Treasury securities are currently about 1.5%. But projects are much riskier investments and also may require paying state taxes on any increased profits. Indeed, it is hard to believe that any organization would invest in this new system if it didn’t expect a real (i.e., inflation adjusted) return of at least 4% per year. If you think your project is expecting a lower annual return than that, use your own number – but I think 4% is pretty conservative.

4% per year over five years is 20%. 20% of $5M is $1M. That means that a very conservative estimate of the project’s value generation is $6M over 60 months, or $100,000 per month or about $22,000 per week. Without other information (such as knowledge of a likely spike or cliff in the value generation at some point), it seems reasonable to assume that a week’s delay on the project will result in one week less operating time to the same point of obsolescence, resulting in a reduced expected monetary value of $22,000. And a week of acceleration would add a week before the same point of obsolescence and thus increase value by $22,000.

That is the information that may allow the project team to justify additional resources on the critical path, such as by adding $10,000 of resources to eliminate an activity’s three weeks of critical path drag, increasing the project’s expected value by $66,000 at a cost of $10,000.

Of course, the project manager should not simply spend that extra money on her own initiative. Instead, she should incorporate these calculations in a memo to the sponsor/customer.

“Here is what the minimum cost of value/time on this project seems to me to be. If I know this, I think I can find opportunities to generate added value. Do these numbers seem about right, or is there another estimate of the value/cost of time you’d like me to use?”

And, as likely as not, the reply will come: “Oh, no! The value of time on this project is much more than that! I’d put it at around $50,000 per week. If you can save any week by spending a lot less than $50,000, please let me know immediately. Oh, and good work!”

And that is how a project manager gets a reputation for adding value.

Fraternally in project management,

Steve the Bajan

3 thoughts on “Estimating the Cost of Time When Ain’t Nobody Told Ya!

  1. Hi, Mike. Good question — thanks!

    Liquidated and ascertained damages (usually called “LDs” in the US) are certainly a large part of the cost to the contractor of being later than the contractual date. But LDs are rarely the only cost — there are often additional legal and administrative fees (schedule forensic experts?), loss of future business with that customer or others, etc.

    Also, LDs often only allow the customer to recoup a part of the damage — the actual cost of late completion is often greater, at least in the US. And LDs (or lack thereof) don’t indicate the potential value to the customer of earlier completion of the contractual date. (Even contractual bonuses for earlier completion often don’t fully reflect that value to the contractor, as the good reputation gained thereby also can have great value.)

    And, of course, there are almost never LDs at issue on the implementation of a software system for a corporation.

    Fraternally in project management,

    Steve the Bajan


  2. Steve,

    As you are aware, Liberzon has spoken about having a single success criteria in a project for some time and one of the examples he gives is getting the time variable and the cost variable and transforming it in one single cost/per day variable. That is somehow what you are showing and giving an example of how calculating this cost/per day, I supose.

    You are also familiar with Mr. Liberzon´s tool Spider and the use of hammocks that can assist us in gathering attention of high management. A hammock is an activity held by something that determines its start and end, so we can have one from day one of the project to the last one, for example.

    If we add to this hammock all the resources and cost factors that can be calculated per hour, this hammock has the ability to give the modeler the opportunity to determine that any resource applied to the hammock will be used some place else at any time. So, only the “non-working” time will actually remain in the hammock.

    So, if I have a project of 30 days an a tech guy from day one to day 30 getting 10 USD per hour, with a 30 day calendar of 10 hours a day we will have spent with this tech guy a total of 3000 USD.

    However, If I apply the same resource to other tasks that demand, let us suppose 5 hours per day, we now have 1500 USD that is “actual work” and the remaining is the “waste money”.

    With that in mind, using drag calculations or doing resource optimization or any other mean of reducing the total duration of the project, we will shorten the ammount of days this hammock will calculate “wast money”. This will give you the opportunity to try alternative approaches. You may pay some extra hours in some days and spend more money, but in the end you would reduce the total duration and have it clearly calculated in the hammock the return in that investment.

    You can even calculate penalties to be applied in the project and simulate it togehter, so you can compare the cost of being late x the money to crash it x the money saved by early conclusion.

    I was very happy to see Drag brought into Spider and I guess that summing methods and tools we can all make a difference in increasing benefits to the end customer! Should we try to organize an example together where we could study the drag effect and the application of hammocks?


    Peter Mello, PMP, PMI-SP, SpS
    The Spider Team / Brazil


Leave a Reply

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

You are commenting using your 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