How to Determine the Expected Value of Those Crucial Enabler Projects!

Every investment decision – stock purchase, real estate development, commodity options, new product development, poker hand – must be based on analysis that estimates the value that the investment will generate at some specified point in the future. That is one reason why the redefinition of projects as “investments in work” is so important. As most project and program professionals are keenly aware, a key area of disappointment with the way that projects are currently executed is their frequent failure to produce benefits. Defining them as investments will enforce renewed emphasis on the expected benefits—not just by listing them but also by:

  1. Estimating the expected value of such benefits if delivered on a specific date;
  2. Estimating how a change in that delivery date, later or earlier, might change that expected value;
  3. Tying those benefits to specific items of product and project scope (via the value breakdown structure, or VBS);
  4. Tying the items of project scope to the project duration and budget through critical path drag, drag cost and true cost (TC of a critical path activity = resource costs + drag cost); and
  5. Making every project and program decision with the impact on expected value (and the DIPP) in view.

One of the crucial types of projects to deal with as an investment is the sort that in my book Managing Projects as Investments: Earned Value to Business Value is referred to as an enabler project.

  • An enabler project is usually part of a larger overall program.
  • Its value comes from its role in increasing the value of the overall program by enabling the other projects (and perhaps non-project work) in the program.
  • In that role, its value is enlarged by the value of the projects it enables.
  • Its acceleration or delay value/cost is therefore also often increased because of its impact in delaying or accelerating the schedules and value generation of the other projects.

There are many, many examples of this type of enabler project. But a concrete example is that of the development of a luxury vacation resort:

****

Paradise Island

Paradise Island Luxury Resort will provide luxury vacation time for the whole family!

  • Five-star hotels and restaurants, as well as boutiques for the rich-and-famous. These are expected to generate an average of $2 million per week above operating costs, or $520M over 5 years after the Grand Opening.
  • A championship-quality golf course, where the greens fees are expected to generate $1 million per week above operating costs, or $260M over 5 years after the Grand Opening.
  • A marina for luxury yachts, expected to generate $0.5 million per week above operating costs, or $130M over 5 years after the Grand Opening.

One of the great attractions of the resort is its guaranteed privacy. This is due to the fact that it is located on Paradise Island. Although only a short distance from land, the cliffs that comprise the island’s perimeter make it completely inaccessible. We therefore have to build the Garden of Eden Bridge to the island in order to:

  • Transport the heavy construction equipment and materials needed for the development, and
  • To allow the guests to reach the island once the resort is opened.

It is planned to take 52 weeks to make the bridge ready for the transportation of equipment and materials. Only after that point can work start on the hotels, restaurants, boutiques, golf course and marina. The Grand Opening of the entire resort with all its features is intended for 104 weeks after transportation across the bridge becomes possible.

When the resort opens, a tollbooth will be placed on the bridge. It is expected that tolls will amount to $1,000 per week above operating costs, or $260,000 over five years.

QUESTIONS:

  1. What is the expected value of the entire resort over five years?
  2. What is the expected value of Garden of Eden Bridge over five years?
  3. What is the value/cost of time on the Garden of Eden Bridge project?
  4. Based on the information above, how much would it be worth if we could shorten the bridge project by six weeks?
  5. If the Garden of Eden Bridge is being built by a contractor on a fixed price contract, what should the customer insert into the contract?

Scroll down for the answers.

ANSWERS:

  1. What is the expected value of the entire resort over five years? Combined, the Paradise Island Resort is expected to generate $3.5M per week above operating expenses, or $910M over five years, plus $260,000 in tolls from the Garden of Eden Bridge.
  2. What is the expected value of Garden of Eden Bridge over five years? $910.2M over five years! There is no value unless we build the bridge – it enables the entire project! So the value-added of the bridge project is equal to the value of the entire luxury development program.
  3. What is the value/cost of time on the Garden of Eden Bridge project? Any delays on the bridge delay all the other projects, and the resort opening, on a one-to-one basis. Therefore the value/cost of time on the bridge project is $3.5M per week (+ $1,000 per week for the bridge tolls). In other words, that is the drag cost per week for every activity on the bridge project’s critical path.
  4. Based on the information above, how much would it be worth if we could shorten the bridge project by six weeks? Each week that we can shorten the bridge project is worth $3.5M per week + $1,000. That means that the expense for additional resources that cost up to $21M (+$6,000 for the bridge tolls!) would be justified.
  5. If the Garden of Eden Bridge is being built by a contractor on a fixed price contract, what should the customer insert into the contract? Substantial monetary incentives for each week earlier that the contractor completes the bridge. Unless the contractor is incentivized, he likely will not even seek opportunities to accelerate the schedule, costing the customer $3.5M per week for every opportunity overlooked. And if the customer doesn’t do this but the contractor recognizes the project as an enabler project, the contractor should:
  • Approach the customer;
  • Explain the situation;
  • Point out that he might be able to accelerate the schedule by spending more money; and
  • Suggest amending the contract to include time-based incentives that would maximize the customer’s value.

This is a very simple — but easy to understand — example of an enabler project and the importance of identifying it as such and of computing its multiplied value/cost of time. What are some other examples of enabler projects in the real world? Have you worked on any? Were their unique value aspects, as shown in this example, understood and exploited? If you have other examples from your experience, please describe them in this website’s Discussion FORUM here.

Fraternally in project management,

Steve the Bajan

PMBOK® Guide Sixth Edition: What Would You Like to See Added?

Sometime in 2016, the next edition of the PMBOK® Guide should be published by the Project Management Institute. We could wait until too late and then complain about how the hard-working folks who author the “bible” haven’t seen fit to include our pet terms, techniques, metrics and ideas. Or we could start now by developing a list of items that we feel it should include, and perhaps either someone will notice it or we can summarize it and email it to PMI for consideration.

Toward this goal, I am starting a “PMBOK® Guide Sixth Edition Wish List” thread in the Discussion FORUM attached to this blog. I hope that readers will weigh in with their own suggestions/nominations, as well as comment on the suggestions of others. And periodically I will compile a summary of them.

For starters, here are ten items that I personally think should be included in the next edition, listed in descending order of how valuable I feel the inclusion of each would be. I will follow each with a brief explanation or descriptive link and a five-scale rating, running from VL (for Very Likely) to L to M to U to VU (for Very Unlikely), of my estimate of the probability of each being included.

  1. Change in the definition of “project” to eliminate the weasel word ”endeavor” and replace it with “investment in work”. My preferred redefinition would be: “An investment in work to create a unique product, service or result.” (No need for “temporary” either, until someone can show me something that isn’t temporary!) [U, even though this would have great benefit for the project management profession by recognizing our important role in utilizing the resources and funds with which we are entrusted to maximize value and ROI.)
  2. Expand the section on “Business Value” that was introduced in the 5th edition and that currently occupies most of pages 15-16, as well as being mentioned in the Glossary. The current description starts: “Business value is a concept that is unique to each organization.” That is indisputable. But it is also such a crucial concept (the raison d’etre of every project and/or program!) that surely it needs to be expanded to far more than two pages. Deserving of exploration are:
  • What are the commonalities of business value across any and all organizations?
  • How should it be measured? (Value is usually measured in monetary units.)
  • What generates the business value? (Answer: the product scope, with occasional contribution from the project scope if just doing the work adds value {e.g., a more experienced workforce}.)
  • What project documentation/technique should be used to define the business value? (Answer: the value breakdown structure (VBS) – which should definitely be included, and I think will be!)
  • How should business value be used to manage the other aspects of the project? (Through optimizing it in integration with schedule and cost, and using it to justify additional resources where their cost is less than the value they add.)

[VL. Business value is an obvious concept that lots of people have been writing about for a while. Whether any of the information mentioned above is included in the expanded treatment of the topic is much more doubtful. But almost any expansion would be useful.]

  1. Change the EVM term from planned value (PV) to planned cost (PC). It is cost, as the original earned value terms (that are still used in US Department of Defense contracting) BCWS, BCWP and ACWP emphasized: notice the “C” as the second letter in each of those. Yes, using two letters instead of four for each term made the metrics more accessible, and PMI has done a great job in spreading the use of the technique. However, the word “value” instead of “cost” in PV and (and in EV!) confuses people over the concept of business value. (For a great illustration of this, read Mike Hannon’s review of my book Managing Projects as Investment: Earned Value to Business Value.) [U. Okay, maybe I’m too optimistic and it should be VU. But if PMI wants (as it should!) to expand the concept of business value, it has to start clearly distinguishing between cost and value.]
  2. Include critical path drag as a scheduling metric. Wikipedia definition here. Every item on the critical path of a project or program has drag (unless two parallel paths are both critical, in which case neither has either drag or float but both, in combination, have drag compared to the next longest path). Why does the PMBOK® Guide include the non-critical float (slack) metrics but not the always-critical drag that costs the project time and money? Knowledgeable project managers are now computing drag “manually” – but drag analysis would be done so much more routinely if all the software did the calculation. That will happen someday – but much faster if the next PMBOK® Guide recognizes it. Besides, it’ll stimulate a lot of additional opportunity for PMP Exam questions! [L. Again, maybe I’m being overly optimistic — but it’s just hard to see how knowledgeable people could think that drag doesn’t belong in the Time Management section.]
  3. Stress the importance of a clear estimate of the value/cost of time as part of the charter or project business case or other initiation documentation. [U. It’s an obvious idea which would help tie PMBOK® Guide methods to the shutdown and turnaround discipline, where such estimates are standard and hugely important. I think it will happen eventually, but probably not in the 6th Edition]
  4. Include drag cost as either a Time Management or Integration Management metric, or both. Wikipedia definition here. On more than 98% of projects (by my estimation) extra duration (i.e., time on the critical path) reduces the expected value-over-cost (expected project profit (EPP?) of a project. And on those few exceptions, it’s important to know that they are exceptions! If critical path drag is included, it would be hard to understand a rationale for not mentioning drag cost. [M. Less likely to be included than plain naked drag, but still a good chance. If it is included, it would increase the chances for inclusion of #5, stressing the importance of a clear estimate of the value/cost of time.  But #5, recognition and quantification of the value/cost of time, is more important than just the act of tying it to an activity’s drag.]
  5. Mention and discuss the DIPP formula (DIPP = {$EMV of Scope ± $Acceleration or $Delay} ÷ Cost ETC} for planning, optimization and tracking. [VU. A rephrasing of the definition of “project” to include the word “investment” (see #1) would obviously make this more likely. But the “enabler” (see below) has to be recognition of projects as investments. Maybe this important metric will be included in the 7th or 8th]
  6. Recognize and discuss the multiplier effect on the value of “enabler” projects within a program, as well as the multiplier effect on an enabler’s acceleration premium and/or delay cost. The failure to recognize the special nature of enabler projects and to designate them as such leads to many bad decisions in terms of resource targeting. [U. Again, it’s an obvious and important concept. Some of the PMBOK® Guide authors are very smart people, so I hold out some hope.]
  7. Discuss/mention the doubled resource estimated duration (the DRED) as a technique for estimating the resource elasticity of an activity’s duration in response to additional resources. The DRED is an estimate of what an activity’s duration would become (shorter, longer or stay the same) if its assigned resources were doubled. [VU. Too bad, it’s a useful little tool for identifying where additional budget would help the most.]
  8. Discuss/explore the cost of leveling with unresolved bottlenecks (the CLUB). We know that resource insufficiencies cause delays. If we start measuring the value/cost of time, we will be able to quantify that cost and attach it to the specific bottleneck causing the delay. This metric is extremely valuable on a single project basis, and even more when compiled for an entire resource type or functional department across all the projects it supports – in other words, this is a toll that can move us toward right-sized staffing levels. [VU. But the CLUB is SO valuable to project and functional managers! I’m allowed to dream, ain’t I?]

Well, here are ten to start the ball rolling. C’mon, now, you must have some ideas too, don’t you? CCPM folks? Agile expansion suggestions? Add them to the list.

Fraternally in project management,

Steve the Bajan

Project Management and Senior Management: Reconciling Their Needs

I’ve been developing and teaching techniques and metrics for managing the business value of projects for over 20 years. My first major article was “When the DIPP Dips: A P&L Index for Project Decisions”, published in the Sep/Oct 1992 issue of Project Management Journal. And the first edition of my Total Project Control book included techniques such the DIPP Tracking Index, the value breakdown structure (VBS), drag cost and the cost of leveling with unresolved bottlenecks (the CLUB): all techniques for managing and tracking projects for optimum value.

But something was missing. I would explain these techniques to experienced project managers in corporate classes and PMI seminars, and from time to time I’d be hired as a consultant to help plan a big project or pull in a slipped schedule. And then I’d leave and realize that I’d only handed the organization a fish. Despite my efforts, I had failed to teach them how to implement the processes to catch it themselves.

teach a man to fish

About five years ago, during the fourth day of a corporate class on the TPC methodology, an attendee said:

“Steve, these concepts and techniques that you’ve been teaching us are great – but we’re the wrong audience. We’re just the master sergeants. You need to be teaching the colonels and generals in this company. Because they don’t understand any of this!”

I started thinking: what is it that I’m missing? Why is it that senior managers have almost no interest in learning about the techniques of something that so clearly impacts an organization’s bottom line?

And so it finally hit me: the concept that I had been talking all around for two decades, the magic word that would make senior managers sit up and take notice. Investment! The thing that senior managers do understand! Not just understand, but respect and study and believe in planning and tracking and optimizing.

Project managers are subject matter experts. They are engineers and chemists and programmers and biologists and doctors and geologists and… They know a lot! They have not only extensive education, but experience in things that it is very important to know!

Where they often don’t have a great deal of knowledge is in terms of what some would call “business skills”: investment and economics and marketing. And you know what? That’s okay! Knowing how to make sure that the building doesn’t collapse, or the airplane crash, or the software consume the hard drive, or the pharmaceutical compound kill someone, or the ground water get polluted… That’s hard and that’s important! Yes, it would be nice if these smart and conscientious folks also had business knowledge and skills – but if we want those skills, they are going to have to be “add-ons”, because these people have been busy all their lives putting their energy into other very valuable knowledge. And that’s why corporations bring in people like me to teach their SMEs project management.

Executives have learned an awful lot as well: about investment and economics and marketing and taxes and interests rates and corporate bonds and organizational structures and behavior… and that’s all important stuff too. What they don’t know about is project management. And most of the time, they are not willing to attend project management classes.

Now, I’ve met some senior managers who seem to think that project management is somehow “beneath” them. (After all, what’s the big deal about delivering a mall or a jet fighter or an oil well or a cure for depression by an arbitrary deadline for an arbitrary budget, right?) But actually most senior managers I have met are bright and conscientious people, too! It’s just that no one has explained to them why knowledge of project (and program!) management – its techniques, metrics, and governance — is importance to what they do: especially investment!

This is where both sides have to learn! They have to learn a common language. They have to institute and use common metrics that are based in the investment information that senior management respects. But those metrics must then guide the project teams in making the right decisions, and senior management must know that this is occurring.

This is the approach that I took in my book Managing Projects as Investments: Earned Value to Business Value that came out last September. It was intended to provide the “common ground”, the knowledge and understanding that both senior managers and project managers need to share. And that is why it was so rewarding for me when the June issue of PM Network included that very nice review of the book by Gary Heerkens, himself the author of The Business-Savvy Project Manager, which I strongly recommend.

Gary’s review said: “But what about during the project? Luckily, in his book,… Stephen Devaux makes solid points about what can be done to maximize ROI during project execution, and it reveals a large void in my perspective on the business of projects.”

Do not be fooled by Gary’s humility! His own book and his regular writings in his PM Network column have taught me a great deal that I didn’t know. Both of us (and let me emphasize that I have never met Gary!) share a love for project management, a desire to learn and, most important, a willingness to admit when we don’t know something. But what makes me happiest is that he identified, without any assistance from me, the deepest intention of the book: to create, define and explore that crucial nexus between the project management discipline and its techniques and the senior management interest in, and concerns about, business value and investment.

I believe project managers must say that word again and again – investment, investment, INVESTMENT! – to project sponsors and customers and all of senior management (especially, when possible, to the Chief Financial Officer!) to establish that we understand why we are doing these projects. (And then, of course, we must be sure to manage them as investments!)

By the way, I have seen this work in a slightly different arena: job interviewing. I often mentor former students through the interview process, and I always urge them to say, at an appropriate point: “Of course, all projects are investments and really need to be managed as such.” They invariably report back to me that the hiring manager’s face lights up. The next former student that tries this technique and later reports that they didn’t either get the job or at least get another interview will be the first!

This territory is also where this blog will continue to cultivate and nourish the improved status of and respect for project management. I believe it is where project/program management and business management must come together for the sake of organizational progress and efficiency.

Fraternally in project management,

Steve the Bajan

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

June Issue of PMI’s PM Network Magazine: Great Review of Managing Projects as Investments

Earlier today I decided to Google the title of my book Managing Projects as Investments: Earned Value to Business Value. I was delighted to discover that Gary Heerkens has written a great review of it in the June issue of PM Network in his “The Business of Projects” column.

PM Network June cover

In my previous blog article, I summarized a series of previous articles on critical path drag in the following way:

Critical path drag is not, in my opinion, the most valuable innovation that I have included in my books Managing Projects as Investments and Total Project Control. I think the focus in those books on defining and planning projects as investments and then tracking them in scope/cost/schedule integrated fashion through the DIPP and the DPI indexes is what can take project management, and the project manager role, to the next level of professionalism.”

So I am delighted that Mr. Heerkens’s review is so positive despite not even mentioning critical path drag! One paragraph from his article reads:

“Mr. Devaux’s strong points from his book clearly show that there is a wide variety of ways that sound, business-based decision-making can be brought to bear on the way we manage project implementations. One of the many insightful passages that truly captures the spirit of the book is this: Even though their final value might not be revealed for a long time after the initial investment is made, projects should always be managed in such a way as to maximize their expected return.”

But read the whole article. The Google link locates it here. Or if you receive PM Network magazine in the mail, it’s on page 70.

And if you have any comments or questions, please click here to go to the thread in the Discussion Forum.

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

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

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

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

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

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

Slide1

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

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

The exact sentence in that previous article was:

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

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

Figure 4 full network diagram after slippage

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

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

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

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

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

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

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

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

Fraternally in project management,

Steve the Bajan

The Benefits of Recognizing Projects as Investments: “And yet, it moves!”

One of the great afflictions of mankind throughout history has been the stubborn refusal of certain figures who see themselves as ”authorities” to alter their views in light of new ideas and evidence.

In the 17th and18th centuries, combustion was explained as the escape of a substance called phlogiston from a material. This theory was staunchly defended even after it was shown that magnesium gained mass when it burned. Finally, Antoine-Laurent Lavoisier proved conclusively that combustion was the combining of a material with oxygen. This new explanation led to giant steps forward in both physics and chemistry.

Galileo

Some of the most stubborn ideas are those that come with the imprimatur of sacred scripture. Thus the heliocentrism ideas of Copernicus, Kepler and Galileo were banned by the Vatican as conflicting with the Bible and the teachings of the Council of Trent. Galileo was threatened with burning as a heretic, placed under house arrest, and left only able to mutter about our planet: “Eppur si muove.”

Yesterday I had a discussion on a LinkedIn group in which I tried to explain that, in fact, all projects are investments and that recognizing them as such could have great benefit both for the development of better management techniques and metrics and for the greater esteem for our discipline. Alas, I ran into an individual who refused to accept any definitions or techniques beyond the pages of the Fifth Edition of the PMBOK® Guide.

Make no mistake – I regard the Guide as a very valuable book. But both I and PMI also regard it as a guide, and not as the entire body of knowledge of project management! It is also an evolving document, or there would be no need for new editions.

There are techniques and tools and metrics and, yes, definitions that are being used within our discipline that have not yet made it into the PMBOK® Guide. Undoubtedly many will some year. Critical path drag is an example – every project, however scheduled, has a longest path of activities and other delaying factors, and the amount that each item on that path delays completion is its drag. And drag is always there, and has been since the pharaohs’ projects, whether we and our software compute it or not! And this metric is enormously helpful whenever we are seeking places to compress our schedule! (Many clients have employed me over the years to use this technique to recover schedule.)

So what about the definition of a project that I use in my books?

“A project is an investment in work to create a product, service or result.”

First, is there anyone (apart from the gentleman from the LinkedIn group) who would argue that projects are not investments?

  • Investment: “1 The action or process of investing money for profit or material result;.. 1.2 An act of devoting time, effort, or energy to a particular undertaking with the expectation of a worthwhile result.”

http://www.oxforddictionaries.com/us/definition/american_english/investment

I believe we would all agree that every project is undertaken only if its probability-weighted value is expected to be greater than the cost (i.e., the invested amount). If we need a definition for value, the very first definition from the same source seems applicable:

Value: “1 The regard that something is held to deserve; the importance, worth, or usefulness of something”

http://www.oxforddictionaries.com/us/definition/american_english/value

A project’s value may be:

  • Revenues from a new product or service;
  • Future cost savings;
  • The opportunity to keep a plant open instead of being forced by the government to close it;
  • Avoiding fines;
  • Garnering votes;
  • Prosecuting criminals;
  • Saving lives; or
  • Any other of dozens of efforts intended to create a valuable result.

So every project is definitely an investment. But what might be the benefits of staring to recognize them as such?

  1. Project management would start to focus on the quantified aspects of those things that impact the value of the investment: the Golden Triangle of the integrated value/cost of scope, time and resource usage.
  2. Project managers would work harder to align the scope of the project with the benefits wanted by the sponsor/customer through the collaborative development and implementation of a value breakdown structure (VBS) and other techniques. (The failure to actually deliver the benefits for which a project is undertaken is a big issue in many circles, and this would help to solve the problem.)
  3. The value/cost of time on a project, which is currently almost always left as an unquantified externality and therefore rarely managed in terms of its actual impact on the investment, would suddenly be recognized for its importance. Many scheduling techniques that experienced PMs have mastered, like critical path analysis and resource leveling, would therefore suddenly be fully appreciated.
  4. Both drag cost and the true cost of work could be easily computed, meaning that activities on the critical path would be evaluated not only on the basis of their resource costs, but also their drag costs in terms of how much their drags are reducing the value of the investment. (True cost = resource costs plus drag cost.)
  5. Decisions across the Golden Triangle would be quantified in terms of investment value. Should we employ an additional resource costing $10,000 on a critical path activity? Well, will it reduce the drag cost by more than $10,000? Or would we be better off jettisoning that activity because its true cost will be greater than its value-added?
  6. We will be able to track each project during performance not just on the basis of earned value cost and schedule metrics, but on the basis of investment metrics: the expected project profit (EPP) of the project as tracked through the DIPP and the DIPP Progress Index.

All of these are just a sample of the benefits that would accrue if we start dealing with projects as investments. I believe that practitioners would rapidly develop new metrics and techniques to do an even better job of measuring and ensuring greater project investment value.

But perhaps the most important benefit would be for our profession: the value of project managers and project management techniques and contributions would become clearly measurable in value/cost terms. Instead of being looked upon as “overhead on cost centers” project managers would become valuable contributors to the organization’s bottom line.

Surely this would only help PMI to market its ideas and techniques to senior managers who know little about projects, but who care a great deal about investments!

Fraternally in project management,

Steve the Bajan

What is the most important metric of critical path analysis?

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

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

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

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

Why is critical path analysis so important? Because:

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

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

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

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

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

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

So I conclude with four questions:

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

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

Fraternally in project management,

Steve the Bajan

How to Use the VBS and Critical Path Drag to Ensure Maximum Project/Program Benefits

In recent articles, I have written about the value breakdown structure (VBS) and tried to show the benefits it offers to both program and project. One of the most important of these is the ability to align the business benefits that the sponsor/customer/program manager wants to the products and work that will create those benefits.

The VBS may be created for projects within a program or for work packages and/or activities within a project. Once the upper levels of the plan (i.e., the major summary elements of the work breakdown structure) have been conceived, communication between the sponsor/customer/program manager and the project manager/team should start, ensuring that the planned elements will in fact create the desired benefits as well as prioritizing the elements.

The initial stage of prioritization is between mandatory and optional work.

  • Mandatory work is that which must be performed or else the project/program will have no value. The value-added of mandatory work is therefore equal to the expected monetary value (EMV) of the entire project/program.
  • Optional work will add value to the project/program, sometimes great value – but the rest of the work would have value even without this particular item. The value-added of optional work is therefore equal to the difference in EMV of the entire project/program with and without this particular product or work item.

Ultimately, it is the optional work that can provide “wriggle room” when the project is being performed – but also can cause lots of mischief, either by being omitted when it shouldn’t be or included when it should be omitted. In other words, optional work often requires decision-making. This is one reason why the MoSCoW method, which simply separates optional work into Should, Could, and Won’t categories, is insufficiently granular. If we are deciding whether or not to invest in a specific element of work, we need a monetary estimate of both its value and its cost.

In the last article, we defined the concept of the true cost of work (TCW) in a program or project:

  • If a work item is on the critical path, its true cost is the sum of its resource costs and its drag cost, the latter being the value/cost of the time that the work item’s duration is adding to the critical path.
  • If an activity is off the critical path, its drag and drag cost are both zero, so that its TCW is only the cost of its resources.

This important distinction means that one can have a situation where a valuable (“Should”) work item ought to be omitted in favor of a low value-added (“Could”) work item, if:

  • The Could item is off the critical path with a value-added of $40,000 and a resource budget of $20,000; and
  • The Should item is on the critical path with a value added of $200,000, but with a resource budget of $30,000 and drag of three weeks at a drag cost of $60,000 per week.

Remember: chances are that the sponsor/customer/program manager will not know the details of the work, in terms of schedule and cost, two levels down from them. That is why this example is crucial in demonstrating how important it is that the project manager/team, who should know such details:

  1. Understand the desired benefits of the work;
  2. Understand how the components/work items are aligned with those benefits;
  3. Understand the relative priorities of those components/work items in monetized value-added terms (i.e., the VBS);
  4. Understand the monetized value/cost of time on the project/program;
  5. Perform critical path analysis up front and periodically during execution, including
  6. Computation of critical path drag and drag cost; and
  7. Ensure that no work is costing more than the value it is adding.

The sponsor/customer/program manager will not have this information; only the project manager and team will. Therefore it is of utmost importance that the sponsor/customer/program manager ensures that the project manager and team have the information, knowledge and skills (each as enumerated above) to ensure that the desired benefits are generated without wasted effort and money.

Unfortunately, what percentage of sponsors/customers/program managers know how to do this?

In my next blog article, I plan to show how to use the VBS information in combination with schedule data in a network diagram that includes critical path drag, drag cost, and true cost to determine when an optional activity goes from value-added to value-subtracted.

Fraternally in project management,

Steve the Bajan