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

 

Why is Critical Path Analysis Not Being Used?

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

Ngram

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

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

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

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

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

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

There is an old project management adage:

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

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

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

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

 

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

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

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

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

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

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

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

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

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

Fraternally in project management,

Steve the Bajan

Of Saltines and Deadlines

 Sltine

From Wikipedia.com: A saltine… is a thin, usually square cracker made from white flour, shortening, yeast, and baking soda, with most varieties lightly sprinkled with coarse salt.”

*****************

Most people would say that the “essence” of saltines can be found by simply adding an ess: saltiness.

*****************

There is no question that projects are time-sensitive. Every week, day and hour that elapses until a project reaches completion means one more week, day or hour before its product, service or result is delivered. That result is what those who provided the project’s funding and/or resources are waiting to get. The longer they have to wait, the longer before that final product starts to generate its benefits. And that time can be extremely costly.

Schedule delay generates value decay. Sometimes more, sometimes less, but it is almost always the case that there is some reduction in the value of the return on a project investment due to the need to wait until the work is finished. The solitary exception is where the project’s completion will not shorten the overall schedule because of either:

  • External factors, such as needing to wait until the passing comet is within range before launching our space probe, or
  • The fact that our project is part of a larger program, and not on the critical path of that program. If some other project is on the program’s critical path, then our project finishing early will only give its schedule float within that program.

On some projects, the value/cost of finishing earlier or later can be huge:

  • On a nuclear plant refueling outage, every day off-line can cost more than $1 million.
  • On a new pharmaceutical development project, every day of delay can be many millions of dollars, especially if it means the difference between being first and second to market.
  • There may only be a small increase in revenues if we get our new hotel opened before the tourist season starts – but the losses for every night after the start could be enormous.
  • A delay in deploying a new software system to support our sales teams in the field could mean a reduction of 20% in expected sales for every day.
  • Taking an extra hour to send in emergency response teams after a major earthquake could result in hundreds of additional deaths of those trapped beneath the rubble.

In addition, on every project, early completion retires 99% of the risk of being late. Such risk reduction (and the accompanying savings on anti-stress medications!) can often be worth a great deal to the sponsor/customer. The fact is that although stakeholders may just say they want the product by a specific deadline for a specific budge, if told they could have it earlier they would almost always be delighted and willing to negotiate an incentive bonus for such performance. They would be more likely to give the project/contract to a team that offers to beat the targets.

Project time is managed through the schedule –specifically, the critical path which, being the longest path through the project, determines its completion date. (If the project is delayed by a different path, that only means that we hadn’t correctly figured out the actual longest path!) And what does the critical path schedule give to our projects? It gives the timelines along which the work is scheduled, so that we can see that we need to finish laying the foundation by the end of May if we want our hotel to open at the start of the tourist season. And what is the essence of such detailed timelines on our projects? Timeliness, of course – as with saltines, just add an ess!

Unfortunately, awareness of the value of being early on projects has become almost nonexistent. Instead of planning and working to be early, project teams today often simply go on the defensive – they work to not be late – to deliver just in time! And often, they fail to do even that.

During the US Civil War, prisoners of war were kept in camps like Andersonville, where a line would be drawn in the dirt some twenty feet inside the outer perimeter. That was the deadline – if you stepped beyond it, the guards would shoot you. And around the 1920s, the term became a dead metaphor with the meaning adapted as referring to a time limit. The diagram below shows the Google Ngram Viewer graph of growth in usage of the term in five million digitized books over the course of the 20th century.
ngrm

Figure 1. Google NGram Viewer picture of the usage of “deadline” in books

But with the original meaning of deadline, if you go beyond it, you’re dead! And that is very different from the way the term is flung around today. Are there cases where being one day late makes a project worthless? Sure, and there the term may be appropriate for use. But in the vast majority of cases, deadline simply signals a drop-off in value. And often not even that! It is often just an arbitrary date pulled from the nether regions of the sponsor’s anatomy.

The first two things that every project team should ask upon being given a deadline are:

  1. If we can schedule the project to finish earlier, what value would each day/week have for you?
  2. If for some unknown reason we finish late, what impact would that have on the value of the project for each day/week?

And ask the two questions in that order. The goals of the team should be to:

  • Change the concept from deadline to target date.
  • Establish as part of the project’s business proposition what the value of time is to the customer.

With that information, we not only can seek opportunities to increase the project’s business value through schedule compression using techniques such as critical path drag and drag cost, but also potentially negotiate both a larger budget and early delivery incentives.

But that is not being done. Instead, teams are being presented with arbitrary deadlines, and then they work to try to achieve them just-in-time. And then something unplanned happens and they delivery somewhat-beyond-time instead. And although the deadline may have been arbitrary, there is nevertheless almost certainly a decline, perhaps a precipitous one, in the project’s expected value.

Add an ess to deadlines and you get… deadliness!

Project Management in History: Adolf Hitler and the Balkans Fragnet

I wasted time, and now doth time waste me.” – W. Shakespeare, Richard II, Act V, Sc. 5

Not all discretionary dependencies should be injected into project schedules. Adolph Hitler planned Operation Barbarossa, the invasion of Russia, for late spring 1941. This would leave his blitzkrieg attack plenty of time to capture the major Soviet cities of Moscow and Leningrad before the onset of the brutal Russian winter.

But then Hitler’s ally Benito Mussolini ran into trouble in Greece. The Greeks, supported by British forces, dealt the invading Italian Army such heavy casualties that they were threatening to hurl them back across the border. If this happened, Greece might provide the Allies with a base for counterattack through the Balkans, the “soft underbelly of Europe” that Churchill had so coveted as a second front in the First World War.

Hitler decided to delay his invasion of Russia, and instead opted for a discretionary fragnet. He delayed Operation Barbarossa and instead sent massive German reinforcements into Greece to aid the Italian Army on April 6th, 1941.

When Operation Barbarossa was finally launched on July 22nd, Hitler’s Wehrmacht carved through the cities of the Baltic countries and the Ukraine. By November, they were advancing on Moscow and Leningrad. And then came the rain, and the mud, and the cold, and the snow. Just before Christmas, in the suburbs of Moscow, the advance staggered to a halt, and the German soldiers spent an icy winter freezing in their summer uniforms and boots while the Soviets steeled themselves for the spring.

Balkans

The inclusion of this discretionary predecessor (i.e., shoring up his Balkan flank) is generally considered to have cost Hitler about six weeks, altering his project schedule by replacing the months of June and July with the autumn months of November and December. The result, as we know, was disastrous for the Third Reich.

In both the Panama example we discussed in the previous blog and in the Operation Barbarossa example, the leaders were very definitely engaged in project management. Although they were probably not familiar with such intricacies of modern scheduling as the critical path method (CPM), critical path drag, and drag cost, they must have recognized that delay in the early stages of each project would lead to a costly delay at the end. The cost of the drag would in one case be additional months before the canal would begin accruing value by allowing ships to pass through. In the other case, millions of German lives would be lost due to the decreased time available for the capture of Moscow and Leningrad. Ultimately, the weather that first winter that rendered the German tanks and other equipment unsuitable for offensive operations may have been the single greatest factor in saving the world from Hitler.

Now, it has long been held by military historians that Hitler’s delaying the invasion of Russia was a huge blunder. But was it? Is it not possible that, had Hitler ignored Mussolini’s predicament and gone ahead with the planned invasion in the spring, West Point students today would be hearing about Hitler’s monumental blunder of embarking on an invasion of the Soviet Union without first shoring up his Balkan flank? That he’d allowed that wily strategist Winston Churchill to use the same Balkan strategy he’d once tried fruitlessly to employ through Gallipoli? Only this time Churchill was able to use free Greece as a readymade base for attacking through the soft underbelly of Europe and up into the unprotected areas of Austria and Czechoslovakia, far behind the vast German divisions engaged in pacifying Russia and the Ukraine.

We will never know. Did Hitler conduct appropriate cost/benefit analysis into the value of time on the critical path versus the risk of an exposed southern flank? Probably not. And certainly there is no “project documentation” or even minutes of a strategic meeting to tell us how the decision was made. It was probably based on a “gut feeling” – and those things often stink.

The Time is out of Joint.”W. Shakespeare, Hamlet, Act I, Sc. 5

Hitler’s blunder may not have been to delay Operation Barbarossa, but to fail to recognize that inclusion of such a discretionary dependency caused not just a change of time, but of timing! That dependency inserted an optional “fragnet” of work whose drag greatly increased the risk of weather-related factors. Making war in Russia in June and July is completely different from making war there in fall and winter. The very resources of war change: a tank that could advance two hundred miles in a day, dealing lightning death as it went, metamorphosed into an almost-stationary gun, periodically requiring shovel-wielding infantry to free its tracks from the mud. Both armor and infantry became easy targets and the productivity of automation that had permitted advances of 200 miles a day slowed to a trickle of ten or less.

The American poet James Russell Lowell once wrote: “Truly there is a tide in the affairs of men; but there is no gulf-stream setting forever in one direction.” Wasting time is always a mistake, but using additional time to meet a goal is sometimes correct, sometimes wrong. Whether in war, foreign or public policy, business, or family projects, such use of time should be subject to analysis and decision, with a focus on which specific items are causing the time, how much delay each is causing, and what is the cost (in dollars, but also in lives and pain), that the delay is causing or risking.

Both nations and corporations need to ensure that the correct processes are in place to analyze the benefits and costs of competing strategies in the right way. And that means always evaluating the value/cost of time on any projects critical path – in other words, the drag cost of each activity.

Project Management in History: Teddy Roosevelt and the Panama Fragnet

There are two separate types of “dependencies” in project scheduling. They are called “hard” and “discretionary” dependencies.

Hard dependencies can be defined as constraints that are embedded in the laws of nature: you can’t boil the egg until you boil the water, and you can’t boil the water until you apply heat. You may wish that such were not the order of things, but it is. And the time it takes to do each of those tasks determines how long you have to wait for your hard-boiled egg. Both projects and history are at the mercy of hard dependencies.

Conversely, discretionary dependencies are optional, applied by decision – of the project manager, or of the various actors in history. Sometimes such decisions are wise, sometimes they are disastrous, and sometimes we never know because the way things worked out is the only history we have.

T.R. and the Panama Canal

Theodore Roosevelt knew that to make the U.S. into a major sea power, its navy needed the ability to sail quickly between the Atlantic and Pacific Oceans. A predecessor for such mobility was the construction of a U.S.-controlled canal through Central America that would allow rapid transfer of Navy vessels between oceans. For a variety of reasons, including internal political ones1, the optimum location for such a canal seemed to be the isthmus of Panama, which at the time was part of the country of Colombia.

But the Colombian government was proving difficult to work with. Roosevelt’s administration, in Machiavellian manner, fomented and supported a revolution that placed the isthmus under the sovereignty of the new nation of Panama, a government obligated to the U.S. for its very existence.

With a project manager’s eye, Roosevelt chose a location where it would be possible to cannibalize work that had already been accomplished the long-desired “path between the seas” would be created on the ruins of the French effort that had lost steam and foundered in the jungle two decades earlier. What had been the main cause of the French failure? Yellow fever, which along with malaria, had killed thousands of engineers and laborers brought to Panama to dig the canal.

Yellow fever would almost certainly have doomed the American effort as much as it did the French. But timing is everything! During the U.S. occupation of Cuba following the 1898 Spanish American War, Major Walter Reed had succeeded in confirming the theory of Cuban scientist Dr. Carlos Finlay – yellow fever was caused not by contact or aerial transmission, but by mosquitoes. And, with even more serendipitous timing, the India-born British doctor Ronald Ross had also tied malaria transmission to mosquitoes in 1897.

The discovery of yellow fever’s cause is sometimes viewed as a hard predecessor for the great American construction effort, one without which the American canal effort would have been as doomed as its French predecessor. But the fact that the mosquito danger was understood by the Americans did not necessarily mean that they had to address it! They could simply have accepted the risk instead of trying to mitigate it.

It would require great expense to eliminate the threat: time to clear the jungle around the working and living areas, to drain wetlands, to pour oil in stagnant pools, and to provide screens for worker domiciles. All this work (in project management terms, a fragnet) would likely delay, by months or years, the eventual opening of the canal. Decreasing or eliminating the yellow fever threat might be very advantageous, but it still was in fact a discretionary predecessor, to be performed or not on the basis of cost/benefit analysis.

Was such analysis performed? In project management terms, did Roosevelt and his planners determine all the work they were going to have to do in building the canal, assemble a critical path method (CPM) schedule, and determine both the end date and the number of lives that would be lost during those years of effort?

Did they then plan out the fragnet of work for resolving the disease threat, plug it into the rest of the schedule, see how much time it added, and compute the fragnet’s critical path drag, its drag cost in terms of the delay in the utility of using the canal, and the value-added from a value breakdown structure (VBS) in terms of reduced deaths? And did they then have a conference, shouting back and forth about whether or not the delay in America’s strategic advantage outweighed the cost of the unmitigated risk of greater mortality?

It seems highly unlikely that any of that analysis was performed. Yet the Americans made, perhaps through luck, what in hindsight we would regard as the correct management decision. With the failure of the French effort as a reminder, they took the time to deal with the mosquito threat. Whereas 22,000 lives were lost to yellow fever and malaria in thirteen years of the French effort (during which only about a quarter of the eventual distance was traversed), fewer than 6,000 lives were lost to all causes during the ten years of the American effort, and almost none to yellow fever after 1906. Instead of the pool of willing workers in the West Indies drying up out of fear of death in a faraway jungle (as happened with the French effort), laborers were eager for the comparatively good paying work. Almost half of the adult males of the island of Barbados, approximately 20,000, would ultimately work on the canal, sending money back to their families and acquiring new skills with a variety of machinery. And once they were there and trained, they didn’t die by the hundreds, requiring new workers and the expense of renewed training.

Whatever the reasoning, history has justified the American decision-making process. In Part 2 of this series, we will see how another decision regarding the inclusion of a delaying fragnet during the Second World War may have led to less satisfactory results.

1 This topic is wonderfully covered in David McCullough’s The Path between the Seas: The Creation of the Panama Canal (1870-1914), (Simon & Schuster, 1977).

Marshall McLuhan was Right!

I recently had a discussion with a project management acquaintance who pointed to the fact that my approach was basically “tools-and technique stuff.” He was more interested, he said, in organizational- and behavioral-based approaches.

This was slightly disturbing to me because, despite the fact that much of my work over the years has been in the tools-and-techniques-based stuff, I nevertheless feel that the behavioral and organizational aspects are more important than the tools! So do I feel that my focus on techniques and metrics is somehow misguided, or at least of lesser importance? No, because it’s my strong feeling that it is largely the inadequacies of the metrics and techniques of traditional PM that lead to poor organizational processes and behaviors.

In fact, my new book Managing Projects as Investments: Earned Value to Business Value is precisely about this subject. It focuses on how these problem metrics (and omissions) can have really negative impacts on organizational processes and the behaviors of project teams, project managers, and even on departmental managers and executives. For example:

The failure to define “project” and “program” as investments (and all of them are!) has both the behavioral and organizational process effect that they are not being planned, measured and tracked as all other investments are, on the basis of ROI. And, as investments, no metric is more important!
The failure to monetize the value/cost of time on a project in terms of its impact on the ROI leaves time as an externality, and the well-known behavioral impact of items left as externalities is that their value/cost is treated as zero. This makes it almost impossible to justify additional resources, because their cost is always very much monetized!
The use of “deadlines” causes myriad bad behaviors: from padding, to clandestinely cutting scope and quality, to Parkinson’s Law, and to the well-known principal/agent problem and moral hazard on contractual projects.
The use of earned value schedule tracking (as opposed to cost tracking, which is a good technique) leads to work being performed out-of-sequence specifically to game the tracking system.
All these issues, and others like using utilization rate as the functional managers’ metric, or the impact of multitasking on project schedules, are well worth examining from the process and behavioral side.

My new book explores them all, and I plan to discuss them further in upcoming articles for this blog. It is my contention that many of these issues are invisibly (because ROI is not being tracked!) eroding the value of project and program investments. The fact that what is emphasized and measured is what people pay attention to is a real problem if the wrong things are being measured and tracked. Marshall McLuhan was right – the medium is the message. And many of the problems in the practice of project management are behavioral issues generated by the medium of the metrics and techniques that are being emphasized.

Fraternally in project management,

Steve the Bajan

Turning Iron into Gold!

That old Iron Triangle is rusty! The term has been applied to many things, including specific locations in the Korean, Vietnam and the second Iraq Wars. I first heard it when I was in Vietnam in 1970, used to describe territory northwest of Saigon, near the Parrot’s Beak and the Cambodian border. It was given that name because it was well known as an area where the Vietcong were very strong.

 

Some years ago, the name came to be applied to the three project parameters, scope, time and cost, that comprise the well-known Triangle Model of a project. Over the years, some have tried to add other project parameters such as risk or quality. Both risk and quality are important considerations on any project. But risk is simply a modifier of the three traditional sides, a factor that can impact scope, time and/or cost. And quality is just an aspect of scope (product and/or project). It may be important to emphasize and ensure quality on a given project. Yet there seems no more reason to “separate” it from the other aspects of scope than to separate out and draw new sides into a polygon to represent all the various factors that go into cost: labor, equipment, materials, overhead, travel, etc.

 

So the traditional Iron Triangle still works as a model of a project. Yet it needs to be updated. It used to be that we lived in a world where we could just describe Sandy Koufax as a “great” baseball pitcher or Garfield Sobers as a “great” cricket allrounder, or say that a candidate has a “great” chance of winning an election. But today that is all insufficient. What does “great” mean in numbers? In any barroom argument, someone is likely to ask: “What do the numbers say?” Was Koufax “greater” than Pedro Martinez? Sobers better than Jacques Kallis? Do the polls favor the Democrats or Republicans to win the Senate?

Numerical analysis should especially be important whenever we talk about an economic enterprise, which every project clearly is. Any time we are going to have to spend money, numbers should be the essence of the discussion.

  1. How much will we have to spend?
  2. How much will we get back?
  3. How long before we generate that return?

Every project is not only an investment, but one for which the answers to those questions is largely determined by the three sides of the Iron Triangle.

  1. Cost is what we have to spend on resources to perform the project.
  2. Scope is the reason we’re spending that money – its value will generate the return on our investment.
  3. Time is the duration of the project, the length of its critical path that determines how long it will be before we start generating the return on our investment.

Cost and the expected value of the scope are clearly measured in monetary units – how many dollars (or euros or yen or rupees) will we have to invest and how many will the scope be worth?

Time, however, is measured in calendar units – how long till the project is finished and its valuable scope is deployed? Almost always, we would like that time to be as short as possible – schedule delay causes value decay. How much decay? That too is a dollar figure for every day or week that passes until the scope is completed. And now all three sides can be quantified in dollars, as is shown in the diagram on the front page of this website:

 

That formula for expected project profit is the essence of the project investment and represents the whole reason why the sponsor or customer is willing to invest money in the project – because if the scope is completed by a specific date, it should have more value than it cost. And almost always, the sooner it’s completed, the great that value.

With most investments, the investor is completely at the mercy of events over which he or she has zero control: the price of oil, the climate, the Federal Reserve Bank, the demand for housing, a change in bond rating. There are factors external to a project that also can impact its value – all investments contain a measure of risk. But at least there are aspects to a project investment for which due diligence and good decision-making can provide a substantial measure of control.

Shouldn’t we at least quantify, in monetary terms, the parameters of all our project decisions? Because they all are right there, in the three sides of the project triangle: scope, time and cost!

But let’s not regard the quantified triangle as “iron” anymore – it’s a Golden Triangle now.

Fraternally in project management,

Steve the Bajan

The Essence of Every Project

My new book, Managing Projects as Investments: Earned Value to Business Value was published by CRC Press last week. As a result, I have decided to start this blog to discuss and answer any questions that readers may raise. And periodically, I will post new blogs as thoughts occur to me about this fascinating management science known as project management.

After several decades of thinking about the topic, it has become clear to me that the essence of every project and program is as an investment in work. No sponsor/customer ever funds a project unless s/he believes that the eventual value to him or her will be greater than the needed amount of investment. And this means that, like all other investments, a project’s purpose is always to generate more value than it costs.

Value above cost, or “profit”, is relative – all else being equal, a project that generates value worth 150% of its cost is better than one which generates 140% of its cost. This certainly is the way that all other types of investments are judged: government securities, real estate, common stocks, mutual funds, gold, taxi medallions,…

Yet projects are the only form of investment where investment metrics such as ROI and profit are not the prime metrics for decision-making. Instead, the “success” or “failure” criteria applied to projects are usually based on completing them by an often-arbitrary deadline and for an arbitrary budget. And whether they might have perhaps generated much more value without these numerical straitjackets is left unexplored.

And this is really unfortunate because, unlike many other investments, projects are a special type of investment: one where human effort advised by appropriate analysis can bring great rewards.

This is the focus of my new book. And this and the new techniques and metrics described in that book will be subject of the new entries in this blog.

If the reader wishes to know more about my approach, the four Wikipedia pages linked to the topics below should provide a thumbnail.

(And of course, my book has much more information!)