Ten Consequences of NOT Regarding Projects as Investment!

By Steve the Bajan

My last article was titled “The Benefits of Recognizing Projects as Investments,” and explored both the resistance of some people to this re-definition and the advantages that such an approach would generate. This article will explore some of major consequences of ignoring this essential nature of all projects.

This is a list of ten problems we might expect to encounter due to trying to manage projects in terms other than as investments. And remember, this lack of recognition is the current state of the project management discipline – so as you read this, see if many of the issues I describe sound familiar!

And after each one is a question. I’d appreciate your letting me know, one by one, if you’ve run into any of these situations.

1.      There would be much debate/discussion about how to judge project results.

Terms like “success” and “failure” would be thrown around, with little agreement about their precise definitions. Some would argue that finishing later than some arbitrary deadline and/or over some equally arbitrary budget automatically equals failure, while others would point out that the extra time and money may have helped produce a far more valuable product. (Three classic examples of this are the Sydney Opera House and the movies Titanic and Avatar, but there are plenty of others.) And there would be no accepted metric for determining who is correct.

2.   Projects would be completed to the original specifications and parameters, but after the project is over, the sponsor/customer organizations would realize that they will not benefit nearly as much as they had hoped.

Scope components (work packages and activities, but also projects within programs) are routinely planned and developed without being specifically tied to the benefits and value they are designed to generate. And thus the sponsor/customer does not get the desired benefits. Indeed, this whole problem area is being addressed in the U.K. by the development of benefits realisation management, the discussion topic in this LinkedIn group.

3.   The important value drivers of project investments would not be mapped to projects’ scope, both product and work scope. The result would not only be omission of key elements as mentioned in #2, but also the inclusion of work that should have been jettisoned at some point: scope that adds time and cost but with little or no added value.

With recognition of the investment nature of projects, there is a Total Project Control (TPC) technique for addressing this within the framework of project management: the value breakdown structure (VBS). The VBS estimates the value-added of optional scope components. But when tied to drag cost, it also helps to ensure that scope is limited to those components and work items whose true cost (TC = drag cost plus resource costs) is more than their added value, and that those that do not achieve that threshold can be identified for modification or elimination. (For more, see this blog article “How to Use the VBS and Critical Path Drag to Ensure Maximum Project/Program Benefits.”)

4.   During execution, project performance would be judged only on the basis of tangential metrics, such as time and cost, that do not directly quantify value decay nor show how value might be increased.

Earned value metrics are, in most cases, pretty good for cost management. However, they incorporate huge distortions when used for schedule management (primarily due to the failure to incorporate the most important schedule information, critical vs. non-critical path progress). This can be ameliorated through techniques explored in my book Managing Projects as Investments: Earned Value to Business Value. But almost no organization is using these techniques, leaving EVM schedule tracking at best a guess and at worst a metric that institutionalizes moral hazard and encourages gaming the numbers. And these cost/schedule metrics are unrelated to the expected value for which the scope is undertaken.

5.   If, as often happens during projects, the expected value ofthe scope either increases or decreases (or even disappears!), that information would not be incorporated in progress metrics and reports.

A change in the expected value of any investment should always trigger analysis of where we stand and if the planned future course needs to be altered. This is particularly true for a project if it becomes clear that the value terms on which the current plan was developed have changed. An adjustment in scope or schedule might restore or even increase value. But the formal incorporation of project value analysis as part of the reported project progress data is so rare as to be almost non-existent. This would change in a hurry if the expected value of a project investment became recognized as an important variable and thus a standard progress metric.

6.   Basic investment theory emphasizes quantification of all factors that might impact expected value. Not recognizing this essence of every project would mean that significant factors such as the impact of time on a project’s expected return are left as an externality, and are not be used for project decisions and resource justification.

The best project scheduling in any project management discipline takes place in the energy generation industry such as maintenance shutdowns of power plants and refineries. Great effort is invested in developing those schedules largely due to the fact that the value/cost of time is (a) large, (b) analyzed and quantified, and (c) well known to planners and to just about every member of the project team. But on most other types of projects, the value/cost of time is usually unquantified (‘But, oh, it’s really important!”), making it very difficult to justify the cost of additional resources that, if the numbers were known, would be repaid many times over through the search for opportunities for a shorter schedule. (Note that the resulting inefficiency is often repeated and multiplied many times over in multiproject organizations where the staffing levels of functional departments are not driven, as they should be, by the impact of resource shortages on the critical paths of projects.)

7.   During project execution, if the discovery is made that the addition of specific resources can increase the project’s value either by adding valuable quality or accelerating (or avoiding delay of) the schedule, it would very difficult or impossible to make the case for the added expense of those resources. The result would be that project value is often greatly reduced when it could have been rescued by going a little over budget.

Enhancing work scope and improving schedule almost always require increasing resource usage. Project resources always cost money, and the amount of money is carefully tracked. Thus the only way to justify those resources is to show the increased value of the investment. This is impossible if the expected value of scope and time arenot estimated, planned and tracked.

8.   There would be no way (and there should be!) to base project prioritization and resource targeting on investment value, either between individual projects or across the entire multiproject portfolio.

When more than one project needs a specific resource at a given time, which should get it? The initial (and correct) answer is the one that needs it on the critical path. But what if two or more projects need the resource on the critical path? The fact that one project would be delayed by four weeks while the others would only be delayed by one week each is not sufficient information. What is the cost of time (i.e., the impact of time on the project’s expected value) if each project is delayed? The four week delay might only reduce the portfolio value by $20,000, while two one-week delays on the other projects might reduce it by $100,000. Only investment analysis combined with drag cost computation can generate the correct answer.

9.   Projects would often be cancelled that should continue to be funded, and other projects that have their funding renewed should be cancelled.

Cutting the funding flow on any project is clearly an investment decision! Yet the lack of investment data makes the continue/terminate decision process fraught with angst, anger and arbitrary adjudication. Although other metrics play a role, the two most important numbers to consider are expected value and cost estimate-to-complete (factoring out sunk costs). But the lack of defining a project as an investment means that expected value is rarely estimated and even less often tracked. The basic index for this sort of decision is the DIPP, based on my article “When the DIPP Dips: A P&L Index for Project Decisions” published in Project Management Journal in September, 1992. Yet almost twenty-three years later, the most fundamental metric of that formula can seldom be produced when such a decision is necessary, and thus the wrong decision is often made.

10. Project managers would not be appreciated for what they genuinely are (i.e., investment managers entrusted with funds and responsible for ensuring maximum return through their knowledge and skills) but instead would often be regarded as “overhead on a cost center”.

The only way that our project management discipline will get the respect it deserves is by showing its value in clear monetary terms. And that means dealing with projects as investments.

There are actually many other unfortunate things that can happen due to projects not being managed as investments. But the ten listed above provide a strong foundation for the case that we need a new definition for “project”.

Fraternally in project management,

Steve the Bajan

 

A New PMI White Paper on Organizational Project Management by Joseph Sopko

PMI has just published a new white paper by Joseph Sopko titled Organizational Project Management: Why Build and Improve. The analysis and recommended implementation methods are excellent.

Topic subtitles include:

  • OPM Models: The Evolution of Best Practices
  • Projects, Programs and Portfolios — You Need All Three!
  • The Business Case for OPM Improvement
  • Conduct the OPM Improvement as a Program — Focus on Benefits

It’s an excellent exploration by someone who spent years in the field assessing organizational maturity and implementing improvements with Siemens Corporate Research. And this quote on page 19 about my book Managing Projects as Investments: Earned Value to Business Value is especially gratifying:

“Tools and practices for managing projects and programs as investments have been defined by Devaux (2014) and are very useful to executive sponsors as well as in project or program value optimization. For example, critical path DRAG is a concept for evaluating how much any activity along the critical path can be shortened to optimize the project duration… (T)o take advantage of the use of DRAG an organization must have a reliable critical path defined on its projects and quantify the benefits of accelerated project delivery (e.g., impacts on net present value [NPV]).”
I urge reading the entire paper — it’s truly excellent!

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

Weekend Puzzler: Computing the Value/Cost of Time on an Enabler Project

The past several blog articles have been discussing the value breakdown structure (VBS). We still have a bit more to cover on that topic, and I’ll get to that next week.

However, the weekend is upon us, and several readers emailed me that they really enjoy the Weekend Puzzler exercises. So I have put together one on a topic that we will get to soon: the value, and the value/cost of time, of enabler projects.

Identifying enabler projects and computing their true value is extremely important for any organization, and especially for a project manager who is trying to justify the resources that they know they will need. We will explore the important topic of projects in the coming weeks – but for now, and for your weekend puzzling, here is an exercise, with answers below, that should get across some important concepts.

If you want to learn more about managing enabler projects (and indeed, about pretty much everything in my blog!), try my two new books, Managing Projects as Investments: Earned Value to Business Value and Total Project Control: A Practitioner’s Guide to Managing Projects as Investments.

Two Projects in a Program: The Values of Project Steel Donkey and Project Rock Stone

(Among the questions below, the most important information for a project team to understand is in Question #7: the value/cost of time on an enabler project! It is crucial that business analysts provide this analysis for project teams!)

NOTE: For this exercise, all dollars are in current dollars.

You have been put in charge of Project Steel Donkey, a 12-month-long effort to develop and implement the Steel Donkey enterprise-wide system, which is expected to improve efficiency and reduce our organization’s overhead costs by $200,000 per month over the next three years. The budget for the project is $5 million.

One of the advantages of the Steel Donkey system is that, once implemented in its basic form, it can be extended.

The key planned extension is a real-time data communication system for our field personnel that should accelerate decision-making. Such an extension is expected to increase annual revenues. Our business analysts have estimated the probabilities of increase to be as follows:

  • 50% chance of $1 million/month for two years after the extension is put in place.
  • 25% chance of increase of $500,000/month.
  • 25% chance of no change.

The enhancement project, named Project Rock Stone, is expected to take 12 months, and will have a budget of $6 million.

But such an enhancement project cannot start until immediately after Project Steel Donkey is over and the overall system is operating.

  1. What is the total savings, just in overhead costs, expected for the three years after Project Steel Donkey is completed? A. $200,000   B. $720,000   C. $7.2M   D. $36.0M   E. None of the above
  1. What is the average monthly increase in expected revenue for the two years after Project Rock Stone (i.e., three years after Project Steel Donkey) is completed, if Project Rock Stone is completed on schedule? A. $13.5M   B. $15.0M   C. $24.0M   D. $27.0M   E. None of the above
  1. What would be the two-year expected project profit (EPP) of Project Rock Stone if completed on budget in 12 months? A. $4.5M   B. $10.0M   C. $18.0M   D. $21.0M   E. None of the above
  1. What is the three-year expected monetary value (EMV) of Project Steel Donkey if completed in 12 months? A. $7.0M   B. $12.2M   C. $16.2M   D. $22.2M   E. None of the above
  1. What would be the three-year expected project profit (EPP) of Project Steel Donkey if completed on budget in 12 months? A. $2.2M   B. $7.2M   C. $10.2M   D. $11.2M   E. None of the above
  1. What would be the impact on two-year revenues of finishing Project Rock Stone one month earlier or later? A. $625,000   B. $825,000   C. $7.2M   D. $11.2M   E. None of the above
  1. What would be the acceleration premium or delay cost (i.e., change in EMV) for finishing Project Steel Donkey one month earlier or later? A. $200,000   B. $825,000   C. $7.2M   D. $11.2M   E. None of the above
  1. What would be the DIPP at the start of Project Rock Stone, with a budget of $6 million and a schedule of 12 months? A. 1.50   B. 2.00   C. 2.50   D. 3.70   E. None of the above
  1. What would be the DIPP at the start of Project Steel Donkey, with a budget of $5 million and a schedule of 12 months? A. 1.50   B. 2.44   C. 3.05   D. 3.24   E. None of the above
  1. What would be the expected project profit (EPP) and DIPP be for the entire program? A. $0.2M & 1.01   B. $11.2M & 2.02   C. $22.2M & 2.02   D. $33.2M & 3.01   E. None of the above

Written down your answers? Now scroll down for the answers and explanations.

Answers to the Weekend Puzzler: Value/Cost of Time on an Enabler Project

  1. What is the total savings, just in overhead costs, expected for the three years after Project Steel Donkey is completed? A. $200,000   B. $720,000   C. $7.2M   D. $36.0M   E. None of the above

Answer: C. $7.2M.

Explanation: 36 months * $200,000 = $7.2M

  1. What is the average monthly increase in expected revenue for the two years after Project Rock Stone (i.e., three years after Project Steel Donkey) is completed, if Project Rock Stone is completed on schedule? A. $13.5M   B. $15.0M   C. $24.0M   D. $27.0M   E. None of the above

Answer: B. $15.0M.

Explanation: The expected monetary value (EMV) of potential revenues = the probability of them occurring times the value of the revenues.

The probability of generating revenues of $1M/month = 50%.

EMV = 50% * (24 months * $1M) = 50% * $24M = $12M.

The probability of generating revenues of $0.5M/month = 25%.

EMV = 25% * (24 months * $500,000) = 25% * $12M = $3M.

Total EMV of Project Rock Stone over two years = $12M + $3M = $15M.

  1. What would be the two-year expected project profit (EPP) of Project Rock Stone if completed on budget in 12 months? A.$4.5M   B. $10.0M   C. $18.0M   D. $21.0M   E. None of the above

Answer: E. None of the above.

Explanation: EPP = EMV – expected project cost

= $15M – $6M = $9M

  1. What is the three-year expected monetary value (EMV) of Project Steel Donkey if completed in 12 months? A. $7.0M   B. $12.2M   C. $16.2M   D. $22.2M   E. None of the above

Answer: C. $16.2M.

Explanation: EMV of an enabler project = the EMV of the project itself plus the EPP of all projects it enables.

Therefore the EMV of Project Steel Donkey = its own EMV + the EPP of Project Rock Stone

= $7.2M + $9M = $16.2M

  1. What would be the three-year expected project profit (EPP) of Project Steel Donkey if completed on budget in 12 months? A. $2.2M   B. $7.2M   C. $10.2M   D. $11.2M   E. None of the above

Answer: D. $11.2M.

Explanation: EPP = EMV – expected cost of Project Steel Donkey =

$16.2M – $5.0M = $11.2M

  1. What would be the impact on two-year revenues of finishing Project Rock Stone one month earlier or later? A. $625,000   B. $825,000   C. $7.2M   D. $11.2M   E. None of the above

Answer: A. $625,000.

Explanation: Impact = the gain or loss of expected monthly revenues for one month = $15M / 24 months = $625,000/month.

  1. What would be the acceleration premium or delay cost (i.e., change in EMV) for finishing Project Steel Donkey one month earlier or later? A. $200,000   B. $825,000   C. $7.2M   D. $11.2M   E. None of the above

Answer: B. $825,000.

Explanation: Impact = the gain or loss in expected monthly savings + revenues for one month on both Project Steel Donkey AND on the enabled Project Rock Stone = $200,000 + $625,000 = $825,000.

  1. What would be the DIPP at the start of Project Rock Stone, with a budget of $6 million and a schedule of 12 months? A. 1.50   B. 2.00   C. 2.50   D. 3.70   E. None of the above

Answer: C. 2.50.

Explanation: EMV = $15.0M. Budget = $6.0M.

Starting DIPP = $15.0M / $6M = 2.50

  1. What would be the DIPP at the start of Project Steel Donkey, with a budget of $5 million and a schedule of 12 months? A. 1.50   B. 2.44   C. 3.05   D. 3.24   E. None of the above

Answer: D. 3.24

Explanation: EMV = $16.2M. Budget = $5.0M.

Starting DIPP = $16.2M / $5.0M = 3.24

  1. What would be the expected project profit (EPP) and DIPP be for the entire program? A. $0.2M & 1.01   B. $11.2M & 2.02   C. $22.2M & 2.02   D. $33.2M & 3.01   E. None of the above

Answer: B. $11.2M & 2.02

Explanation: For Project Steel Donkey, the DIPP acts as a tracking mechanism for project performance. Project Steel Donkey’s the EPP (and thus the numerator of the DIPP) include all of its equity: its expected savings AND the probability-weighted increase in revenues from Project Rock Stone. However, the cost responsibilities and authority of Project Steel Donkey are limited to the costs of that project only, or $5M. That determines its value/cost of time, and those are the metrics against which it should be measured and tracked.

However, the program as a whole includes the EMVs and budgets of BOTH projects. Thus the program EPP would be:

($7.2M + $15.0M) – ($5.0M + $6.0M) = $22.2M – $11.0M = $11.2M

The Starting DIPP would be EMV divided by program budget, $22.2M / $11.0M

= $22.2M / $11.0M = 2.02

So how many did you get correct?

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

What is the True Cost of an Activity’s Work? Is It Worth It?

I have been delighted that my recent blogs about aligning the program and the project, the sponsor and the project team, have gotten a very positive response. In particular, the value breakdown structure (VBS), as a tool for accomplishing this, seems to have been very well received. So this article explores the next step, how to combine the VBS with other new investment-based techniques and metrics, to ensure that project effort and money are not being frittered away on low value products and work.

It is no revelation to the business community that projects are being completed every day that fail to generate the intended benefits. Many of these can be categorized, from an investment viewpoint, as “losses” – they cost more than they turn out to be worth.

The same principal that says that such project investments are losses also says to me that, on every calendar day and throughout the world, there will be a substantial number of projects completed that include work that costs significantly more than it is worth. No, I have not conducted a study to see if such is the case (although I think that it would be a very fruitful topic for research!). Rather, I deduce this from the fact that the following important steps in measuring both value and cost on projects are simply not being done:

  • Most projects never bother to create a value breakdown structure (VBS) and so have not even a guesstimate of what the value is of any optional scope;
  • Most projects do not bother to estimate the value/cost of time;
  • Many projects (and programs!) fail to perform even rudimentary critical path schedule analysis; and
  • Even on those projects that do perform critical path analysis, they rarely compute critical path drag and drag cost up front, and almost never re-calculate it during project performance. Such re-calculation is especially crucial when the critical path changes during execution.

If all of the above techniques are not used on a project (or program), then it is very likely that the effort will include products and work that cost more than the value they add.

My recent blog articles have discussed the essence of the first of the above points, the value breakdown structure (VBS). This is a tool for prioritizing project work packages and activities by estimating their relative importance and value. Some project components (like both the left wing AND the right wing on an airplane) are mandatory: the project cannot be completed without both of them. Other components are optional, included not because they are essential but for the value they are expected to add. If you have not yet read this blog article on the VBS, I urge you to do so now and then return to the rest of this article.

The True Cost of Work (TCW)

If would-be project sponsors could simply buy the exact product they want and have it immediately delivered and ready for use, they would elect to do so almost every time. In fact, they would usually even be willing to pay a significant premium for an off-the-shelf product that precisely meets their needs rather than funding a project to create it.

Why? Because (1) there are many more risks in creating the product than in buying something that has already been made and quality-checked, and (2) the time that it takes to create something you want almost always has a cost, and sometimes a great deal of cost!

Time is money, wrote Benjamin Franklin, and it is rarely more definitively so than when the sponsor/customer has to wait for project completion. But how much money is time worth on a given project? How much would the sponsor be willing to pay for each week earlier that they would be able to deploy the desired product?

Occasionally, it’s worth very little. Rarely, it might even be worth less if delivered early because its internal systems will start to run down and/or become obsolete. But such situations are so unusual that, when such is the case, it is crucial that the project manager and team know that this project is one of those “exceptions”! (And, by the way, it is almost always due to the fact that the specific project is part of a program but not on the program’s critical path!)

In the vast majority of cases, the value/cost of time on projects ranges from moderate to, yes, vast!

  • Our intended new product can generate no value until it’s deployed.
  • Our new product is an enabler and other revenue generators need it.
  • Competitors enter the market and make our product a “me-too”.
  • Market windows are missed.
  • Market share is lost.
  • We lose weeks in implementing a tool that will result in weekly cost reduction.
  • And sometimes humans die because of the delay.

Yet, sad to say, projects are initiated with arbitrarily-chosen “deadlines” and without any attempt to quantify the value/cost of being earlier (or, indeed, later!) than that target date.

So if an earlier deployment of a product would be worth $40,000 per week to a potential sponsor/customer, surely we can see that they would be delighted to consider an off-the-shelf product that costs $2M rather than execute a 30-week project with a $1.5M budget to create a similar product. All else being equal, the project approach would have a true cost of work (TCW) of $1.5M + (30 * $40,000) = $2.7M.

The TCW is the overhead-burdened cost of resource usage plus the value/cost of the time we lose in waiting for the work to be completed. If the work is serial in nature (i.e., one activity only, or simply one activity after another), it is easy to measure the time we must wait and “charge” each activity’s duration with the cost of that time.

But what if the work comprises a project that is part of a program that has other projects occurring in parallel? Or, onion-like, if the work is an activity in a project and it has other activities occurring in parallel?

As project managers understand, the determining factor of the duration of every project (and program!) is the work, constraints, re-work, dropped batons, and other delays that comprise the longest path, i.e., the as-built critical path (ABCP)! Activities and other delaying factors that are not on the critical path (even if with only one day of float!) are not delaying completion, and in TPC (i.e., Total Project Control) terms have zero drag – and thus zero drag cost! Therefore the true cost of work that is not on the critical path (either of the program or of the project) is simply the cost of resource usage.

But the TCW for each item of critical path work is the sum of its drag cost plus its resource usage costs. Thus comes the importance of computing these on every project and program, because without that computation, you really don’t know what each item of work is costing! And if the true cost of a work package, activity or project is greater than the value that it is adding (per the value breakdown structure), we should either figure out a way to reduce its true cost (perhaps by electing to use the DRED) or jettison it from the project (or program)!

In my next article, I will talk more about how work with negative value-added (value-subtracted?) often arises. But meanwhile, you might want to take a look at this article on drag (published here in Portuguese by Peter Mello) and perhaps at the drag cost and true cost exercises on the main page. (Or just read my two new books, Managing Projects as Investments: Earned Value to Business Value or the second edition of Total Project Control).

Fraternally in project management,

Steve the Bajan

The Value Breakdown Structure (VBS): What, How and Why?

My recent blog articles have mentioned the value breakdown structure (VBS), with a link to the Wikipedia description. Now several people have asked me expand on this concept: what does it look like, how to create one, and why is it a valuable tool?

To get across the concept, I’ve created the abbreviated VBS below for a project to build a small house. Please note that this is not intended to be a complete or comprehensive VBS – it is merely a sample designed to give a sense of the VBS structure, with certain branches (BEDROOMS, BATHROOMS) decomposed more than others. (Ultimately, the other elements should also be decomposed to reveal optional items: KITCHEN, for instance, might include an optional dishwasher and garbage disposal, as well as a mandatory sink.)

VBS for House

The VBS is a technique that I have implemented from time to time in my consulting career. I then introduced the idea in my 1999 book Total Project Control. Although I regularly taught the concept in my corporate classes, up until a couple of years ago I had assumed that the idea had not “caught on”. Then about three years ago I did a Google search on the term and discovered, to my delight, that it was being applied in several countries in Europe and the Middle East!

The most thorough description of the VBS and its application is in the second edition of my first book just out from CRC Press this week: Total Project Control: A Practitioner’s Guide to Managing Projects as Investments. I would urge anyone who finds the concept interesting to read the chapter on developing the WBS and the VBS in that book. However, let me try here to provide a thumbnail sketch of the concept.      

First, as my books stipulate, all projects and programs are investments and must be managed as such. One part of any investment is the money (and on a project, effort and time) that must be invested. In general, traditional project management does a pretty good job of this.

However, the other side of an investment is the value that the invested money is supposed to generate (which, after all, is the whole purpose of the investment!). That side of the equation is almost totally ignored. Even in cases where senior management, or the sponsor/customer, or the manager of the program of which the project is a part, has performed value analysis and has quantified the project’s expected value, that specific information is almost never passed along to the project manager and team. Yet those are the people who can really use that information to maximize the project value.

In my two previous blog articles, I have made the case that all levels of management engaged in project work have a specific role to play. The customer/sponsor and/or the program manager must ensure that the project they are funding will generate the benefits/value they want.

The business value of a project is generated by its scope, primarily the product scope. This value is then almost always impacted by the completion date. If our remote-controlled snowblower is in the stores by the three days before the first snowstorm of winter, we estimate that our sales revenues for the winter will total $25 million. However, for every week later, we anticipate a drop in revenue of 10%. Ten weeks later, our potential customers will be looking to purchase lawnmowers, not snowblowers. Although they are rarely given such information, the expected value of the scope and the value/cost of time are two crucial data items for every project team in achieving what should be their goal – to maximize the value to the investor(s).

Traditional project management loads the resource costs for program and project into the elements of the work breakdown structure and sums them to the top to create both the budget and the earned value baseline for each summary element and for the whole project and program. But the project’s expected value, even if estimated, is never tied to the specific program projects, products, work packages and work elements of scope that will generate it. Yet this is the very tool that allows the sponsor/customer/program manager to collaborate with the project manager and team to:

  1. Ensure that scope elements that will generate the desired benefits/value are clearly specified;
  2. Measure their expected contributions; and
  3. Make sure they are not actually costing more than the value they are adding (a key consideration related to the computation of the true cost of work, which I will explore in a later blog article).

The whole concept of establishing and prioritizing scope items based on their importance to the sponsor customer is not entirely new. There is in fact a technique (sometimes used in agile methodologies) called the MoSCoW method, where:

  • M stands for Must;
  • S stands for Should;
  • C stands for Could; and
  • W stands for Won’t.

The MoSCow method is an excellent place to start; but then the prioritization information should be quantified, in terms of the value that each scope item is adding, and assembled into a VBS.

When this is done, Must equates to mandatory scope – elements that must be included either because the project would make no sense without them, would have no value without them, or scope that is mandated by law or internal regulation. Mandatory scope items have a value-added equal to that of the entire project – without these items, the project has not been performed!

Should and Could equate to optional scope items – they don’t have to be included, but they will add some value. Whether or not they are included should depend on their value versus their cost.

As the house VBS above shows, value behaves differently from cost. Whereas cost is always additive (the sum of the costs of five detail activities ALWAYS is equal to the dollar cost of their parent summary activity), value is not. The value of two activities may be more than the sum of each, i.e., they may either duplicate some of the other’s value or kindle each other’s value. For example, on a small airplane that is expected to be sold for $100,000, although both the left wing and the right wing are mandatory and therefore each has a value-added of $100,000, the value-added of “wings” is NOT $200,000 – value just works differently than cost.

In looking back at that house project VBS, notice that the value-added of each of the two bathrooms is $200,000 for the first and $40,000 for the second. In other words, until the house has a bathroom it will not get an occupancy permit and it will basically have zero value. So the first bathroom is mandatory and therefore has a value-added equal to 100% of the value of the project. But the second bathroom is optional, with a value equal only to the difference between what we could expect to sell it for with one bathroom versus with two. Please note that it is not intended to be a complete or comprehensive VBS – it is merely a sample designed to give a sense of the VBS structure, with certain branches (BEDROOMS, BATHROOMS) decomposed more than others. (Ultimately, the other elements should also be decomposed to reveal optional items: KITCHEN, for instance, might include an optional dishwasher and garbage disposal, as well as a mandatory sink.)

As I expect to show in a future article, optional activities are actually the ones that allow opportunities for decision-making and optimizing of the project investment.

Are you finding the VBS topic interesting? If so, please consider indicating this fact to me by selecting the appropriate option in the embedded poll below.

Fraternally in project management,

Steve the Bajan