Grateful for a very nice review of my book

I’m headed out today to teach a two-day class at University of Massachusetts, so I’m not sure when I’ll get the chance to write the next blog I want to post, about what to do when no one tells you the cost of time on your project. Maybe I’ll get to it on the weekend.

But I also just read a very nice review of my book Managing Projects as Investments: Earned Value to Business Value at Ten Six Consulting. Among other things, it says:

“Devaux helps make the paradigm shift from thinking of projects simply in terms of cost and schedule to viewing them as investments.”

That is, exactly, what I want to do — to put my shoulder, along with that of many others, behind the rock of improved project management and help us all reach a point where we can all be proud of our discipline instead of having to read, again and again, of costly and sometimes lethal failures. I believe that treating projects as investments, along with new techniques like business value and DIPP tracking, drag and drag cost computation, the value breakdown structure (VBS), etc. can all further this goal.

One spends many months writing a book and when it’s published you wait for reactions from readers, not knowing if they’ll like it or hate it. Although my publisher reports that sales have been good so far, this is the first formal review I’ve read and it’s very gratifying. I have always liked Ten Six Consulting’s blog and in the past have learned some valuable things, especially about MS Project and Primavera, from it. I think it’s a very useful site. So thank you, Ten Six.

If by Saturday I haven’t yet been able to publish the new blog post about how to estimate the cost of time, I promise I will at least post another little puzzle, this one about George Washington and a fictional project. (Actually, considering the great response to my previous puzzle/riddle, why would I ever publish anything else? But I will.)

Fraternally in project management,

Steve the Bajan

Who Cares about the Cost of Time?



Time is the coin of your life. It is the only coin you have,

and only you can determine how it will be spent.

— Carl Sandburg, American poet


The answer to the question in the title of this blog post is simple: we all should! It is, as Carl Sandburg wrote, the coin of our lives. Yet every time someone commissions a project, they are allowing others to determine how their most valuable “coin” will be spent. If we spend a dollar to create a widget, we can usually get that dollar, and more, back when we sell it. But we can never get back the time that was spent in designing and prototyping and manufacturing and testing and deploying that widget – it’s gone for good. How strange, then, that corporations have whole finance departments busily forecasting and tracking the spending of every dollar, yet the value of the time the project takes often slips by unmeasured in monetary terms. Time is one of the three constraints of the venerable Iron Triangle (discussed in this November blog post “Turning Iron into Gold!”). The other two constraints are Scope and Cost. Cost is the monetized metric of resource usage – the dollars (or yen, euros, rupees, etc.) one has to pay to obtain the resources necessary to create the Scope. Scope is the reason for doing the project: the value the Scope is expected to generate. The one thing certain thing about Scope is that the value it’s expected to generate is greater than the cost of resources needed to generate it! No sane person would ever knowingly invest money in a project expected to generate less value than it will cost (which, of course, is why every project is an investment!). So both the Cost and Scope sides of the Triangle can be estimated in dollars. That means that if we are to use the three-sided paradigm for making decisions and trade-offs across the project, we must have an estimate of Time that is also in dollars. On projects, time delay almost always causes value decay. How much would the same Scope be worth if we could generate the final product three weeks earlier? How much value must that fragnet of optional Scope add to the project’s expected value if it’s also adding two weeks to the duration? And how much better or worse off would we be if we spent an extra $20,000 on resources to avoid the schedule slipping by a week? The answers to all these questions are dependent on the interaction of Time on the value of the Scope and the Cost of the resources. ImitationGame A week ago, I saw a movie that contains a number of project management motifs: The Imitation Game. There is a very powerful bit of dialogue at one point (so powerful that it is featured in the movie’s trailer (at 0:30 seconds in). Stewart Menzies, the “sponsor” of the project to decode the output of the captured German Enigma encryption machine, is talking to the “project manager” Alan Turing: *** MENZIES: Mr. Turing. Do you know how many British servicemen have died because of Enigma? TURING: I don’t. MENZIES: Three… (All stare at Menzies) TURING: That doesn’t sound like very many. MENZIES: …while we’ve been having this conversation. (Checks his watch) Oh, look. There’s another. Rather hope he didn’t have a family. *** This brings home in human terms the cost of time, and the value of shortening the project. Yes, it is often particularly salient in wartime. But it’s also true on healthcare and pharmaceutical and medical device projects, and on national security, and on digging potable water wells, and on emergency response projects. If you are unsure of how to think about the cost of time, and how to use it along with critical path drag and drag cost to optimize an important schedule, I would urge you to read the chapter “Time Is a Murderer!” from CRC Press’s Handbook of Emergency Response. You can read it for free right on this site, under the REFERENCE tab on the front page (or just click on the hyperlink above). I feel as though writing that chapter was one of the most important things I have ever done. I hope it will lead to the saving of human lives. In my next blog post, I plan to address what a project manager should do in the (very likely!) event that no one has informed him or her about the value/cost of time. 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



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

Answer to the Quick Riddle…

My goodness, I guess we project managers just love to waste time. Very gratified to see all the responses, though. I didn’t know how this would be received, perhaps with cudgels for not being serious about such a serious subject as project management. Now I don’t know if I should ever post anything that isn’t frivolous!

Both Bill and RH pointed out that if we go from April 1st of one year to May 31st of the next, there’s “bags of time”. While this is not the answer I was looking for, it’s my own fault for not framing the question better. Trust project managers to figure out a loophole in the contract!

The answer I was looking for was actually supplied by marcthibault. His posted response here suggested that he was on the right track, and when I emailed him it turned out he was.

The answer that I conceived, and that works, and that marcthibault figured out, is what I would term the Passepartout Solution. Jean Passepartout was the valet of of Phileas Fogg in Jules Verne’s 1873 novel Around the World in 80 Days. When Fogg finally returns to London after circumnavigating the globe, he thinks that it has taken 81 days and he has therefore lost his wager of 20,000 pounds (about $2 million in today’s money). However, his valet Passepartout discovers that, while 81 days have indeed passed for them, because they traveled from west to east they have gained a day on the calendar and only 80 days have passed in London.

So the answer to the riddle is simply to have the resource doing the work travel, perhaps by ship, from west to east across the International Dateline during the course of the project.

I’ll try to make a more serious blog post later today. Meanwhile, thanks so much for the responses.

Fraternally in project management,

Steve the Bajan

A quick project scheduling riddle…

I will try to post another major blog either tomorrow or the next day. But meanwhile, for those who like posers (as opposed to poseurs!), here is a little problem to solve.

If you think you know the answer, feel free to supply it by clicking on the COMMENT function. Under any circumstances, I will provide the answer at the end of my next blog post.

So here is the circumstance:

We have a project to complete. It consists exclusively of work to be done on a computer: data analysis of a previously-performed study and writing up the results, findings and recommendations.

The project consists of exactly 62 eight-hour days of work effort. None of it can be done in parallel and it must all be done by a single resource who will work and produce for exactly eight hours per day, producing one work day of effort every day. No overtime is allowed.

The work is scheduled to start April 1. But it MUST end no later than May 31..

If it starts April 1, how is it possible to complete the 62 days of effort by the end of May 31?

Fraternally in project management,

Steve the Bajan

Why is Critical Path Analysis Not Being Used?

The diagram below is Figure 4.1 on page 62 of my new book Managing Projects as Investments: Earned Value to Business Value. It is a Google Books Ngram Viewer graph. It shows the number of times, year by year, from the set of five million books that Google had digitized through 2008, that the terms “critical path” and “project management” were used. It shows that both terms started being used just before 1960. “Critical path” shot up much faster, but peaked in 1968. Thereafter, despite the fact that “project management” continued to rise for decades, surpassing “critical path” in 1980, the usage stats of “critical path” first fell from the peak and since then have remained moribund.


Figure 9.1: Google Books Ngram Viewer graph for “critical path” and “project management” terms

Why is this? How is it possible that, despite the explosion of project management, the term for the factor that determines the length of every project (whether or not scheduled using CPM!) has failed to increase in usage?

I genuinely am asking this question because I am not certain I know the answer. I do have some ideas, however.

The first is the fact that critical path scheduling takes effort. As 2002 Nobel laureate in Economics Daniel Kahneman points out in his book Thinking, Fast and Slow, the hard work of computation and analysis require effort that people often find painful: what will happen first? What’s likely to happen next? How likely is it? What if a less likely event occurs? What contingency should we plan? And will we have the resources for that contingency?

All this planning, analysis, and other sweat-inducing labor, which are required behaviors for project management competence on any but the simplest projects, can be hard even to learn how to do. And actually putting it into practice is even harder. It’s a lot easier to say: “We’ll go with the flow and react to what occurs.” And that’s also a lot easier to do — until actual events blindside us and utterly destroy the project!

Part of the problem is that many people don’t understand the purpose of critical path scheduling and why it’s such a valuable technique. The assumption is that if we aren’t certain exactly what is going to happen and how long every activity is going to take, then the plan will be worth little.

There is an old project management adage:

Q: “Why do we put so much time and effort into planning the project?

A: “Because when we do, whatever we have planned will have eliminated ONE of the millions of ways the project could actually go!”

But there is truth deep in that tongue-in-cheek Q & A. The reason we plan is not because we expect the project, especially a complex project, to roll out exactly as planned. Things are bound to change during execution, and often in unexpected ways. Components will fail and require rework; expected resources will disappear; activities will consume their float; and the planned critical path will migrate hither and yon. But the project manager who has utilized the standard techniques of project planning will cling to the neck of that bucking bronco, spotting the variances, measuring them, predicting their impacts and alleviating the damage.

To briefly illustrate how critical path scheduling provides the project manager with the reins to maintain control of the project, let us take the simple network diagram shown below. We have performed the forward and backward passes and computed total float and drag for each activity. Now the project starts and the variances start hitting;


Figure 9.2: Critical path network showing early and late dates, total float and critical path drag

  1. D takes 12 days – what is the impact?

The project becomes 2 days longer. F, I, H and J all slip their early dates by 2 days. TF on B, E, G, K and L all increases by 2D. Drag on F increases by 2D to 9D.

  1. In response, we shorten F from 15 days to 9 days – what is the impact?

The project is shortened by 6 days to 66 days. TF on B, E, G, K and L all decreases by 6D. Drag on I decreases to 3D (now parallel with G whose TF is down to 3D).

  1. Finally, we discover that, by adding $100K in resources to Activity I, we will be able to shorten it from 20 days to 12 days. What is the impact?

Since Activity I now has only 3 days of drag, the project will be shortened by only 3 additional days, to 63 days. The critical path will migrate through Activity G. Is the $100K expense worth it?

No matter what changes hit the project, the project manager can see and assess the impact and perhaps find alleviating measures. This is what using critical path scheduling in planning a project can do, whether for 12 activities or 12,000 activities. This is what all project planning using traditional flexible techniques like WBS, CPM and resource leveling is designed to do: help keep that project from getting out of control. And those who fail, through ignorance or laziness, to use these techniques deserve to have their projects reap all those whirlwinds.

For other exercises in computing critical path information and critical path drag, see the exercises tab on this site.

Fraternally in project management,

Steve the Bajan

“Anything that just costs money is cheap.”

The title of this blog post is a quote from John Steinbeck, American novelist and 1962 Nobel laureate for Literature. Steinbeck probably wasn’t talking about projects, but, boy, does his quote apply! And the most costly aspect for most projects is usually not money but time!

If the purpose of a blog is to get discussion going, then my previous blog post (“Project Success and Failure: Who’s the Impostor?”) has been wildly successful! I never thought daily readership of this site would reach three figures, but it has far surpassed that. And although people are not posting comments right within the blog, a great discussion with many valuable insights has been stimulated on the LinkedIn discussion group The Project Manager Network. (If you are not already a member of that group but find these topics interesting, I urge you to join it – there are many other excellent discussions over there!)

Because the topic of project success and failure seems to excite such interest, I am going to devote the next few blog posts to discussing it, with particular emphasis on the techniques laid out in my books Managing Projects as Investments and Total Project Control (second edition due out from CRC Press in April).

There is an important concept in economics called an externality. The American Heritage Dictionary defines it as “A cost or benefit that affects people other than those involved in the economic activity that produced it and that is not reflected in prices.” Quality processes such as Six Sigma emphasize measuring every variable, because of two adages: “What is measured counts!” and “What is measured can be improved!” Leaving a variable unmeasured results in the negative of those two statements: “What is left unmeasured counts as zero and cannot be improved!”

Everyone knows that projects take time, and that time is important. But how important? Important enough to spend a thousand dollars to save a day? A million dollars?

Some projects in industries like health care, national security or emergency response aren’t about making money, but about saving lives. How much to save a day if thereby we save a human life? What if the life is of a family member, or your own?

But of course, we know this. We have evidence:

  • Every time GE or Siemens buys a piece of equipment rather than undertaking a project to engineering it themselves.
  • Every time an IT department buys a software package instead of undertaking a project to program it themselves.
  • Every time a home owner buys a garden plant rather than planting a seed and growing it.

Yes, such decisions are also driven by awareness of expertise, cost reductions due to volume, and risk mitigation – but a huge factor is simply the value of saving time through an off-the-shelf purchase. We have an entire retail industry that derives value from this, and experienced program managers routinely seek off-the-shelf substitutes to replace development subcontracts when pressed for time on the critical path.

I believe that the biggest failing in project management today is the routine omission of the value/cost of time as a driving metric in project decisions. There are exceptions, notably nuclear power plant outages and oil and gas refinery maintenance projects. Every member of a team in such projects is specifically informed of what it’s costing in lost revenues for every hour or day that the plant is not working. And it is no accident that such projects invest the greatest effort, usually to great benefit, in project scheduling.

There is another John Steinbeck quote:

“An answer is invariably the parent of a whole family of new questions.”

That is very much true with this topic. Its complexity in both depth and breadth is extensive:

  1. The damage due to the failure to estimate the value/cost of time on most projects is usually not isolated even on a given project, but pervasive.
  2. The metrics to measure the value/cost of time require comprehension and effort.
  3. And the management techniques to use those data to improve project performance (instead of, as is now often the case, metrics and methods that damage projects further by providing incentives that beget delays, such as deadlines and functional manager utilization rates!) are new and, because projects have not traditionally been treated as investments, are still being developed (by me and by many others!).

Some of these metrics and techniques like critical path drag, drag cost and the value breakdown structure are spreading through the Internet. Others, like the DIPP, the DPI, the DRED, the CLUB, and the true cost of activities, are still relatively unknown (despite being no less valuable), and being expanded by people like Dr. Tomoichi Sato of Tokyo University, Vladimir Liberzon of Spider Project, Bernard Ertl of InterPlan Systems, Jean-Yves Moine of the 3D Breakdown Structure approach and others.

I try to further discussion and answer questions in discussion groups, and will continue to explore and explain in this blog. But the truth is that many of the questions that arise have been answered much more comprehensively and coherently in my book Managing Projects as Investments. Someone who has read that book would likely have even more sophisticated questions that I would love to answer.

I know the book costs money, but as anyone here who has published a PM book can attest, a tiny percentage of the price goes to me. What would go to me is the knowledge that new ideas in project management that I have been pushing “up the hill” for over twenty years are finally getting widely disseminated. And I also believe that knowledgeable PM readers will find it very interesting – for the most part, it contains ideas you haven’t read elsewhere and may well align with thoughts you have had yourself.

I am headed off to New Jersey tomorrow to teach a five-day course in these techniques at a major aerospace contractor. But in the meantime, I hope to have my web designer load two new items:

  • An exercise (with answers) in computing drag and drag cost in a network with complex dependencies and lags.
  • A chapter titled “Time Is a Murderer!” from CRC Press’s 758-page tome Handbook of Emergency Response, Badiru and Racz, editors. It explores how to use critical path drag, drag cost and other PM techniques (e.g., WBS templates, organizing a program schedule to maximize value) to optimize a planned response to a natural catastrophe. (And the rest of the book contains some great info, too.)

I hope you find these interesting, and I will respond to any comments whenever I can steal a minute from my course.

Fraternally in project management,

Sisyphus the Bajan