Author: Cynthia Low

Will polar bears die because of global warming? Most likely not, as they, like any other living creatures, are capable of adapting. Of course, if global warming turns out to be extreme, no adaptations the polar bears make will help them find suitable habitat. Nevertheless, the ability to adapt is a distinctive feature of all life.

Adaptive management is a structured and systematic process for continually improving decisions, management policies, and practices by learning from the outcomes of decisions previously taken.

In the 1970s this power of adaptation was researched by a group of ecologists that included C.S. Holling and Carl J. Walters. They did this to find the answers to the questions such as how to predict fish stocks when they are dependent on many uncertain factors related to human activities. The scientists came up with the idea of adaptive management or adaptive resource management. Essentially adaptive management is ‘learning bydoing’. It is a structured and systematic process for continually improving decisions, management policies, and practices by learning from the outcomes of decisions previously taken. Since then, adaptive management has become one of the key approaches in environmental engineering. Examples of adaptive management implementation for large-scale natural resource management projects include the Everglades and Grand Canyon National park. The US Department of Defense has been exploring adaptive management concepts for environmental cleanup at Navy facilities. The National Oceanic and Atmospheric Administration has utilized adaptive management for coastal habitat restoration activities.

Many engineers from different fields are using a number of basic principles of adaptive management without actually understanding the work done by Holling and Walters. In 2001, a group of prominent software gurus met in Snowbird resort in Utah and discussed effective software development processes. They came up with what is called “Manifesto for Agile Software Development”. This document offers a number of basic principles, which are similar to the adaptive management concept:

• Regular adaptation to changing circumstances, including changing requirements 
• Constant collaboration in project teams and with clients 
• Iterative development processes

At the same time, authors of the Agile Manifest suggested a new idea: effective adaptive management is possible only in creative business environments with self-organizing teams and trusted and motivated individuals.

Ideas related to agile project management spread rapidly beyond software development. Many teams and organizations are actively applying the agile approach to complex projects. One of the ‘relatives’ of agile project management is flexible product development. Flexible product development offers an ability to make changes in the product even later in the development cycle.

Agile project management and other similar methods are focused mostly on the organizational aspects of adaptation process. Two principles are the most important:

• Iterative decision-making or making choices based on learning from the outcomes of decisions previously taken. 
• Strategic flexibility or avoidance of irreversible decisions

Adaptive management processes originally developed by the ecologists were much broader. In addition to organizational principles, they include quantitative analysis methods, which would help to make better choices based on actual project performance, particularly:

• Multi-model analysis and hypothesis testing 
• Actual performance measurement 
• Quantitative project risk analysis

Here is the essence of adaptive project management: projects are managed based on learning from actual project performance and these learnings are obtained and analyzed using quantitative methods.

Why Adaptive Methods are not Widely Accepted?

There is only one living species in the world that often actively resists adaptation – humans. In particular, project managers often do not realize that adaptive methods will most likely bring better project results than traditional project management processes, where the project plan is defined upfront. 

Many organizations embrace adaptive management methods and techniques. Many software development companies and teams actively use some principles of the agile approach. Nevertheless, traditional project management processes still dominate the field.

Why are project managers so reluctant to embrace adaptive management? The answer lies in human psychology. There are a number of psychological biases that act to prevent people from accepting adaptive principles.

Tendency to be Consistent

Very often politicians blame each other with being inconsistent and this inconsistency is often interpreted as a character flaw, “Three years ago you supported something, now you are against it, are you a flip-flopper?” In reality, inconsistency may be not so bad, if it is based on changing circumstances or new information. For example, if a politician initially did not accept a human role in global warming, but changed his mind after reading new scientific evidence, this is probably a good thing. The world is always changing; new or additional information is revealed and decision-makers must adapt to the new information. In fact, the best politician would be somebody who adapts to changing circumstances rather than sticking to outdated strategies or policies

When people are accused of inconsistency, they tend to become very uncomfortable, something often used by police interrogators and lawyers to uncover information. They try to put people in the position when they make inconsistent statements and then extract necessary information.

The tendency to embrace consistency is very common in project management. When there is new information about the project and it is important to make changes very fast and without any hesitation, the tendency to consistency is often an obstacle to making these crucial decisions. If a device does not work, sometimes it does not make sense to fix it. Building a new device could be a better solution. Project managers have to be willing admit the error and adapt to the new circumstances.

In addition, even if individual project managers are capable of making U-turns, the corporate culture may not support it. Senior management often frowns upon managers who stray from the project plan.

Sunk Cost Effect 

In 1996, NASA selected Lockheed Martin to design, build, and fly the X-33 Advanced Technology Demonstrator test space vehicle. The X-33 was to be launched vertically from a specially designed facility and to land on a runway at the end of the mission. 

The construction of the X-33 was more than 85 percent complete; however, in 2001 the X-33 project was cancelled. What happened? The composite liquid hydrogen fuel tank failed during testing in November 1999. In response, Lockheed Martin proposed to complete the development of the X-33 by replacing its two composite liquid hydrogen tanks with aluminum tanks. However, NASA concluded the benefits of testing the X-33 in flight did not justify the cost. The X-33 would not be able to reach space with aluminum tanks.

NASA’s investment in the X-33 program totaled $912 million. Despite the huge expenditure, NASA cancelled the program. They essentially resisted the sunk cost effect: The tendency to invest more money in a venture in an attempt to recover previous losses. This psychological effect usually prevents project managers from performing adaptive actions. Instead of stopping work on an ineffective project or course of action, they pump more and more into it with the hope of somehow reviving the project.

One of the examples of sunk cost effect is the Concord aircraft project. French and British government continued to fund this aircraft even when it became apparent that it was no longer economically feasible.

Guilt of Indecisiveness

Organizations expect managers to make decisions, even if the managers do not have the reliable information required to make these decisions. Instead of collecting information and analyzing data, which may give the appearance of indecisiveness, project managers make irreversible decisions intuitively, based on their “gut feel”. This style provides an appearance of decisiveness and leadership, regardless of the quality of the decisions. 

In reality, it is very important to analyze when and what additional information is required, how much this additional information will cost, and how waiting for additional information would affect the project’s bottom line. In other words, it is important to use adaptive management.

How Adaptive Management Work? 

Traditional project management processes include the phases of project planning, execution, monitoring, and control and evaluation. If, as a result of an evaluation, it was found that something did not go well, this learning may be used in future projects. 

Adaptive management processes can be active and passive (Figure 1). The main objective of passive adaptive management is to incorporate the process of learning into existing management approaches. The information obtained from each iteration of the project can be used on subsequent iterations. This way, risk and uncertainties associated with each iteration, can be significantly reduced. Passive adaptive management is used as a part of the agile approach.

Figure 1. Traditional project management process versus active and passive adaptive management processes.

The goal of active adaptive management is to learn by experimentation to determine the best management strategy. The process starts with hypothesis generation, which involves the selection of multiple alternatives for the strategy. The next step is the creation of multiple models. In practical terms, these models are usually project schedules with a set of risks and uncertainties for the particular iteration. All alternative models should be evaluated using quantitative analysis. The outcomes of this analysis are duration, cost, chance of meeting deadlines and other parameters of the iteration that may help to select alternatives for execution.
In most cases, only one alternative model will be selected and executed. However, in cases with significant risks and uncertainties, especially in software development projects, it may be more efficient to execute a number of alternative models at the same time.

Here is an example how active adaptive management can be used:

1. Define a project strategy and high-level project plan. Make sure that you provide strategic flexibility: leave room to reverse previous decisions if necessary. 
2. Split this project plan into multiple phases or iterations. 
3. Define a more detailed plan for the next phase or iteration. Do not create detailed plans for future iterations, as they may change due to the outcomes of previous iterations. This plan should include a schedule and list of risks. You may choose to create multiple alternative project scenarios (project schedules and risks list) for the same project phase. 
4. Perform quantitative risk analysis. Different project scenarios may have similar cost and duration, but have a different risk profile. Quantitative project risk analysis will help to determine what will happen with project schedule if certain risks occur. By analyzing this ‘realistic’ project schedule you may choose a scenario to execute. 
5. Execute one or a couple of project scenarios and continuously measure actual results versus original plan. Then perform quantitative risk analysis again. If the project is partially completed, you may have a better idea of which risks actually occurred, and which ones did not. Also, you should be able to calculate the chance that a risk will occur using the performance data. Figure 2 shows how the results of such analysis may look.

Figure 2. Actual project performance measurement and quantitative risk analysis of partially completed projects.

Currently there are a number of advanced project management and risk analysis tools available to perform quantitative analysis. These tools are easy to use: complex math will be hidden inside the software.

Conclusion and Recommendations

Adaptive management is a structured project management framework. It is not a formalized process that must be strictly followed. This framework can be tailored to different types of space system design and acquisition projects. Principles of adaptive management are strongly endorsed and actively used in many industries, such as information technology and environmental protection. 

Rule number one of the adaptive management is simplicity. If adaptive management does not bring tangible benefits and causes extra organizational burdens, ineffective procedures should be abandoned as soon as possible.

Adaptive management includes the basic principles of agile project management, such as iterative processes and creative business environments. In addition, adaptive management involves the active use of quantitative methods to measure project performance and apply learning to improve decisions.

Below are practical recommendations related to the implementation of adaptive management for both hardware and software projects: 

1. Whenever possible, do not define a detailed project plan upfront; instead, use an iterative project management approach. 
2. Always identify multiple project alternatives or hypotheses; model these alternatives and, if it is deemed beneficial, start implementing a few alternatives at the same time. 
3. Use quantitative risk analysis at each phase and iteration of the project. 
4. Integrate original assumptions and new learning when planning next project iterations. 
5. Try to minimize the cost of decision reversals; minimize risk by keeping the option to change project direction available. 
6. Ensure that adaptive management is implemented within a creative business environment characterized by a collaborative structure for stakeholder participation and learning.

Future Reading

Holling, C. S. (ed.) 1978. Adaptive Environmental Assessment and Management. Chichester: Wiley
Kodukula, P., and Papudesu C., 2006. Project Valuation Using Real Options. A Practitioner’s Guide. Fort Lauderdale, FL: J.Ross Publishing
Project Management Institute. 2004. A Guide to the Project Management Body of Knowledge
(PMBOK® Guide), 3rd ed. Newtown Square, PA: Project Management Institute.
Virine L., and Trumper, M. 2007 Project Decisions: The Art and Science. Vienna,VA: Management Concepts.
Walters, C. 1986. Adaptive Management of Renewable Resources. New York: Macmillan.

 

---

Lev Virine has more than 20 years experience as a structural engineer, software developer, and project manager. In the past 10 years he has been involved in a number of major projects performed by Fortune 500 companies and government agencies to establish effective decision analysis and risk management processes as well as to conduct risk analyses of complex projects. Lev’s current research interests include the application of decision analysis and risk management to project management. He writes and speaks to conferences around the world on project decision analysis, including the psychology of judgment and decision-making, modeling of business processes, and risk management. Lev received his doctoral degree in engineering and computer science from Moscow State University. You may reach Lev Virine at [email protected]

 

Part 1: The Last Planners

Lean manufacturing programs like ”Achieving Excellence” are being implemented at an increasing rate now in North America. They promise to improve competitive positioning and increase profitability in the global economy. In their pursuit of excellence, more and more companies are also looking to Lean Project Management (LPM) as the next big thing to implement to better manage non-recurring activities.

Hence, the words lean project management are used all over the place by a lot of people nowadays. LPM is really not well understood, however. In this context, a few blog entries presenting the main rules of LPM, as I see them, might help us all better understand under what conditions project managers can really claim to use and live by lean principles.

Last thing comes first in LPM. So I’ll start with the “Last Planner.” The worst I heard about this is that it was a software package. So I guess some explaining is necessary. The Last Planner is a principle originally promoted by the Lean Construction Institute¹. Its systematic use “Last Planner System” was developed by Glenn Ballard for his PhD thesis². The last planner is defined as the person who will execute the planned work in a project. One of the most important last planners is ultimately the end-user of the product of a project, because he is the one who will materialise project benefits.

Simply put, the last planner approach states that “the one who will execute the planned activity is the one who must plan the planned activity.” As simple as that! Why? Project success is achieved through a series of planned promises made by some people who work very hard to meet the promises they have made! As we all well know from our failure to make our spouses, best friends, children, etc., keep promises we have made for them, making promises for others does not work. And this becomes a certainty when we try to make promises for the almost pure strangers around us, like our employees, co-workers, collaborators and business partners, regarding how they use their time. .

This principle of the last planner first came from the realisation that centralised planning did not work for construction projects, among others. Project managers using centralised planning have to admit that, very often, a time comes when the project is in complete turmoil, with the building falling apart, water pipes bursting, the construction workers and very expensive machinery waiting (while being paid for) for conflict resolution. They finally realise that it would have been less costly to win the collaboration of their stakeholders while they were at the planning stage than later while witnessing destruction work. So the last planner principle is about getting the right people making the right promises as early as possible. It is about negotiating a plan that people adhere to because part of it is their personal plan, their sacred promises for which they truly feel responsible. And more important, both the project and its last planners are bound to benefit from those promises, a sine qua non condition to meet for effectively building and mobilising project teams.

So LPM rule No. 1 is: The one who executes the work is the one who plans the work

¹ www.leanconstruction.org/
² www.leanconstruction.org/pdf/ballard2000-dissertation.pdf

Decisions about project management tend to follow a standard process. Senior management gives middle and/or upper management a project order, and mid-level people respond by quickly selecting a manager — perhaps too quickly!

It’s a process that can contain enormous consequences for any business entity. Yet all too often, upper management unwittingly falls into traps when choosing the manager and finds out much too late the wrong person is leading the charge. By that time, the project has either struggled or failed, and the company’s bottom line has taken a huge hit.

The traps here are those assumptions, the so-called standard business practices that go unquestioned during project manager selection. A better word to describe them is myths.

How Myths Become Acceptable Practices

To find the root cause of these myths, start with this supposition: project management is a paradox. On the one hand, you have senior or upper management, vowing to “think out of the box” and vehemently proclaiming “the same old ways of doing things don’t work anymore.” The paradox becomes evident when these same promises fall by the wayside as the company relies on business-as-usual methods for selecting the manager.

Consider the selection process, assuming that there is one. The focus usually falls on someone who has had previous project success or provided a strong contributing performance in a team role. However, if the company is so inundated with projects that preferred managers are unavailable, middle management may reach deeper into the mix, a choice comparable to a roll of the dice. All-stars at the team level do not always develop into capable managers, a truth constantly rediscovered by sports franchises and their counterparts in the business world.

So consider those previously unquestioned myths that have become the foundation of project management. It’s a foundation less than solid.

Myth #1: Technical Leads Are the Best Choice for Project Leadership

The origin of this precept is easily understood. Technical experts generally get the inside track for leadership of the next project because of their outstanding performance in the previous assignment, usually in a non-managerial role. After all, doesn’t it make sense to choose an analyst or technical engineer to handle a challenging and complex technical assignment? Well, yes and no. True, the manager should have the knowledge and expertise to make informed and creditable decisions, but there is still the issue of leadership, which takes more than numbers crunching or the weighing of variables.

An outstanding technician does not automatically become a top-flight project leader. That next big step depends on several objective factors, e.g. previous performance and people skills, and subjective ones such as an assessment of the candidate’s managerial potential. Such decisions take time. Unfortunately, time is rarely available in today’s overburdened corporate world. So, the decision becomes based solely on the tangible (technical) as opposed to the intangible (leadership qualities).

This is not to suggest that technical people cannot or should not be managers, but a stronger emphasis on leadership skills needs to be part of the selection evaluation if the project is to have its best chance for success.

Myth #2: The Tool Solves Everything

The tool in this case is a software program, such as Microsoft Project. There is nothing wrong with the tool when its usage conforms to its purpose, which is scheduling. This type of software is outstanding for setting and scheduling various components of a project.

Now the key: the tool is excellent as long as its use is confined to scheduling. It was never designed to cover other extremely important facets of project management, such as additional planning and modifications. When a project is modified, the changes may not conform to the tool’s structure. That doesn’t stop many managers and teams from trying to fit the wrong glass slipper on Cinderella.

“I’ve seen teams spend countless hours trying to get everything perfect in the tool and when there are changes, they spend even more time trying to make it fit,” said one frustrated consultant. “That’s not managing a project. That’s a disservice.”

Teams overly rely on the tool to the point of costly project delays. The fault is not with the tool; it’s with leadership.

Myth #3: A Training Workshop Will Produce a Successful Project Manager

Most companies understand the necessity of project manager training, but fail to realize that a three-day workshop is not the answer. Workshops are valuable, but limited. They provide the basics along with other helpful elements, but the rest is up to the individual and upper management. Unfortunately, the training rarely continues beyond this point.

Many acknowledge that classroom training isn’t all a manager needs yet companies, due to either budget or time limitations, do not provide an environment for ongoing training or learning, including real-world experience. Once again there are the usual suspects: limited funds for training, whether classroom or on-the-job; pressure from shareholders in publicly traded companies for short-term results; simultaneous projects limiting the number of quality managers available; and a management-by-objective business model that creates an environment less likely to produce experienced project managers.

Case Study: A Tiger by the Tail

Any one or more of the above myths can produce disastrous results. This was exemplified recently by the experience of an IT organization within a major health care corporation inundated with projects. Its best managers were unavailable, and the only option was to bring in consultants and less experienced staff members. To make matters worse, the IT group relied on the project tool to compensate for the absence of a skilled manager. All the elements for failure were there and the results were catastrophic. Shareholders could not have been pleased when the loss to the company was an astounding $300 million. The corporation’s stock took a huge loss, and the project was terminated as were a number of managers.

Contrast this nightmare with the experience of Scott Brown, director of an enterprise IT renewal program for a leading automotive remarketing company. His program, which is designed to replace all core operating applications, including standardized tools and processes, continuously evaluates and implements common tools for business and technology users. Despite the program’s successful start, Brown says considerations outside of the tool’s scope cannot be excluded if a project is to be successful.

“In a nutshell, a tool does not equal process, and without training and process re-engineering, all implementations fail,” Brown says.

Brown refers to his method for avoiding the pitfalls of the myths as “E3: establish process, educate and enforce.

“Very little thought has been given to understanding or documenting business process prior to initiating the next great idea,” Brown says, adding a caveat to managers who de-emphasize process over a company culture likely to accept the myths as gospel.

“Culture eats process for breakfast,” he says. “It’s the single biggest challenge to avoiding these pitfalls.”

Strategies to Overcome the Myths

Clearly, it’s important for management to re-evaluate all of those assumptions that tend to jeopardize rather than facilitate. Start with an emphasis on the process of developing plans and people long before anyone is sent to a workshop. Planning should include other important considerations including a mentoring program in which experienced project managers train future managers, who have completed workshops.

These strategies will be successful only if companies are willing to put the time and resources into development. The best managers will display knowledge, aptitude, reasoning and leadership skills, but these are not always innate. They require practice to mature.

They also require time.

---

Don Wessels is project management senior consultant for Management Concepts, Vienna, Virginia, a professional services company with training, consulting and publishing expertise. Management Concepts partners with individuals and organizations to improve performance through consulting, training programs and certificate courses. For more information, please call (703) 790-9595 or visit www.managementconcepts.com.