Project recovery management

Abstract

Project recovery management is not mentioned as a topic requiring special attention and knowledge in the global project management standards, such as the PMBOK^® Guide. The assumption, it seems, is that to recover a failing project, one only needs to apply the standard properly and the project will be brought back on track. On the other hand, experienced practitioners like Hornjak (2001) and Kliem (2011) argue that project recovery requires a special and methodical approach which deviates in several respects from the global standards on project management.

This paper presents a concise review of two perspectives on the topic of project recovery management. These are the positivist perspective, with which the PMBOK^® Guide is strongly aligned, and the constructivist perspective, which sheds a very different light on the causes and remedies of failing projects.

The two perspectives are seen as complementary to each other in the sense that they can both be used as valuable sources for the development of a theory on project recovery management. Suggestions for further development of such a theory are provided at the end of this paper.

Keywords: project disasters; project recovery; emergency management; crisis prevention

Introduction

On October 20^th, 2011, the Project Management Institute (PMI) presented testimony to a Senate panel on the United States’ Federal Emergency Management Agency (FEMA) accountability testifying that project management expertise has practical applications for FEMA in providing disaster relief efforts. “Our research shows that project management provides the kind of leadership and clarity of thought needed to help in the reconstruction effort,” stated the PMI vice president for organization markets (PMI, 2011). (source: http://www.pmi.org/About-Us/Press-Releases/Project-Management-Institute-Testifies-on-Disaster-Relief-Project-Management.aspx). If project management standards provide effective aids in recovering from a natural disaster, do they also provide appropriate and sufficient guidelines to recover from a project disaster?

Project recovery management is not mentioned as a topic requiring special attention and knowledge in global standards on project management. Keywords like “crisis” and “disaster” are not mentioned in these standards. The assumption, it seems, is that to recover a failing project one just needs to apply the standard properly and the project will be brought back on track. How valid is this assumption?

According to Morris (2013), the validity of current “public knowledge” about project management “is affected by the context in which management is operating and the values and behaviors of those involved in the project’s management” (p. 20). To increase the validity of our common knowledge we need more interpretative epistemologies in addition to the positivist epistemology which seems to dominate public knowledge.

Two perspectives –positivist and constructivist- on project recovery management are reviewed in the following paragraphs.

The Positivist Approach to Project Failure and Recovery

What Is a Project Disaster?

According to Morris and Hough (1987) a project disaster exists when the answer to each of the following questions is negative:

1. “Project functionality: does the project perform financially, technically, or otherwise in the way expected by the project sponsors?...
2. Project management: was the project implemented to budget, on schedule, to technical specification?...
3. Contractors’ commercial performance: did those who provided a service for the project benefit commercially?...
4. Cancellation: in the event that a project needed to be cancelled, was the cancellation made on a reasonable basis and terminated efficiently? “ (p. 193).

The multicriteria approach to distinguish project success from failure or disaster has been followed by many others in subsequent years. Turner and Müller (2006) provide a review of several publications with this perspective. Apparently, there is a strong common belief that the phenomenon of project failure should be objectified as much as possible.

Causes of Failure and Crisis in Projects

Much research has been done to identify the major causes of project failure (Turner and Müller, 2006). In most cases this has resulted in lists, usually ranking the causes in order of frequency or importance.

Often mentioned causes are:

• Poor project management.
• Weak business case and inadequate attention to business needs and goals.
• Lack of top management support.
• Lack of attention to the human and organizational aspects.
• Failure to involve users appropriately.
• Inappropriate contracts.
• Inadequate design solutions.
• Incompetence and lack of experience.

How to Recover?

Project recovery management, is currently mostly a practitioner’s field. While much research has been done on the identification of causes, few efforts have been undertaken to validate different theories of recovery. Hence, it is the practitioner we have to address ourselves to in order to find out more about current theories of recovery.

Scanning the internet we can find a multitude of proposed approaches applied by project management consultants in their daily practice. Many of these are single-phase, multistep procedures. For instance:

• Brad Egeland (2012):

  1. Push for compliance: try to maintain the original plan. Sometimes a firm reminder of the commitment and an offer of support may be enough to stimulate better performance.
  2. Recover in later tasks: sometimes a better option than attempting to fix the immediate problem. Be sure that future plans are reflected in the project schedule.
  3. Add resources: but weigh the costs against the returns.
  4. Accept substitutions: when something is unavailable or expected to be delivered late, consider substituting a comparable item.
  5. Use alternative work methods: but weigh the costs against the returns.
  6. Accept partial deliveries: delivery of only some of the items you need may allow you to keep the project moving forward.
  7. Renegotiate cost and schedule targets: but it won’t solve real underlying performance issues.
  8. Reduce scope: this should ordinarily be your last course of action.

• Manjeet Singh (2012):

  1. Set stakeholder expectations from the outset. Make clear to all parties concerned that you will need time to familiarize yourself with the project.
  2. Get your hands on all the relevant documentation (scope, charter, specifications, etc.) and read it. In parallel, hold a series of individual meetings/conference calls with the main stakeholders and team members to introduce yourself, and pick their brains. Among others, specifically ask: Why is the project out of control? What should be done to get it back on track? How can the person help you in rescuing the project?
  3. Hold a formal meeting with the core project team. Focus on getting to know the team. Go through the project by comparing: Initial scope vs. current + reasons for change, initial schedule vs current schedule + reasons for delay, initial budget vs. money spent + reasons for budget overrun, Current state of deliverables + initial estimation for completing them. Such a meeting will help you identify the root causes for the project’s problems.
  4. Write a damage assessment report and discuss this with the main stakeholders.
  5. Now work with the team to come up with a new planning for the project (follows index of the new planning report). Note that creating such a new planning document is an iterative process. You will need to allocate time for this.
  6. Get your new planning validated by all the main stakeholders, and start managing your project to completion.

Several practitioners have gone beyond the simple checklist method and developed a multiphase, multidimensional approach that could be called a practitioner’s theory. Examples are found in Aiyer et.al. (2005), Hornjak (2001) and Kliem (2011). One of these we will describe in detail as we believe that it sufficiently represents the others and offers a clear view on both the methods and the underlying reasoning of these practitioner’s theories.

Example of a Practitioner’s Theory: Hornjak (2001)

Hornjak’s approach recognizes three phases; each of these phases has its own character and requires its own methods:

1. Emergency management: recognize the symptoms of an emergency, assess the situation, identify and analyze the consequences of project failures, prioritize the separate failures, take corrective action to stop the “bleeding” caused by the most crucial and repairable failures.
2. Crisis management: identify the direct causes of the failures, collect information required to develop effective solutions, evaluate alternatives and their consequences, test and implement the chosen solutions.
3. Crisis prevention: identify and analyze the root causes of the failures; redesign the system in such a way that reduces the likelihood of repeated system failure.

The overall aim of this approach is to increase top-down control of management over the project and to improve the feasibility of the formal plans and schedules of the parties involved.

Hornjak acknowledges some important aspects of recovery management. These are: (a) different failures have different consequences and different recovery times; therefore it does not make sense to try and solve all issues at the same time; (b) first try to minimize the consequences, then deal with the causes; (c) failures have direct causes (often the most visible) and root causes; taking away the first has a more immediate but a lesser long term effect; intensive care is aimed at direct causes, corrective surgery at root causes; (d) to deal with root causes one has to apply an integral systems view; (e) proper recovery management is a project by itself; the way in which the recovery project is managed must be an example to the managers involved in the failing project.

On the other hand, Hornjak’s perspective basically is a closed, rational systems perspective. A project, in his view, is like a mechanical system which leads a more or less autonomous life. This life is governed by rational, coherent goals. If a project fails–it enters into a state of crisis—that is because the likelihood of reaching these goals has been reduced to near zero level. The project surgeon—Hornjak himself, for instance—is there to make an objective, rational diagnosis and operate on the patient (system) in such a manner and to such a degree that, after a while, the patient can stand up and proceed with life.

This perspective disregards that:

• A project is a social construction. “It is not found, but made” as Morris (2013) puts it. This implies that knowing about the particular—often very personal—logic applied by those who somehow manage the project is crucial for understanding why it went wrong. It is noteworthy that none of the positivist models reviewed here mention anything about the who. Who should take all the actions listed in these models?
• A project is not really autonomous. Those who do not formally manage it can have as much influence on the development of the project as those who do formally manage it.
• A project is a living system. Not at all like an airplane—Hornjak frequently compares airplane failure with project failure—or an IT system. The major difference—in this context—is that living systems can, so to speak, “repair” themselves—airplanes cannot. Social systems have the ability to “revive.”

The consequence of this difference is that while Hornjak tries to isolate the patient in his operating room making the patient more or less passive while the operation takes place, it is at least equally sensible to do the opposite, namely to focus on the capabilities of self-healing within the project.

A Constructivist Perspective on Project Disasters and Recovery Management

What is a Project Disaster?

With regard to natural disasters, Altay and Green (2006) state “It is critical to understand that a disaster becomes a disaster when someone who is authorized to say it is a disaster does so.” Project disasters are defined by Peter Hall (1980) as: “any planning process that is perceived by many people to have gone wrong” (p. 2). In Hall’s view, it is the clash between different logics of the parties involved which makes a problematic situation a crisis. Both views emphasize the subjective side of whether or not to label a situation as a disaster.

Although objective criteria can and should be taken into consideration when judging a problematic project, the decisive criterion from a constructivist perspective is how the parties involved judge it. In some cases, these parties will agree that the project “has gone wrong.” In other situations, they will disagree, with one side believing that the project has become a disaster while others believe that optimism about the final outcome is still warranted. When one of these beliefs is dominated by the other there is a lack of countervailing logic which, according to Weick and Sutcliffe (2001) is characteristic of many organizational and strategic crises.

Both Hall and Weick and Sutcliffe emphasize is that it is the process leading to disaster which we need to understand, more than the static causes which are inferred after the crisis has manifested itself.

Causes of a Project Disaster: The Process of Project Derailment

The process that eventually leads to failure or disaster can be called project derailment. According to Weick and Sutcliffe (2001), the derailment process is characterized by “a deceptively simple sequence in organizational life: a person or unit has an intention, takes action, and misunderstands the world; actual events fail to coincide with the intended sequence; and there is an unexpected outcome. People dislike unexpected outcomes and surprises. Because of that, they sometimes make situations worse” (p.2).

Three teams were involved in the 1996 climbing disaster: (a) two commercial teams—Adventure Consultants, led by Rob Hall, and Mountain Madness, led by Scott Fischer;- and (b) a noncommercial Taiwanese team. The following is taken from a study performed by Alvarez, Pustina, and Hällgren (2011) on this particular project.

When disasters like this happen, most often the cause is attributed to external events, such as a snow storm, and not to the preceding sequence of events, which may represent a process of derailment. We tend to attribute causes to visible events and not to slow and hidden processes that involve the actions of several or sometimes many people. Also, these people—because they are involved—will often resent the idea that they may have somehow been responsible for the course of events. In the case of the 1996 Mount Everest disaster, post-mortem investigations have shown that the high toll of eight casualties could indeed be attributed to a series of human mistakes and misjudgments.

In general, this process can be described as follows:

• Derailment rarely sets in because only one major threat manifests itself. Derailment is caused by a combination of causes. Usually there are at least three of these, which somehow come together. This can be labeled as snowballing of the causes.
• The first symptoms of something going wrong are rather weak. They are present in small incidents which are usually perceived as exceptional (incidental) and independent of each other. Derailment generally does not go off with a bang—it just sneaks up on you.
• Once the snowballing sets in more and more people (and parties) get involved. They all become affected by the process and each of them tries to minimize the consequences. That is natural and unavoidable. However, as they do so, they are inadvertently increasing the consequences for the others. The others will not let that happen, of course. They react with counter measures. And so on. This stage of the process will be called mutual reinforcement.
• If this process of snowballing and mutual reinforcement is not stopped in time, a vicious downward cycle will emerge which will eventually lead to a crisis. This is often a phase in the process when outside parties, such as the press, the public, higher management or political powers, get dragged in. Usually this will decrease the capabilities of the original parties to solve their own problems. Their independent authority has diminished to a dreadful level. This stage of the process will be called external infection. Now we are dealing with a problem that is too big for anyone to solve as an individual.

In short, derailment is a gradual process caused by snowballing of different, often sequential, causes (such as the ones mentioned previously). This snowballing is aggravated by mutual reinforcement between the parties involved and by external infection, both of which are additional or meta causes.

The extensive documentation regarding Mount Everest 1996 provides a clear and detailed example of gradual derailment:

So what happened here? What was the causal chain that led to eight casualties?

• Snowballing of different causes. At least six causes subsequently came together; snowballed into one big force: (1) The time window for a summit attempt by three teams simultaneously was pretty short; any delays might cause queues at the bottle necks and, hence, further delays. (2) Ropes were not there where they should have been. This caused delays. (3) Later on bad weather caused further delays. (4) There is a golden safety rule, called the 1.00-2.00 rule, which advises to give up a summit attempt and return to camp during the hour between 1.00 and 2.00 p.m. To the extent that all climbers were aware of this rule many of them were caught in a dilemma once they had reached the Hillary Step. As one participant said: “The desire to get to the summit is enormous. I’d spent six years training and a huge amount of money. Six weeks of slog to get where I was and to miss out by 200 vertical meters were more than I could bear”(Alvarez et.al., 2011, p. 980). (5) If the bad weather had emerged earlier, then perhaps the decision to abort would have been easier to make. However, at the hour of the golden rule, those who had just reached the top reported that the weather was fine. This inspired others to move on to the top. (6) Once the bad weather broke out, climbers and leaders got dispersed and communication between them became much more difficult. As a consequence, decision making could not be coordinated as well as required under difficult circumstances. Different people started to make their own decisions; some of which were contradictory to each other.
• Mutual reinforcement between stakeholders. (7) The two commercial teams and their leaders, Fischer and Scott, worked together but also competed with each other. “Fischer was trying very hard to eat Hall’s lunch and Hall knew it... The idea of turning Adventure Consultants’ clients around down the mountain while his competitor’s clients were still climbing towards the summit may have been displeasing enough to muddle Hall’s ability to think carefully before making a decision (to continue towards the summit after the hour of the golden rule)” (Alvarez et.al., 2011, p. 980). (8) “Fischer’s ego craved recognition in the elite level climbing circles. Having summited Mt. Everest in 1994 without supplemental oxygen, the only way to enhance his reputation was to have a successful expedition in 1996 with as many clients reaching the summit as possible” (Alvarez et.al., 2011, p. 980).
• External infection. (9) “The presence of three journalists in the teams, who were writing articles and reports about the expedition for media that targeted large audiences” (Alvarez et.al., 2011, p. 980).

What can we learn from this example?

• Nine (or perhaps more) causes of a very different nature collided to lead eventually to disaster. At first sight one might say that an external event—the snow storm—was the major or only cause. However, sudden snow storms are something to be expected at Mt. Everest. One should be prepared for that. Were the teams not sufficiently prepared? Given the amount of experience and expertise of Fischer and Scott, this is not very likely. There is just not one cause to which we can attribute the dramatic turnaround of events.
• Some of these causes can easily be recognized as “bad things” which should be avoided. For example: causes (2)” the ropes were not in place” and (3) “bad weather.” However, other causes such as (5) “Excellent weather at the summit at 1.00 p.m.”, (7) “competitors co-operating with each other”, (8) “Strong ambition to succeed” and (9) “publicity” are often seen as “good things.” Positive or desirable circumstance or events are equally likely to be part of the causal chain as negative or undesirable circumstances or events.
• The scenario—or causal chain—is hardly visible at the time it occurs. The sequential events seem unrelated. For instance, what is the logical relation between (2) “The ropes were not in place” and (9) “There were three journalists present”? There is none! So it is unlikely that anyone had focus on such a scenario. In addition, those who could possibly have seen the scenario unfolding were blurred by their own involvement in and commitment to the joint ambition. When projects are being planned and prepared, rational logic and common sense are leading the way. When projects actually unfold emotions, intuition, and coincidence are ready to take the lead.
• If we view this whole chain of events only as the breakdown of a rational, closed system, then we will miss out on some crucial characteristics. To begin with, in a closed-system perspective we would probably not include external infection in our analysis. Of course we could and should include the presence of journalists but we would see them as part of the closed system—a part which has one or more functions within the system. But we would miss out on the nonfunctional or even irrational effect they could have on the mindset of the leaders and the other team members. Secondly, given the very short time span in which things turned around, it would not make sense to send a “project surgeon to Mt. Everest” to start a project recovery operation. But, thirdly, even if there was ample time left for recovery, it would have been very unlikely that the team members and team leaders would have allowed him to get involved in the recovery. He would be seen as a stranger and—unless he happened to be a mountain climbing hero—as an amateur. So it is not so much the breakdown of rationality, but the emergence of a situational rationality which characterizes the derailment process.

These aspects call for a constructivist perspective—the open, living systems perspective—which focuses on the “self-learning” and “self-healing” capabilities of the parties who make up the project coalition.

Recovery Management from a Constructivist Perspective

How can we call on the “self-learning” capabilities of the parties involved in the project coalition?

Learning—specifically experiential learning or learning from experience (Turner, Keegan, & Crawford, 2002)—in projects is dependent on various conditions within and surrounding the project. Results from previous research suggest that the following conditions have a direct influence on experiential learning in projects:

• Complexity of the project (Edmondson and Nembhard, 2009)
• Stability of team membership (Akgün and Lynn, 2002)
• Organizational structures that promote or hinder free flow of knowledge (Wageman and Baker, 1997)
• Organizational culture that promotes learning (Tjepkema, 2002)
• Psychological safety (Edmondson, 1999)
• Joint sense of purpose (London and Sessa, 2007)
• Role stress (Storm et.al., 2010)
• Leadership behavior that promotes learning (Burke, Stagl. Klein, Salas, & Halpin, 2006)

Savelsbergh and Storm (2012) took these conditional factors into account in their longitudinal investigation of two projects. One in ICT and the other in infrastructure development. Both projects were struggling with recovery from a major crisis. Their main conclusions are:

• Managerial actions to recover the project by appealing to a common, positivist logic do not lead to significant improvement in project performance. In some instances, these actions have a negative effect on recovery. Examples of such actions are: changing the scope and the time schedule or increasing the level of control.
• The project teams involved are not naturally inclined to see joint learning as a means of recovering from the crisis. Managerial recovery actions tend to lower the desire for joint learning.
• Intra-team learning and inter-team learning are interdependent. When teams draw different learning conclusions from the same events then joint learning will stagnate.
• Different interventions to restore joint team learning have visible effects only when they are coordinated to change the conditions mentioned above in the same direction.
• Behavioral learning patterns are more likely to occur when there is an immediate and strong need to stop ongoing actions and investigate the causes of the incident. This implies that interventions to improve joint learning should take place in conjunction with what happens in the daily operations, at the work floor.
• Development of joint learning follows a cyclical path consisting of short-term ups and downs and a medium term upward trend.
• Recovery from the crisis—as indicated by increases in mutual trust, joint handling of incidents, joint risk management and overall operational progress—is positively influenced by increases in joint learning.

The following approach represents one way to apply the results from the investigations mentioned above:

1. Make the process of derailment visible in such a way that the dominance of joint influence, instead of party specific influence, becomes clear. Examples of actions that may be required are:

• Use examples of derailment processes from similar projects to show how vicious downward cycles can be described in causal diagrams (see Love, Edwards. & Irani, 2008) and how they can cluster into a derailment scenario.
• Bring representatives of different levels and of different teams together to jointly describe the scenario which led to the crisis of their project.
• Jointly draw conclusions about the specific conditions of the project and how these conditions may have hindered joint learning within the project.

2. Improve conditions for joint learning. Examples of actions that may be required are:

• Change the contract to increase joint risk management and joint rewarding of improvement.
• Soften the impact of higher management’s desire to increase their grip on the project.
• Improve communication channels to promote free flow of knowledge.
• Train team leaders to rebalance their leadership style towards more coaching and less control.
• Stabilize the composition of project teams.

3. Actively promote and support joint learning in the daily operations, at the work floor. Examples of actions that may be required are:

• Mobilize and train a learning support team.
• Prepare for rapid response when an incident takes place.
• Conduct short incident response sessions in which joint incident description, process reflection, mutual feedback, and drawing of lessons learned play a central role.
• Use fast reporting to higher management on the results of incident response sessions.

4. Share and implement lessons learned on a project wide scale. Examples of actions that may be required are:

• Increase active involvement of outside stakeholders in the project.
• Adapt the interface structure of the project organization, both horizontally and vertically.
• Change or increase the budget available for learning support.
• Keep working on the levels of trust and openness within the project.
• Rebalance top-down management control versus bottom-up self-control within the project

The overall aim of this approach is to increase joint learning capability at the level of daily operations within the project and to increase the joint ability to think in terms of the scenario’s in which the joint interactions of parties involved have more influence on what happens than the formal plans of the separate parties.

Reflection

The positivist approach, in short, is aimed at strengthening top management control over the project and to increase the feasibility of the project plan. The constructivist approach, in short, is aimed at increasing the joint learning capability at the operational level and promoting joint rapid responses to incidents. Both have their advantages and disadvantages (see Table 1).

Table 1: Approaches to recovery—Advantages and disadvantages

Although a combination of both approaches requires a wider set of competences of the recovery manager, we see no fundamental restrictions to applying both in the same situation. By combining positivist and constructivist perspectives sensibly and through empirical testing the validity of a project management theory can be enhanced (Morris, 2013).

Summary

Global standards on project management do not acknowledge sufficiently that recovery of a derailing project may require the use of principles and methods that deviate from those standards.

The stream of research aimed at identifying the objective causes of project failure may lure us into believing that objectivity—in the sense of neutrality and factuality—is our primary source of the knowledge needed to recover failing or, as we prefer to call it, derailing projects. However, projects are social constructs. As such, they are real only in the minds of those who have “constructed” the project at hand. Understanding the particular and very subjective logics of action, vis-à-vis the project, is crucial for understanding the process that leads to derailment.

The process of derailment may be caused by a multitude of seemingly unrelated events. Derailment sets in when these events snowball as they become related to each other in the minds of those who are closely involved in the project. The process becomes unmanageable when external infection takes place.

There are at least two different perspectives on how to recover a derailed project: a positivist and a constructivist perspective. Each perspective has its own advantages and disadvantages. Depending on the specific nature of the project and its external conditions a particular combination of both perspectives may be most effective.

Suggestions for Further Development

Empirical research on project recovery management is scarce. Lacking, in particular, is research that is based on comparisons of both similar and different approaches taken in various situations. The results of such investigations should give us a better insight into “what works—and why—in which situation.”

This paper opposes two different views on the causes of and remedies for project derailment: the positivist view versus the constructivist view. One could expand on this by further investigating various combinations of these views in different situations.

The development of our theoretical knowledge about project recovery can probably benefit from studies in other areas, in particular from the area of turnaround management in business and government. Some additional insights may be gained from evaluation reports on the management of natural crises, even though there are some basic differences between the nature of man-made crisis in projects and crisis resulting from natural disasters.

Finally, lessons can be learned from the investigations of projects that are executed under extreme or unknown conditions, such as polar expeditions and outer space expeditions. These lessons may pertain both to prevention of and preparation for derailment (Melkonian & Picq, 2010).