CHAPTER 20

Adaptive Project Management

Adaptive project management is a powerful method that incorporates constant learning and improvement. Quantitative analysis helps compare original assumptions with actual project data. Instead of making an irreversible major decision at the start of a project, it is important that project managers focus on making small sequential choices. Adaptive project management can be implemented only in a creative business environment, where potential issues and problems can be identified and corrected at an early stage.

Adaptive Management as Part of Project Decision Analysis

After the framing, modeling, and analysis phases of our work, we finally come to one of the important milestones in the project—the project launch. Why is that so monumental? It’s primarily because many projects never make it to this stage. If the decision process is working correctly, the weakness in a project will be seen and the project will not be launched.

As we start to execute the project plan, we now have the opportunity to see how the project progresses in actuality—no longer just in theory—and can make necessary adjustments to our original plan. This process is called adaptive management. Adaptive management is a process of continually improving decisions by learning from the outcomes of decisions previously taken.

Because of the many risks and uncertainties in a complex project, it is impossible to envision everything in the planning stage. We now have new inputs to our decision-making process: actual project performance.

The adaptive management concept was introduced by ecologists in the 1970s (Holling 2005; Walters 2002) and has become an effective tool in both ecological and environmental management. Environmental and project management have many things in common. For one thing, both deal with multiple uncertainties. We believe that project managers can effectively apply adaptive management practices to their projects.

A key area of overlap between the two processes is the principle of continuity, which we discussed in chapter 3 as one of the key concepts for project decision analysis (along with consistency and comprehensiveness). Continuity is also a key principle of adaptive management. Look back at figure 3-3 in chapter 3. The arrows from the box “Implementation, Monitoring, Review” point to other phases of the decision analysis process. These arrows represent the iterative process of adaptive management. By analyzing the actual project performance, you can update the following:

• Original assumptions made during decision-framing. For example, you may add or retire certain risks. Sometimes you will have to update project objectives, assumptions about the business environment, and available resources.

• Valuation models. You can update the schedule or reassess the probability of certain risks. Active adaptive management may involve defining multiple models for different alternatives and testing them during the course of the project (Linkov et al. 2006b).

• Quantitative analysis. You can run a new analysis using Event chain methodology with an updated schedule model and risk breakdown structure.

Here is an example: when an oil company decides to start drawing oil from one of its reserves, it estimates the reserves in place using all available information: seismic surveys, exploratory data, and analogous information from nearby wells. If and when the well starts producing, the oil company can then use actual production data to refine its original estimates about the size of the reserve (Rose 2001). Although in some situations it is impossible to estimate precisely the volume of oil in the reserve until almost the entire field is produced, the company can reduce uncertainties and can update economic and production models based on new information obtained during the course of the project.

Principles of Adaptive Management

Adaptive project management consists of five basic principles that help you monitor the course of your project and refine your original decisions.

PRINCIPLE 1: USE ACTUAL PROJECT DATA IN COMBINATION WITH ORIGINAL ASSUMPTIONS

During the execution of a project, a manager might behave in either of two extreme ways:

1. Disregards the original assumptions made during the planning stage of the project.

2. Ignores the implications of the new data and adheres resolutely to the original forecast. This occurs because of differing motivational and cognitive biases, such as optimism or overconfidence, and because warning signs about the failing project are often ignored.

Neither extreme is desirable. Assuming that the original estimates were done using relevant historical data or expert opinion, both the original plan and the new data should come into play together. Let’s say we have a project where we originally estimated that it would earn net revenue of $1 million by year-end, but by April net revenue is already $0.5 million. Should we readdress our estimate, and if so, how? If we simply multiply the current revenue by three to account for the remaining number of months, this may not account for expected slow summer sales. The solution is to perform an analysis and compare it with trends for current and previous years.

A number of techniques can help us forecast the future, based on actual and historical data. One such technique is regression analysis. Generally, regression analysis is a statistical technique for investigating and modeling the relationship between variables. If we know how a variable such as cost changes over time, we can come up with a forecast for future cash flows. Then, if we add actual data to the analysis, the quality of regression analysis improves.

When we deal with probabilities, the situation is much more complex. It is easy to ignore base-rate frequencies when trying to combine actual and historical data, especially if they are related to probabilities. Let’s say we estimated that the chance of a certain risk occurring was 20%, but with the project only half completed the risk has already occurred twice. What is the chance that the risk will occur during the reminder of the project? We previously discussed this problem in the chapter on Event chain methodology, particularly in the section on performance tracking (see chapter 17). One of the solutions to this problem is to use a Bayes theorem to analyze the value of imperfect information. Using the Bayesian formula, you can combine original estimates of probabilities (prior probability or marginal probability) and data obtained as a result of actual project measurement. The actual formula is used in various analysis software (see appendix A).

PRINCIPLE 2: MINIMIZE THE COST OF DECISION REVERSALS (“TRY NOT TO KILL THE COW”)

There is an old legend in which an elderly woman, having spent her last penny, decided to sell off her only cow to be slaughtered for meat. She called the local village butcher, who told her there were three pricing levels:

A. The total weight of the live cow

B. The total weight of the dead cow after initial processing

C. The total weight of the processed carcass, minus by-products that could not be sold

The price per pound for B is greater than that for A, and for C is greater than that for B. The problem is, the woman had to make her choice before the cow was slaughtered. If she chose to kill the cow, she would get a higher price per unit of weight, but would this be more or less than what she would receive for the live cow? If she decided to kill the cow first, she would be faced with the same type of decision when choosing between options B and C. However, she would be constrained by the fact that once she decided to forgo option A, her options would then be limited to B and C. In other words, the decision to kill the cow is irrevocable. We are not experts in the cow-killing business, but we feel fairly confident in saying that trying to resurrect a cow would not be a trivial process.

The old lady had the difficult task of estimating whether the cow would be worth more dead or alive. Lacking any real data, she had to gamble. “Kill the cow,” she said. And she won: the dead cow was worth more than the live one. She also went on to guess correctly when she agreed to the further processing of the cow. As a result, she got the maximum possible price for her cow. The legend doesn’t tell us if she used her newfound money to buy milk.

We do not recommend that you gamble with your projects—it is a bad idea, even though a lot of project managers routinely do it. But what if your original decision happened to be wrong? How much would it cost to go back and salvage the project? (That is, how much would it cost to bring your dead cow back to life?)

When you are performing a decision analysis, we recommend that you consider the cost of decision reversal, meaning the cost associated with all the expenses related to a wrong decision. In theory, the cost of a decision reversion can be between zero and infinity for an irrevocable decision like killing a cow (figure 20-1).

Figure 20-1. Cost of Decision Reversal

The idea behind this concept is that when you make a decision, you should also try to formulate an alternative that you can implement at minimum cost. For example, if you are an opera producer, you should always have the phone number of an easy replacement for your diva if she ends up in rehab after her fifteenth divorce. If you remember, in The Phantom of the Opera, the producers had a similar issue when they had to bring in a new star, Christine (the object of the Phantom’s affection), after the original star was poisoned by the phantom. One never knows what goes on backstage.

Unfortunately, you cannot always make a U-turn in the middle of a project because it brings up a whole new set of risks: heavy traffic and slick roads.

PRINCIPLE 3: MAKE SMALL, SEQUENTIAL DECISIONS

The movie Wag the Dog is a good example of a project with multiple uncertainties and sequential decisions. Just two weeks before the presidential election, the president finds himself embroiled in a scandal that is threatening to escalate and ruin his chances at reelection. To divert attention from the scandal, the president’s handlers and advisors decide to invent another crisis, a war with Albania (decision #1). With the help of a famed Hollywood producer, the president’s advisor has several fake war scenes staged and distributed to the media. When they find themselves being undermined by other elements in the government, the advisors decide to add another twist to the tale by inventing a hero left behind enemy lines (decision #2), whose televised rescue will captivate the American audience. Unfortunately (for them), in an unexpected turn of events, “the hero” turns out to be a violent psychotic, and in the end he is shot. Still trying to make the best of a bad situation, the president’s advisors decide to continue the charade by staging a state funeral for “the hero” (decision #3).

While this example is somewhat extreme (but very amusing), it shows how decisions can be made as a response to a constantly changing business situation. In other words, the advisors were using iterative decision-making.

In chapter 12 we discussed the use of the agile methodology in project management. We mentioned the benefits of an iterative approach, in which requirements are not completely defined up front and a working (and constantly redefined) project is delivered to the client on a regular basis.

Now we will prove to you mathematically that managing risks and uncertainties using an iterative project management process will save you both time and money. Let’s assume that we have two scenarios affected by the same risk (figure 20-2):

• Scenario 1. There are three 20-day tasks, and each task has a risk “change of requirements” with a probability of 20%. If the risk occurs, the task will have to be restarted. The risks for each task are not correlated, so three small, separate decisions will be reviewed and, if necessary, corrected during the course of the project.

Figure 20-2. Quantitative Analysis of Two Project Scenarios

• Scenario 2. There is one 60-day task with the same risk, “change of requirements,” but with a probability of 60%. If the risk occurs, the task will have to be restarted. This will require only one strategic decision, which will be strictly followed during the course of the project.

Which scenario will be completed first? An answer to these types of questions requires quantitative analysis. In this case, we will use Event chain methodology for the analysis. The original project schedule is shown on the event chain diagram as white bars. The project schedule with risks has gray bars. Table 20-1 shows the results of the analysis.

As you can see, the project scenario with the three 20-day tasks will be completed, on average, 17% faster than the project scenario with one large task. Moreover, if the risk “change of requirements” is most likely to occur at the end of the task, the difference between the two scenarios will be even more significant. In addition, the second scenario is also much riskier, because the range between low and high estimates of duration is much larger than that for the first scenario.

What this means is that projects with risks can be completed earlier if they are done iteratively. The iterative approach ensures faster feedback, which can be a result of testing, prototyping, demonstration to the client, and so on. Through this process, we can learn from actual experience and can then apply this learning to the next stage or iteration of the project.

PRINCIPLE 4: SUPPORT CREATIVE BUSINESS ENVIRONMENTS

If during a project you receive new information, you should be able to use it to steer the project in the right direction. At the same time, you do not want to create chaos by making frequent U-turns as a response to small requests or small changes in the business environment.

Table 20-1. Results of Quantitative Analysis: Duration of Project in Days

Unfortunately, many organizations are not able to strike a balance between their ability to improve projects by using actual project information and their change-control process. Often, the change-control process is so vigorous that it suppresses any creative decision-making. For such organizations, the main problem is that necessary corrective actions will not be taken because of organizational pressure. If this is an issue, you will not be able to resolve it without major improvements occurring in the organization’s culture.

PRINCIPLE 5: IDENTIFY AND FIX PROBLEMS EARLY (AVOIDING BEHAVIORAL TRAPS)

Suppose that during the project planning stage we made certain decisions that have been proven to be wrong during the execution of the project. However, we are reluctant to make necessary changes.

The longer we continue with an incorrect course of action, the more difficult it will be to reverse the course of action. This phenomenon has several different explanations, including technical and organizational. One of the most common explanations is related to behavioral traps. For example, the more money we invest in a failing project, the more money may be lost. This is the sunk-cost effect, which we discussed in chapter 2. The longer we continue to develop a software application with an unfriendly user interface, the more we get accustomed to it, and the more difficult it is to create a new interface. Therefore, it is very important to identify problems as soon as possible, perform an analysis, and try to fix them.

The PMBOK Guide Approach to Project Executing, Monitoring, and Controlling

The PMBOK Guide does not explicitly use the term “adaptive management.” However, you will find important information related to adaptive management in two of the Guide’s process groups: project executing and project monitoring and controlling.

The project monitoring and controlling process group includes the following project management processes:

1. Monitor and control project work. This includes collecting information, measuring project performance, and updating forecasts.

2. Integrated change control. This occurs when any changes made to the project scope through corrective and preventive actions need to be collected, analyzed, documented, and either approved or rejected. For example, as a result of testing, one component of the device does not meet specifications. While this issue needs to be addressed, this change may occur in the middle of the project and affect many other activities. This kind of impact must be carefully analyzed.

3. Quality control. This includes measurements, corrective and preventive action, recommended defect repairs, validation of deliverables, and other outputs. Good quality can be achieved not only by original design but also by constant testing and monitoring during the course of a project. It is very important to find a problem or a defect as early as possible; otherwise, the repair can be much more costly.

4. Risk monitoring and control. This includes tracking risks, monitoring residual risks (for which risk response is implemented), identifying new risks as early as possible, recommending preventive actions, and executing risk-response plans during the course of a project. The PMBOK Guide (chapter 11) recommends regularly reassessing risks based on actual project data. Risk audits can help to control the efficiency of risk responses. Reserve analysis helps to determine the amount of contingency reserves remaining at any time in the project.

Other processes included as part of the project monitoring and controlling process group include scope verification, scope control, schedule control, project team management (tracking the performance of team members and coordinating changes to enhance performance), performance reporting, stakeholders management, and contract administration.

One technique mentioned in the PMBOK Guide that can be used in adaptive management is a technical performance measurement, in which you constantly compare technical accomplishments during the course of a project with the project plan.

Adaptive Management and Changing Requirements

Let’s assume that you are a famed British dressmaker and you are tasked with designing and making a wedding dress for a royal wedding. You know that the probability that the client’s requirements for the dress will change over time is 100%. The question is what requirements and what changes will be required.

Changing requirements is one of the main uncertainties that project managers often face. There are two ways to manage this uncertainty:

1. Accept the changing requirements, and when they do change, use change management processes to address them.

2. Recognize that requirements may change, perform an analysis, and select the best course of actions, given the probability that requirements will change. If these acts are done properly, the value of the project can be significantly increased (Bordley et al. 2019). There are different ways to plan for changes in project requirement. One is risk-response planning, which we discussed in chapter 10. Change of requirements is a probabilistic event, which would trigger activity or group of activities as a response to the event.

So, what is the most effective way to manage requirements? It is difficult to plan projects in a manner that take into account all possible changes in requirements. Therefore, the solution is a hybrid approach: to plan a response to the most unstable requirements and then to implement change management processes when unplanned changes occur. If you are a dressmaker for royalty, you can probably anticipate some alterations, such as making longer sleeves that can be adjusted later. Yet some requests by your client will be difficult to anticipate and you will need to manage these changes according to adaptive process.