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!)