Managing Project Uncertainty: From Variation to Chaos

Uncertainty is an inevitable aspect of most projects, but even the most proficient managers have difficulty handling it. They use decision milestones to anticipate outcomes, risk management to prevent disasters and sequential iteration to make sure everyone is making the desired product, yet the project still ends up with an overrun schedule, overflowing budget and compromised specifications. Or it just dies.

To find out why, we studied 16 projects in areas including personal-computer development, telecommunications, Internet startups, pharmaceutical development, iron-ore processing, airship development and building construction. Interviews with team members and scrutiny of project documentation over five years showed managers consistently failing to recognize that there are different types of uncertainty, each of which requires a different management approach. The lack of awareness is understandable, given that the commonly accepted definition of a project (“a unique interrelated set of tasks with a beginning, an end and a well-defined outcome”) assumes that everyone can identify the tasks at the outset, provide contingency alternatives and keep to the same overall project vision throughout.1 Those are fair assumptions for routine or well-understood projects, but not for novel or breakthrough initiatives, which require companies to rethink the traditional definition of a project — and the ways to manage it. (See “Beyond Risk Management.”)

A more forward-thinking approach is uncertainty-based management, which derives planning, monitoring and management style from an uncertainty profile comprising four uncertainty types — variation, foreseen uncertainty, unforeseen uncertainty and chaos. From variation to chaos, managers move progressively from traditional approaches that are based on a fixed sequence of tasks to approaches that allow for the vision to change, even in the middle of the project.

What Uncertainty Looks Like

Some projects have few uncertainties — only the complexity of tasks and relationships is important — but most are characterized by several types of uncertainty. Accepted practice is to classify uncertain events by their source (technical issues, market, people, cost, schedule and quality) or by potential impact.2 Our categories, however, emphasize uncertainty as it relates to project-management techniques. (See “Characterizing Uncertainty in Projects.”) Although each uncertainty type is distinct, a single project typically encounters some combination of all four.

Variation

Variation comes from many small influences and yields a range of values on a particular activity — activity X may take between 32 and 34 weeks, for example. At the start of projects characterized by variation, managers know the sequence and nature of activities and have clearly defined objectives. The project plan is detailed and stable, but schedules and budgets vary from their projected values. A shifting schedule causes the critical path (the train of activities that determines overall project duration) to move, forcing project managers to monitor variations across the board, not just critical activities. In a construction project, for example, myriad events (worker sickness, weather, delayed parts delivery, unanticipated difficulty of tasks) influence budget, schedule and specifications. Such influences are too small to plan for and monitor individually, but the project team could plan for and monitor the resulting variations in expense and time.

Foreseen Uncertainty

Foreseen uncertainties are identifiable and understood influences that the team cannot be sure will occur. Unlike variation, which comes from combined small influences, foreseen uncertainty is distinct and may require full-blown risk management with several alternative plans. Pharmaceutical development typifies foreseen uncertainty. It is geared toward detecting and managing risks, primarily in the form of drug side effects. A developer of a new drug can anticipate possible side effects because they have appeared previously in related drugs. It then can outline contingency plans to change the prescribed dosage or restrict usage to certain indications or well-controlled circumstances. The side effect is the foreseen uncertainty. The contingency plan may never be used, but it is there if the side effect occurs.

Unforeseen Uncertainty

As its name suggests, unforeseen uncertainty can’t be identified during project planning. There is no Plan B. The team either is unaware of the event’s possibility or considers it unlikely and doesn’t bother creating contingencies. “Unknown unknowns,” or “unk-unks,” as they are sometimes called, make people uncomfortable because existing decision tools do not address them. Unforeseen uncertainty is not always caused by spectacular out-of-the-blue events, however. It also can arise from the unanticipated interaction of many events, each of which might, in principle, be foreseeable. Unforeseen uncertainty occurs in any project that pushes a technology envelope or enters a new or partially known market. Pfizer’s block-buster drug Viagra, for instance, began as a heart medication to improve blood flow by relaxing the arteries. When clinical studies found that it also increased sexual performance, the company ended up developing that unexpected side effect into a block-buster drug, implementing new clinical development and a new marketing approach midway through the original project.

Chaos

Whereas projects subject to unforeseen uncertainty start out with reasonably stable assumptions and goals, projects subject to chaos do not. Even the basic structure of the project plan is uncertain, as is the case when technology is in upheaval or when research, not development, is the main goal. Often the project ends up with final results that are completely different from the project’s original intent. For example, in 1991, Sun Microsystems conceived of Java as software to drive a controlling device for household appliances. It wasn’t until 1995 that Java became hugely successful as a programming language for Web pages. Ironically, a decade after Java’s conception, we are finally seeing consumer-appliance applications for it.

Creating Uncertainty Profiles

In the rare projects that have little uncertainty, the project manager is primarily a coordinator and scheduler — planning tasks according to experience and using task-breakdown structures and critical-path methods. Relationship management consists of identifying conflicts, clarifying responsibilities and defining deliverables. Monitoring consists of comparing budget, schedule and deliverables against the project plan, coordinating stakeholders and suppliers and enforcing deliveries.

The greater the uncertainty inherent in a project, however, the more the team may have to redefine the tasks — or even the structure of the project plan — in midcourse. It is much easier to do that if everyone has begun the project with the same assumptions about how changes will be managed. The mechanism that ensures agreement is the uncertainty profile — a qualitative characterization of the degree to which each type of uncertainty may affect the project. For example, although the dominant uncertainty an Internet startup faces may be chaos (for example, the potential for fundamentally changed circumstances), it also may face variation (IT implementation taking longer than planned), foreseen uncertainty (market entry by a competitor) and unforeseen uncertainty (human-resource issues).

The uncertainty profile is the team’s subjective estimate and indicates which uncertainty types are potentially the most important. To help identify the dominant uncertainty types, teams may use hunches based on previous projects or may adopt more formal approaches, such as statistical analyses, technology and market forecasts, scenario planning or creativity-management techniques. Teams draw from many sources to create the profile. Its form is not as important as its purpose — to ensure that everyone understands the major uncertainty types faced and how each uncertainty type influences management style.

Once a profile is created, it can be used to build a project infrastructure to execute a plan (in the case of variation or foreseeable uncertainty) or to learn from events and adjust (unforeseeable uncertainty or chaos).3 The project manager’s role and the planning and monitoring activities change as the uncertainty profile evolves. So flexibility — and the ability to communicate changes — is key.

Managing Variation

In projects subject primarily to variation, the project manager is first and foremost a troubleshooter who can identify deviations and push through solutions to get the project back on track. Radical changes to the plan are not the concern as much as how to control slippage in the budget, schedule and deliverables. If no one has planned for variation, the project manager must resort to firefighting to get the project back on track — a waste of resources and a drain on stakeholders. A better approach is to account for variation during project planning and build in buffers at strategic points in the project — for example, increased capacity or budget reserves.4 Top management must respect those buffers and avoid treating them as bargaining chips to be negotiated away.

Once the critical path is established and appropriate buffers are defined, managers need procedures for monitoring progress and authorizing changes in the project plan, such as expediting certain tasks.5 Formal methods such as statistical control charts let managers monitor variations without identifying the small, underlying causes. They can track performance variables —such as days ahead of or behind schedule, or differences between the budgeted and current project cost. As long as the variable stays within an acceptable range, no action is needed. But once it falls outside the range, managers must identify causes and take action. The project team must have the ability and authority to react, for example, by shifting suppliers’ and subcontractors’ intermediate delivery dates. Reacting to significant deviations is more effective than monitoring every small critical-path variation in an endless battle to stay the course.

The Mobile Systems Unit (MSU) of Taiwan computer maker Acer learned the importance of that principle in its development and manufacture of PC notebooks.6 Notebook development happens under extreme time-to-market pressure, and in 1998, MSU development cycles had shrunk to eight months. Missing the market introduction window by only one month on a given model virtually eliminated the unit’s profit potential for that model.

MSU saw that missed introductions were due to significant schedule variations with multiple causes. Vendors would occasionally not deliver sufficient volumes of a promised new component on time. Major customers such as IBM would change their requirements. Design problems with the motherboard would cause an additional design loop. Negotiations among multiple parties might change internal specifications. Relentless pressure on the engineers and insufficiently documented procedures would lead to shortcuts in testing, causing major rework at a more costly stage.

Acer attacked the multiple causes on multiple fronts. First, MSU management created buffers in the form of slack capacity by killing two projects that were already delayed. That wasn’t easy, because one project was to be a top-of-the-line model and the decision to kill it was hotly contested. (The controversy ultimately prompted Acer to adopt a more focused market-segment strategy.) MSU then concentrated on improving the way it documented operating procedures so that it could increase testing coverage and facilitate training of young engineers. Those steps reduced the number of correction loops during product development and improved the quality of the company’s manufacturing ramp-up. Acer also concentrated the responsibility for product specifications in one group, reducing negotiation loops and internally caused specification changes. Over the next two years, MSU more than doubled its sales and gained significant market share.

Managing Foreseen Uncertainty

In projects with major sources of foreseen uncertainty, project managers must first identify events that could affect the project. The task could be as simple as making a list of risks or opportunities and identifying different courses of action to deal with events as they materialize. Although critical-path methods are still good for handling complexity, there also must be some way to represent the potential influence of foreseen uncertainties. The decision tree — a graphic that helps managers to consider and communicate the effects of early decisions on later uncertainties and thus on later decisions — is a useful approach.7 Each branch of the tree represents a contingency plan for a major foreseen uncertainty.

To track projects featuring unforeseen uncertainty, teams must monitor not only which activities are complete, but also which branch of the decision tree has materialized. The manager shifts from master scheduler and troubleshooter to reactive consolidator of what the team has achieved so far. With unforeseen uncertainty, managers must ensure all parties know the contingencies and, from the project’s outset, buy into the alternative plans and outcomes. During the project, managers must constantly monitor all risks and communicate them to stakeholders.

It is dangerous to ignore foreseen uncertainty. Consider the case of the pharmaceutical company Alpex (not its real name), which launched Nopane in Germany in 1995. Nopane was an effective painkiller with blockbuster potential.8 The company knew of several life-threatening potential side effects, which it carefully controlled and ultimately eliminated during clinical trials. One less dangerous side effect was low blood pressure to the point of dizziness and fainting. Patients could avoid that effect if they kept their pulse rate below 120 beats per minute for five days after taking Nopane. Unfortunately, many patients ignored the warning. After 700,000 packets of Nopane were sold in the first six months, 500 fainting cases — a few of them well publicized — occurred because patients exercised too soon after the drug had controlled their pain. The German health agency ended up restricting the drug to a small niche, and Alpex lost the chance to market a blockbuster.

Alpex could have used more-disciplined management in introducing Nopane. The company had seen signs of irresponsible patient behavior and fainting in the U.S. trials and also in China, where the drug was introduced in 1993, but certain stakeholders argued against the relevance of the U.S. and Chinese experiences to the German market. Alpex developed no formal contingency plans for the low-blood-pressure effect.

Also, Alpex marketed to doctors, which clouded its vision of the behavior of real customers — patients. Moreover, an organizational rift stunted effective oversight, and early warning systems broke down. High expectations and rigid managerial systems kept the company from fully responding to what should have been anticipated. When the German health agency discovered there had been signs of the side effect during clinical trials, it reacted strongly. That was the end of Nopane’s large-scale potential.

If stakeholders had agreed on a contingency plan for non-threatening side effects — perhaps testing the drug outside the hospital under more realistic conditions of patient behavior —the causal link between exercise and fainting would have been harder to ignore.

Managing Unforeseen Uncertainty

Unforeseen uncertainty makes contingency planning more difficult because the project team cannot anticipate everything. Because it is impossible to create a complete contingency plan, the plan must evolve as the project progresses. Teams must go beyond mere crisis management and continually scan for emerging influences — either threats or opportunities. When enough new information arises, they must be willing to learn and then formulate new solutions. To deal with unforeseen uncertainty, project managers must move from troubleshooting to opportunistic orchestrating and networking.

As the manager of the Ladera Ranch earth-moving project in California notes, “Fifty percent of my job is managing relationships with our subcontractors, regulatory agencies and landowners. Thirty percent is scanning the horizon more than three months out to identify potential problems while we can still do something about them. The final 20% is driving to the site and keeping track of what is really happening.” Tools such as Gantt charts — graphical representations of the exact timing of all project activities — are inadequate. As the team manager observes, “A Gantt chart is more a reflection of what happened last week, and what someone hopes will happen next week.”

The Ladera Ranch team moves millions of cubic yards of dirt for independent builders in Southern California needing house pads, streets, water runoff, landscaping and utilities. The major objective is to plan the cuts and fills in a way that moves dirt the shortest distances possible. Although geological studies exist, the moisture level and exact soil type are unpredictable. That’s a problem because moist earth requires more excavation and takes longer to settle before anyone can build on it. A project team might opt to dry the dirt rather than delay selling lots. Also, some soil types may require different slopes for stability and that can affect the amount of flat area available for houses and streets.

The Ladera Ranch team is forced to deal with unforeseen uncertainty. The number of scenarios proliferates with the number of locations considered. The team could, in theory, handle that problem as a series of foreseen uncertainties, building a contingency plan for each scenario. (“If soil is moist and type X at location Y, use Plan A. If it is dry and type Z, use Plan B.” And so on.) However, that rapidly becomes infeasible because of the interdependence of cuts and fills across locations. Sometimes, markedly unexpected events — such as the discovery of prehistoric Indian ruins or a rare animal or plant species — can alter the operation completely.

The Ladera Ranch project-management team is run on principles its project leader saw firsthand in the U.S. Marine Corps: “Every play we run,” he says, “is an option play. I want my people to be able to make decisions in the field without having to report back to me every time something comes up.” The team meets weekly to discuss whether the project or target path will change and, if so, how. The approach ensures that team members view unforeseen uncertainties as incrementally solvable problems, not roadblocks or rationales for underperformance.

With unforeseeable uncertainty, a lot of time and effort must go into managing relationships with stakeholders and getting them to accept unplanned changes. Stakeholders often dig in, so much of the manager’s job is to anticipate and soften resistance by creating flexible contracts and keeping stakeholders well informed. Top-management support, negotiation techniques, team-building exercises and the project manager’s charisma can help resolve conflicting interests.

The project management team at Ladera Ranch has worked hard to share subcontractors’ risk, recognizing that taking advantage of a supplier today limits flexibility tomorrow. The relationship is characterized by trust and relieves both the management team and the subcontractors of having to anticipate every little event. Without such trust, no subcontractor would cooperate until the project team had drawn up a formal contract — a barrier to handling unforeseen events. A high degree of flexibility is difficult to obtain and often is received unenthusiastically. That’s understandable given that most top managers have been more concerned with hitting established targets than in doing the best overall job possible. But flexibility is key to moving projects beyond the vague assumptions characteristic of unforeseen uncertainty.

Managing Chaos

Even greater flexibility is required in managing projects subject to chaos. The management team must work with conceptual models that may be redefined repeatedly as feedback spurs learning. Contingency plans are insufficient because learning may cause a fundamental change in the project structure, which in turn requires redefining the entire project. To keep the chances of success high enough, teams must be willing to try fundamentally different approaches, either in series or in parallel. Tracking is less focused on the current status of the project relative to its target and more on the current status of learning about basic project assumptions.

The need for flexibility and iteration obliges project managers to cope with constant change. They become entrepreneurs — developing and maintaining close but loose contacts with customers and opinion leaders. In projects characterized by chaos, team managers must have a high degree of autonomy. They must continually verify the original project idea, quickly run experiments to collect feedback on new ideas and consolidate what they learn. Rapid prototyping is one way to support such an experimental approach.6

However, autonomy must be in balance with organizational discipline. Companies must be ruthless in cutting projects when the chance of success becomes too small. Changing the project’s basic concept requires the involvement of the organization’s leaders and may force them to make major decisions about what resources to commit and how to set targets.

IhrPreis.de, a German Internet company launched in 1999, wanted to use the Priceline reverse-auction business model (which cannot be patented in Europe). Despite numerous changes in the selling process to accommodate the preferences of the German consumer, the company could see by mid-2000 that the consumer-auction boom was faltering. Knowing that it could not survive on customer-driven pricing alone, it developed software services for industrial customers and an Internet-based ticket search engine for travel agents. By summer 2001, the search engine, which dynamically optimizes offers from multiple airline-reservation systems, had become the most promising of the company’s offerings.

IhrPreis.de successfully navigated chaotic uncertainty, but there were painful points along the way. One investor commented, “How can they change the business model this much? It’s like we gave them money to develop a sausage factory, and now they tell us they have moved into building fighter planes.” Fortunately, the project managers knew that to survive they would have to do more than control a few identifiable risks or bring a schedule into line. Had the company not recognized the chaotic market and taken the steps to deal with it, its evolution would have floundered.

That much discipline will strain even the most trusting relationships. Tying in partners through contracts or dedicated assets may backfire if a radical change nullifies partners’ participation. For projects in chaotic environments, painful redefinitions are inevitable. Successful partners typically are those that share a long-term vision of the project’s mission.10

The Circored project — a collaboration of U.S. ore provider Cleveland-Cliffs and Lurgi Metallurgy GmbH — provides an object lesson.11 Cleveland-Cliffs wanted to develop a new market, delivering directly to steel plants rather than to dealers, and Lurgi had technology that though unproven appeared to be a breakthrough. The Circored project started in 1995 with Cleveland-Cliffs, Lurgi and a third partner making plans to build a plant in Trinidad. It soon became clear that Lurgi’s new technology would not meet expectations and would have to be fundamentally changed. As market prices for the product collapsed, the third partner pulled out. Cleveland-Cliffs and Lurgi wavered. They agreed to continue only after an elaborate trust- and team-building effort. Lurgi’s efforts to rethink the technology finally bore fruit in March 2001. The plant began to produce volume and now has business potential, although world market prices are still down.

One manager reflected, “Why did we all agree to go through this pain? Only because we all underestimated what was ahead of us. The risks we thought we were facing turned out to be irrelevant; the problems that did hit us were unexpected; and the outcome was different from the original idea.”

Striking a New Balance

Though many projects are characterized by one dominant type of uncertainty, they often will display a blend of types. Managers must be flexible enough to adopt the right approaches at the right time. The challenge in managing uncertainty, to whatever degree, is to find the balance between planning and learning. Planning provides discipline and a concrete set of activities and contingencies that can be codified, communicated and monitored.12 Learning permits adapting to unforeseen or chaotic events. The two require different management styles and project infrastructure. Projects in which variation and foreseen uncertainty dominate allow more planning, whereas projects with high levels of unforeseen uncertainty and chaos require a greater emphasis on learning. (See “How Management Style Varies With Uncertainty Profile.”) Openness to learning is new to many companies. But it’s obvious from the many spectacular project failures that the time has come to rethink some of the traditions in project management. In an era of rapid change, uncertainty is a rule, not an exception. Companies that understand that have the greatest chance to produce spectacular project successes.