New paper on drag just published in Portuguese

I was not able to publish any articles or puzzlers this week due to having been summoned to teach at UMass Lowell at the last minute. The father of one of my colleagues passed away on Wednesday and so I had to fill in Wednesnight through Friday. The students were great and, as usual at UMass Lowell, the experience was entirely positive — but it did prevent me from posting any articles.

However, I can point readers from Brazil (and Portugal) to a new article on critical path drag that I wrote at Peter Mello’s invitation for publication in the Mundo Project Management blog. It is titled “A Importância das novas métricas “Drag” e o “Custo Drag” na Análise do Caminho Crítico” (Peter was kind enough to translate it into Portuguese).

I hope to have the English version up on this site within the next couple of days — but it’s just possible that Peter’s version is so much better than mine that English readers would be better off with this Google Portuguese-to-English translation of his version!

Meanwhile, I hope my Portuguese-reading friends enjoy the article. And that most readers are in places that are warmer than here in Massachusetts! We’re also due for another 3 to 6 inches of snow Sunnight into Monday, which should break our all-time record for a winter with all of March still to go.

Fraternally in project management,

Steve the Bajan

Justifying Resources through the DRED: How to Repeal Brooks’s Law

There is a famous quote from Frederick P. Brooks Jr., author of The Mythical Man-Month, that has come to be known as Brooks’s Law. The quote is: “(A)dding manpower to a late software project makes it later.”

Although Brooks himself called his law an “outrageous simplification,” there is some truth in it. And it is often taken as though it were gospel, on all activities and projects irrespective of the nature of the work: “What do you mean you need more resources? Don’t you know about Brooks’s Law? Adding resources to a project just makes it take longer!”

There certainly are types of work and situations where adding resources will delay completion. In certain situations work such as software coding, writing documentation, and, as I discovered on a consulting gig about ten years ago, doing installation work in the cockpit of a jet fighter can all be subject to such constraints. And there are undoubtedly many other such cases. But I don’t think one should accept it as gospel for even the majority of work situations. Try lifting a refrigerator or a long table up a couple of staircases by yourself and then tell me that employing an additional pair of hands wouldn’t have been more efficient!

The impact of varying resource levels on an activity’s duration is called the activity’s resource elasticity: how much it will contract or expand in response to more or fewer resources. This is a very important consideration when looking to compress a project’s schedule. Some work is very resource elastic, some is a little so, some is not at all and some is negatively so. From a scheduling viewpoint, it can be very valuable to know what the resource elasticity is of each activity, especially those on the critical path with substantial amounts of drag and drag cost.

One of the planning techniques I have used on consulting assignments is to obtain a secondary duration estimate from the SMEs based on the following question: “I have no idea if I can — but if I could get you double the resources you currently have, how long would the activity take?” (Notice: I don’t ask “How resource elastic is your activity?” which would simply beg for the response: “Huh? What the heck’s that?”)

The estimate this question generates is the doubled resource estimated duration, or DRED. It is not intended to trigger some kind of automatic increase in resources and corresponding schedule compression. Rather it is simply to provide, in terms that anyone can understand, an indicator of how resource-elastic the activity might be.

Most project management software packages can store a secondary duration field. Then if it turns out, either upfront or during implementation, that an activity with lots of critical path drag and drag cost is very resource elastic, it may identify a suitable target for efficient increase in resources.

But not without first going back to the SME and re-establishing both that the increased resources would be beneficial AND that we know the right amount of additional resources. (Maybe a 25% increase will give us as much benefit as a 100% increase, so why spend the extra money?)

DRED Graphic

There is a range of possible DREDs for any activity. For 20-day activities, DREDs might look follows:

5 days: Very rare, but it can occur as a result of not having optimum team size – toting that refrigerator upstairs is one example – I bet two people get it done in 25% or less of the time that one person would take!

10 days: Said to be “perfectly” resource elastic — the number of estimated workhours is unchanged and thus implementing the DRED may cause little or no negative cost impact.

13 days: More common than 10D in my experience. Some negative cost impact, but still usually a good way of reducing drag cost.

17 days: A small improvement. It may be useful if the drag cost is great, but not if it’s small.

20 days: Not at all resource elastic.

30 days: Negatively resource elastic. However, sometimes using entirely different kinds of resources can help.

Once the initial schedule has been generated and the drag and drag cost of each critical path activity have been computed (we are doing those calculations, aren’t we?), the project manager/scheduler should look at the DREDs of those activities, see which might benefit substantially from added resources, and then check back with the activity managers/SMEs who generated the estimates.

“You said you could get this activity done 10 days faster if I got you two more programmers and one more mechanical engineer. I just want to confirm that this is correct?”

“Actually, Steve, I’d really only need another mechanical engineer – that’s the constraining resource. But I don’t think you’re going to be able to get one!”

“Let me see what I can do.”

And then I go and make the case that I can potentially shorten the project by 10 days, at an expected value of $20,000 per day, by getting one additional M.E. for three weeks. If that M.E. is located anywhere in the organization, he’s going to be assigned to my project! (That is, of course, unless the manager of another project where time is even more valuable is using the same techniques and needs that M.E. at the same time.)

Finally, since multitasking has become so much more prevalent in the business world than it was back when Mr. Brooks worked at IBM, it is good practice to periodically examine all activities with critical path drag and drag cost for their level of resourcing. If any such activity has only part time resources, its resource elasticity should be examined. Why would we ever limit a critical path activity with large drag costs and a generous DRED to a 25% or 50% resource assignment? That’s just one more inefficiency that these new techniques for critical path analysis can identify, measure in financial terms and, perhaps, alleviate.

Fraternally in project management,

Steve the Bajan

Answers to the Weekend PM Puzzler: Where to Use Added Resources? (Next article)

First, if you have not yet tried this past weekend’s PM Puzzler, it’s not too late. Just scroll down through my blog to the next article before you read the answers below.

Next, my congratulations to all who even attempted to answer the questions on this PM Puzzler. Knowing how to figure out these types of answers is important! And those who tried but got it wrong have demonstrated a willingness to try to compute new and valuable information. I will be only too delighted to help you master these calculations.

Of course, this information is exactly what project management software should calculate – that’s why those things are called “computers”! Again, if your company’s software doesn’t currently compute drag and drag cost (not to mention expected project profit and the DIPP), urge your provider to start including this functionality.


Of course, I don’t know how many people actually tried the puzzle, but just didn’t enter their answers in the forms below the exercise. However, as of 3:30pm US East Coast Time:

  • Thirteen people entered an answer for the first question “1. On which ONE activity would you spend the extra $100K?” and five of them got it correct. Congrats, you five!
  • Eleven people entered an answer for the second question “ How much more expected project profit (EPP) will the project have as a result of your decision to spend that $100K (or not to)?” No one got it correct.
  • Nine people entered an answer for the third question “ The Starting DIPP for the project with the 54 day schedule was $800K divided by $400K = 2.0. What will the Starting DIPP be if you made the correct decision?” And nobody got this one correct.


Question 1: “On which ONE activity would you spend the extra $100K?”

Solving this problem (like almost any problem that involves shortening a project schedule!) should start with computing the drag of the critical path activities. I have computed each in the network diagram shown below.

Answers to PM Puzzler network exercise drag calculations

  • Activity A, with nothing else in parallel, has drag of 2W due to its duration. Cutting its duration by 50% would therefore reduce the project duration by just one week.
  • Activity D has drag of 4W, constrained by the total float of the parallel activity with the least total float, i.e., Activity E with total float of 4W. Cutting Activity E’s duration of 8W by 50% would therefore reduce the project duration by the full four weeks of its drag.
  • Activity I has drag of 6W due to the sum of the lag-plus-total float (0 + 6) of its start-to-start successor Activity H, which is less than the total float of any of the parallel activities. Cutting Activity I’s duration of 12W by 50% would therefore reduce the project duration by the full six weeks of its drag.
  • Although all of Activity M’s parallel activities have either 8W or 10W of float, (note that E and H are not parallel but ancestors and P is a descendant, all sharing a path with Activity M), its duration of 4W constrains its drag to 4W. Cutting Activity M’s duration of 4W by 50% would therefore only reduce the project duration by two weeks.
  • Activity Q, despite its duration of 24W, has drag of only 2W due to the TF of parallel Activity P. Therefore even though Q’s duration could be cut by 12W, only two of those weeks would be drag. The impact of such a reduction in Q’s duration would be merely to give it 10W of float! Cutting its duration by 50% would therefore reduce the project duration by just two weeks despite its juicy duration being twice as long as that of any other critical path activity.
  • Finally, Activity S, with nothing else in parallel, has drag of 4W due to its duration. Cutting its duration by 50% would therefore reduce the project duration by just two weeks.

Question 2: How much more expected project profit (EPP) will the project have as a result of your decision to spend that $100K (or not to)?”

At the original schedule of 54 weeks duration, the project’s expected monetary value (EMV) was $1M minus $200,000 for the delay cost of two weeks beyond 52 weeks, or $800,000 on a budget of $400,000, for an EPP of $400,000. By spending an additional $100,000 on Activity I, the project’s expected completion will be pulled in by six weeks, from Week 54 to Week 48. The first two of those weeks will erase the delay costs of $100,000 per week, or $200,000. The remaining four weeks of acceleration will result in increased value of $50,000 per week, or an additional $200,000. Thus the EMV will increase by a total of $400,000 to $1.2M, while the cost increases by $100,000, from $400,000 to $500,000. Increased EMV of $400,000 for a cost of $100,000 means an increase in EPP of $300,000, from $400,000 with the 54 week schedule to $700,000 with the 48 week schedule. (No one got this correct, which, considering the extensive knowledge and experience of many of the folks reading this blog, surely says that this sort of analysis just isn’t being done very often.)

Question 3: The Starting DIPP for the project with the 54 day schedule was $800K divided by $400K = 2.0. What will the Starting DIPP be if you made the correct decision?

The DIPP is simply (EMV plus or minus acceleration premium or delay cost) divided by cost estimate-to-complete. If the EMV at 52 weeks is $1M and the acceleration premium for finishing four weeks earlier (48 weeks) is $50,000 per week, the EMV of the project with its new 48 week schedule will be $1.2M. At the start of the project, the Cost ETC is the budget, now $500,000. The Starting DIPP with the new schedule will therefore be $1.2M divided by $500,000, or 2.4.

Notice that this is up from the 2.0 before assigning the additional $100,000 to resources for Activity I. This is how we can now justify additional resources on specific items if we know the value/cost of time. And during project execution, we should track and attempt to maximize the DIPP as the prime metric of our project investment.

If there are any comments or questions about this exercise and the answers, I will be delighted to answer them here. And if you found this whole exercise interesting, please pass the URL along to other people at work who might find it interesting.

Fraternally in project management,

Steve the Bajan

Weekend Project Management Puzzler: Where to Use Extra Resources?

I don’t know if I’ll be able to do it every week – but, when possible, I intend to post a “puzzler” on my blog for folks to have fun with over the weekend. So if you like exercising your brain and/or your PM skills, watch for it. And if you want an email notification when I post a new blog, now you can sign up to receive one by clicking on the FOLLOW button in the top right side of the page and entering your email address. (This should help all you folks who’ve been staying awake all day and night pressing Refresh…)

Today’s puzzler is definitely about PM skills. It deals with critical path analysis and how good decisions can be supported by the information from that analysis.

I have created a network logic diagram below. The total project duration with this schedule is 54 weeks.

If the project it displays is completed in 52 weeks, its expected monetary value will be $1M. For every week later, that value will decrease by $100,000. But for each week earlier, the value will increase by $50,000.

The main issue is as follows: the budget for the project is currently $400,000, but you also have an additional $100,000 that you can use to cut the duration of any ONE activity by 50%. On which activity (if any!) should you use the money? (Notice that the answer can ONLY be found through critical path analysis – or voodoo! And I know which one I happen to feel is the more reliable method!)

I would suggest that you start by doing the forward and backward passes through the network. But if that’s “not your thing” (some of us prefer these to Sudokus – and we LOVE Sudokus!), you can scroll down to where I have filled in the dates on the network for you. However, you will still need to do the computations, including critical path drag and drag cost, in order to answer the questions below.

I will post the answers some time on Monday.

If you like this exercise and would like to have Friday Puzzlers like this be a regular feature, please post a comment to that effect.

Fraternally in project management,

Steve the Bajan

P.S. BTW, if you want to practice your forward and backward passes and drag and drag cost calculation skills, there are these exercises on the main page of the website.

Blog blank network for drag cost and resources

To go to the network with the dates filled in, scroll down.

Blog filled in network for drag cost and resources
Now answer the questions:


What is the DIPP? (Warning! Some wonky stuff)

There is a comment by Keith Burns at the end of the Why Do We Plan Projects? article:

“I see a term here that I have not seen previously. DIPP tracking. what is it and where can i learn more about it?”

First, Keith, thanks for following this blog and for taking the time to post a comment.

Insofar as I have become known in the project management world, it’s been for adding to scheduling metrics the concept of critical path drag and how to compute it. That’s largely my fault — drag is so important to scheduling, as well as glaringly obvious once one thinks about it, that it is the concept I have tried hardest to disseminate.

But I’d like to think that, over the course of the past quarter century, I have added some other concepts and metrics. In my opinion (and I admit that some may disagree), my most important contributions have been:

  1. The idea that projects are investments; and
  2. A metric called the DIPP for planning and tracking expected project profit (or, if you prefer, expected ROI).

Keith, honestly, the best place to get information on the DIPP (and, indeed, most of my other concepts including the value breakdown structure [VBS], the cost of leveling with unresolved bottleneck [the CLUB], the doubled resource estimated duration [the DRED], the ALAP schedule performance index, and several others) is my books. The new one especially, Managing Projects as Investments: Earned Value to Business Value, covers most of the above concepts in what I flatter myself is relatively painless to read.

The DIPP was my first idea in project management, and is the basis for my 1992 article “When the DIPP Dips: a P&L Index for Project Decisions” in Project Management Journal. If you are a PMI member, you can get the article for free. Also, it was reprinted by PMI in 1999 as a featured chapter in the book Essentials of Project Control. It’s an interesting book even apart from my article, and I believe used copies are available.

Or you can get several articles that discuss the DIPP and other stuff in a six-part series I did for ProjectsAtWork on-line magazine. Just do a search on the site under my name. The site is free, but requires registration.

Finally, to describe it in a nutshell, the DIPP was originally an index for determining when to cancel a project and when to keep funding it (a poorly understood concept). But it ultimately evolved into being a planning and tracking index that integrates all three sides of the Golden Triangle.

  1. Scope is measured as the expected monetary value (EMV) of the project if completed on a certain date;
  2. Schedule is a plus or minus dollar amount based on acceleration or delay; and
  3. Cost is the cost of resources and overhead.
  • The DIPP = ($EMV + or – $accel premium or delay cost) / $cost estimate-to-complete.

The DIPP can be planned as a baseline across the schedule, with the cost ETC as the complement of the planned value (PV or BCWS). This supports an index that allows tracking of the project’s expected project profit (EPP): the DIPP Progress Index (DPI), which is Actual DIPP divided by Planned DIPP.

Any change in scope, schedule, cost or risk from what was planned would be reflected in this index, including improvement of EPP. And this extends project tracking beyond the cost/schedule realm of earned value.

Finally, Dr. Tomoichi Sato of Tokyo University has done some work extending the DIPP into areas of risk management. This paper by him, Risk-based project value analysis – contributed value and procurement cost was published in 2006.

Keith (and anyone else who was wondering about the DIPP), I hope this helps. The DIPP is a complex topic and it really takes a book to cover all of its implications and potential benefits.

Fraternally in project management,

Steve the Bajan

Why Do We Plan Projects?

There is an interesting discussion titled “Improbable Success” currently in the LinkedIn discussion group “Planners & Schedulers & Project Control Professional”. It began as a discussion of why one would ever embark on a project where the possibility of “success” was low.

First, “success” is not a valid metric for a project. Every player at the start of a poker hand or poker tournament with five or more opponents has a very small chance of “success” — but it doesn’t seem to stop them from anteing up! They recognize that “projects” are investments and as such the risk of “failure” must be measured in relative terms against the positive impact of “success”.

In that discussion, I wrote:


As one quick and dramatic example, let’s imagine that there is a fire and that five people are trapped in the building. The fire department has a project to save all five. Normally the fire trucks should be able to get there in seven minutes, in which case all five people would be saved. But due to the city having gotten six feet of snow in two weeks (yes, I am using the current situation in Boston), the streets are gridlocked and it takes the firefighters ten minutes to get there. As a result, one person dies of smoke inhalation.

Is this project a “failure” because the firefighters missed their deadline and were only able to save four lives? How about if two died? Three?

If it took ten minutes for the trucks to travel the first block so that it was clear that the four people on the top floors were all dead and the only hope was for the one person trapped on a lower floor, should the department superintendent say: “Hey, we’ve missed our deadline and at least 80% of the value of this project is gone. Just let’s turn around and go back to the firehouse.”?


The LinkedIn discussion goes on to mention the well-known military adage that “no plan survives first contact with the enemy”. If we are quoting military leaders, we should not forget the general who led the largest and arguably most complex combined military operation in history. In 1957, Eisenhower would say:

“Plans are worthless, but planning is everything. There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of “emergency” is that it is unexpected, therefore it is not going to happen the way you are planning.”

What Eisenhower is saying is that events will force changes in the plan. However, if planning has been performed properly, in a flexible format with contingencies to enable alternatives when variances occur, then the process of planning allows adjustment toward the optimal solution. This is what modern project planning, with all its flexible formats and detailed progress metrics — WBS, value breakdown structure (VBS), critical path analysis, activity-based resource assignments (ABRA), resource leveling, risk, earned value and DIPP tracking — permits and relies upon.

How I wish all those planning complex projects, but especially those whose job is emergency management, such as emergency response where large numbers of human lives may be on the line, would understand and obey Ike’s dictum! Emergency response, alas, seems to be a discipline which has little knowledge of project management planning methods. And that’s why my chapter “Time is a Murderer: The Cost of Critical Path Drag in Emergency Response” from CRC Press’s  Emergency Response Handbook, which shows how to apply project planning and schedule optimizing techniques to an emergency response, is available free on the home page of this site under the REFERENCE tab.

The truth is that the purpose of planning is NOT based in the attitude reflected in the old  tongue-in-cheek Q&A:

Q: Why do we spend so much time and effort planning a project?

A. Because when we do, we have eliminated ONE of the millions of ways the project could actually go!

The purpose is that when (not if!) things change, we can:

  1. See the variance from the current plan.
  2. Assess the impact thus far.
  3. Assess the future variance based on present impact and the current flexible plan.
  4. Perform what-if analysis based on that plan.
  5. Decide if a new course based on the current status and the flexible plan seems advisable.
  6. If advisable, implement and execute to the new plan.
  7. And do all the above much faster than if we had to start planning anew!

That’s why we plan.

Fraternally in project management,

Steve the Bajan

A President’s Day Weekend Puzzle: George Washington’s Project Schedule

I’ve been on a calendar, but I’ve never been on time.

— Marilyn Monroe


Here in the US, it is the Friday before the Presidents’ Day holiday weekend. In celebration, I have created this little project management puzzle for readers. You can find the solution by scrolling down to the bottom of this blog.

(Enlightened by my experiences on the previous puzzle I posted a few weeks ago, let me emphasize that it’s a puzzle. For fun! It’s mostly fictional (though consistent with history) and NOT intended to be a recommended solution for real project management issues!)


On the morning of his nineteenth birthday, George Washington sat in his Virginia home and stared into the mirror. Like many youths in their late teens, he was not happy with what he saw: a face uncreased by experience, eyes lacking in knowledge, and a jaw meager in confidence.

“This must change,” George thought to himself, “for that is not a face that could ever adorn a one dollar bill.”

George decided it was time to remake himself. Accordingly, he began to lay out a planned regimen of daily toil, of reading and observation and experimentation in “all maters befyttinge the requyrements of an 18th century Virginia gentle manne!” And he made a resolution that, starting on the first day of the New Year, he would set aside time every day, the Sabbath and holidays as well as weekdays, to follow his plan for exactly 550 days according to his schedule. And he would educate himself in all the appropriate arts and sciences.

True to his word, George started his regimen on the first day of the year 1751, and every day thereafter he labored away at his education, desirous of completing his project by the end of 1752. But, alas, after several months of diligence, fate intervened. George’s older half-brother Lawrence became ill with tuberculosis. A decision was made that Lawrence should sail to the beautiful island of Barbados to have the opportunity to breathe its recuperative air. And it was further decided that George would accompany him. They reached Bridgetown, the capital city of Barbados, on November 2, 1751.


George had hoped that once he reached Barbados, he would be able to re-start his daily program. Unfortunately, he became very ill with smallpox (the facial scars from which, he feared, would further lessen the likelihood of his ever appearing on any currency).

After two months in Barbados during which he was unable to devote even a single hour to his planned regimen, George sailed back to Virginia. Including his time aboard ship, ninety days had been lost to his project. But he was never one to blame failure on bad fortune. “It is better to offerr no excuse than a badde one,” he asserted, and threw himself back into the daily routine of his project.

Question: Back in Virginia, and having lost 90 days due to his voyage to Barbados, was George Washington able to complete his (yes, fictional!) 550-day project by the end of 1752? If not, explain why not. (No working extra hours in a single day is allowed!)

Scroll down for the answer.

Answer: No, George’s project cannot be finished until January 3rd, 1753, due to two changes mandated by the Calendar Act of 1750.

One change shifted the British Empire from the Julian calendar to the Gregorian calendar by eliminating the eleven days from September 3rd through September 13th, 1752. This shortened (the normally leap year) 1752 to only 355 days.

Additionally, the Calendar Act also changed the first day of each new year from March 25th to January 1st, starting in 1751. March 25th was the first day of 1751, but the last day of 1751 was December 31st, shortening that year to 282 days. The two years 1751 and 1752 were therefore only a total of 637 days long. By losing the 90 days for his trip to Barbados, Washington’s 550-day project required 640 days of elapsed time, from the first day of 1751 (i.e., March 25th) to January 3rd, 1753.

Today is also the first day of the ICC’s Cricket World Cup, being played in Australia and New Zealand. May there be some great cricket and may West Indies, as unlikely as it seems, win the championship!
Fraternally in project management and cricket,

Steve the Bajan

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

Time Is a Cost Even When Nobody Says How Much

“ ‘Wait’ is a heavy load!”

– Old Bajan proverb



In my recent post, “Project Managers Should Revel in Time Analysis!”, I wrote:

“By far the biggest impact of time is to the project sponsor or customer – the person or persons who are funding the investment in expectation of reaping its value, yet often must wait months or years for its completion. This is the person who should be stipulating the value of time right up front, in the contract or the business case of the project charter.”

A former student recently sent me an illustrative quote from page 26 of the 2009 book Reengineering the Corporation by Michael Hammer and James Champy:

A company in the pension business recently developed a service to take advantage of a quirk in the tax laws and interest rates. Its anticipated market life was exactly three months. Coming to this market late by just thirty days would have cut the company’s selling time for the service by a third… The point is that not only have product and service life cycles diminished, but so has the time available to develop new products and introduce them. Today, companies must move fast or they won’t be moving at all.”

But what if the sponsor/customer does not understand the full implications of the project being an investment that is greatly impacted by the cost of time? Or has failed to identify this particular project as an enabler project whose full value will be impacted by the cost of delaying other projects? Or simply does not understand how to incorporate the cost of time in a contract or charter, relying on the hackneyed metaphor of a deadline that is far more likely to have negative than positive impacts due to:

  • Parkinson’s Law, which can cause the team to focus on “just-in-time” delivery (and thus often deliver late due to emergent events) even if it could have been delivered far sooner.
  • Debased scope (especially quality), because it seems less painful to cut scope “invisibly” than to miss a calendar commitment. (In the US, the 2013 rollout of the website was a classic example of this.)
  • The Principal-agent Problem, which can cause a contractor organization (which may have myriad other concerns including more lucrative contracts or limited cash flow) to pursue its own benefit to the detriment of the customer’s.
  • The lack of urgency on internal projects in many organizations, often caused by the arbitrariness of deadlines and the sense that: “Hey, everyone’s always late!”

Scope, cost and time are the currencies in which the project manager works. The value of the scope is why the project is funded and the cost of the project, in the form of resource usage, often has a whole finance department to help track it.

But the value/cost of time is almost always left as an externality: not estimated, unplanned, untracked, and not used as a quantified basis in project decision-making. Yet the project team has the knowledge and techniques, through critical path analysis and resource scheduling (especially with the CPM innovations critical path drag and drag cost), to greatly enhance this aspect of the customer’s value. Depriving the project manager of this knowledge is the equivalent of tying one hand behind her back, reducing her impact on the project’s expected profit and incapacitating her ability to demonstrate the value she can add. The effect is to reduce the project manager to an automaton marching blindly to a scope/budget/deadline cadence rather than an investment manager employing her knowledge and skills to maximize the value to her customer. And other than a little oil in the knee-joints every week, automatons get neither appreciation nor salary!

So what should the project manager do if deprived of this information? My recommendation:

  1. Do some back-of-the-envelope calculation of what the minimum value/cost of time on the project could be.
  2. Forward those calculations in a memo to the sponsor/customer and anyone else whose perspective on the subject would be valuable, explaining the conservative rationale of the numbers and why an even more accurate figure would help in seeking opportunities to maximize the project’s value by supporting schedule compression decisions.

If the customer confirms that either the initial estimates are accurate or (as will often be the case) that the value/cost of time is even greater, the project manager should urge amendments to the charter or contract incorporating time-based incentives to the team/contractor for earlier completion. (“We’ll be using these to seek time-saving opportunities that you indicate are worth a lot to you, and to the offset additional costs that such schedule acceleration would likely incur.”)

Such contractual inclusions would only reflect a percentage of the value to the customer and, of course, would only occur in the event of actual early delivery. So why would the sponsor/customer ever want to reject them? It becomes a win-win for all, with an amended contract that reduces the potential for moral hazard in the principal-agent problem by better aligning customer and contractor benefits.

The result is almost always a more satisfied customer, and a project manager whose added value can be clearly quantified.

All this is discussed even more comprehensively in my book Managing Projects as Investments: Earned Value to Business Value. In my next blog post, I will explore ways to develop those “conservative estimates” of the value/cost of time when the project manager has not been given that information.

Fraternally in project management,

Steve the Bajan