Five critical first steps in recovering troubled projects

Introduction

Project failure can happen to anybody—and to any project. A Standish CHAOS Chronicles report states that only 52% of completed projects meet their proposed functionality. The same study, based on more than 13,000 projects, reports that successful projects made up “just over a third or 34 percent of all projects”—meaning, the other two-thirds are failing. Another report on 9,236 information technology (IT) projects showed that project success rates have settled at a startling 28 percent (The Standish Group 2003).

This paper will describe five steps critical to recovery, highlighting the major activities and actions necessary for turning a failing project into a success. These steps are not based on theory; rather, they form an approach based on the trials and errors of senior project managers who have worked in the trenches, assessing and recovering troubled projects in major corporations around the world. This paper is presented from the perspective of the recovery project manager (RPM)—a person assigned from outside the project. However, it's important to note that project managers practicing “self recovery” are advised to follow the same approach.

Defining and Examining Troubled Projects

Simply put, “troubled” means that the project's variance trends of time, cost and scope have exceeded acceptable levels and, without immediate intervention, the project will continue on a path to failure. Troubled projects carry a high cost both to your organization and, by association, to you and to key executives. For example, in 2002 Nike shares tumbled 20 percent upon news that their i2 Technologies supply chain project was in trouble. As a result, Nike lost $100 million dollars in orders because the system wasn't “up and running” (Worthen, 2002).

In another unfortunate story, the former CIO of the state of Maine in the U.S. was replaced after overseeing the implementation of the Maine Medicaid Claims System project. This system was so flawed that it erroneously rejected the claims of 262,000 Medicaid recipients and forced countless doctors and dentists to close their doors or take out loans while the system was being fixed. The project, originally estimated to cost $15 million, is currently at $30 million and climbing. The former CIO? He's now managing the local YMCA (Holmes, 2006).

Trouble Ahead?

Classic project management techniques focus on the triple constraints of time, cost and scope. A good project control system will gather data on each of these elements, comparing actual performance to estimates, typically resulting in variances. But, variances alone—which are expected in the real world—are not, in and of themselves, red flags. It is when those variances greatly exceed “acceptable” levels that attention must be paid to making the necessary corrections to bring the project in line with expected baseline performance.

It's important to remember, however, that baselines, triple constraints and management control systems are only part of the story when trying to determine if a project is “troubled.” Keeping an eye on the human element will also reveal important information about the real status of a project.

The Concept of “Rapid” Assessment and Recovery

Numerous case studies have demonstrated that projects almost always become troubled toward the end of the project life cycle. Thus, the crisis point occurs near the point at which the project should be close to full-scale implementation. Obviously, this is the worst possible time for things to go awry.

At this juncture you do not have the luxury of taking your time to do the requisite assessment and put a recovery plan into motion. Sponsors, clients, customers and other stakeholders will demand immediate results, findings and corrective actions. There will be increased management attention and scrutiny on all activities from this crisis point forward.

This is why you must conduct your assessment and recovery as rapidly, but as thoroughly, as possible. The five step approach that follows is a game plan that works to provide immediate structure and results for the RPM and his or her team. Here's how it works. Let's begin with assessment which focuses on determining the current real status of the project and the changes that need to be made in people, the product or service specifications of the project, and project management processes in order to improve performance. Assessment includes:

• Defining the Charter
• Developing the Assessment Plan
• Conducting the Assessment

Step 1—Defining the Charter

The project charter delegates authority to the RPM, who is typically an individual from outside the project. Because the RPM and his or her team are “outsiders” it is important at the outset that the project manager (PM) and his or her team are committed to working with the Recovery Team (RT). The charter process ensures that this is accomplished before proceeding.

In this important first step you are attempting to identify and agree on a number of critical elements which will be included in the project charter. For example, you need to:

• Define the mission with the sponsor
• Understand the project history and sensitivities
• Establish initial project team contact
• Determine the assessment approach
• Complete the charter and obtain approval

Define the mission with the sponsor.

Successful recoveries have a sponsor supporting the RPM and the RT. The lack of such support is detrimental to the success of any project, but in a recovery project, it is devastating. In a recovery environment, tensions tend to run high, people are on the defensive, customers are angry and team morale is low. Therefore, having a sponsor with the appropriate level of seniority and credibility will send a clear message to all stakeholders that this work is of the utmost importance.

Understand the project history and sensitivities.

Projects almost always operate in a political environment. Being aware of the objective of the project—as well as the objectives and motivations of the key stakeholders—will enable the RPM to better negotiate his or her way in and around the critical issues that are bound to arise during the assessment and recovery process.

Establish initial project team contact.

The project manager and his or her team must be involved with the RPM and the RT at the outset to help assess and recover the project. Establishing early contact with the project team will help gain their support and minimize fear of retribution or embarrassment. This will increase their willingness to help the recovery team.

Determine the assessment approach.

It must be very clear to everyone involved how the assessment will be conducted. The RPM must produce the full assessment plan described in Step 2. This activity will answer the following question: “Given this project, this charter, and the assessment model, how would we go about building the assessment plan?”

The RT needs to identify project data and assessment team resources required to implement the assessment plan. Ultimately, the plan that is developed will—from the outside—appear similar to any project plan. It should, at a minimum, include a WBS, a network diagram, resource requirements and a schedule of assessment actions and how long they will take to complete.

Complete the charter and obtain approval.

Proper establishment of the charter is critical to recovery success. Everyone involved must agree and be committed to the same objectives. As in any charter, it must be signed by a senior manager in the organization and be distributed to all stakeholders.

The deliverable produced as a result of this step is the Assessment Charter.

Step 2—Developing the Assessment

Using this model, the RT will develop an assessment plan that:

• Is realistic and can be executed to achieve the charter's objectives
• Will allow for an assessment in as short a time as possible
• Will ensure that accurate findings are produced
• Will minimize project team distraction

This model centers around two areas of activity at this stage: conducting the interviews and analyzing project data. To do this, the RT will:

1. Identify the critical documentation that needs to be reviewed and analyzed
2. Identify the stakeholders who need to be interviewed
3. Prepare the agenda and interview schedule

Critical Project Documentation

Any assessment must begin with a review of pertinent project documentation. This information is the starting point, helping the RT gain insight, perspective and understanding on why the project is experiencing difficulties. Examples of such documentation include:

• Project charter
• Contract or Statement of Work (SOW), if applicable
• Project plan
• Project metrics and processes
• Signed internal agreements with internal organizations
• Estimate and pricing details
• Project organization chart

Interviews

Using the project organization chart, the RT will be able to identify the individuals who must be interviewed. Examples of stakeholders to be interviewed include:

• Project team members
• Project manager
• Manager of project manager
• PMO personnel
• Project sponsor
• Contractors/vendors
• Clients/customers

Agenda and Interview Schedule

The final action in this step is to develop a day-by-day, hour-by-hour schedule of the assessment process. Having such an agenda puts everyone on notice that time is of the essence and that certain people need to be available at specific times to help the RT. Remember, the assessment period is only a few days. The more detailed and specific the agenda, the more productive the RT will be in its effort to produce a robust assessment plan.

When completed, the assessment plan will include:

• Focused objectives of the assessment
• WBS of the assessment process
• Estimates and resources required for the assessment
• Risk and problem management approaches
• Hourly schedule of activities
• Tools for each task
• List of deliverables to be produced
• War-room needs (if applicable)

As a practical matter, a realistic assessment plan will also consider the geographic distribution of the RT, the project team and the stakeholders to be interviewed. Additionally, the RT should expect a certain level of resistance from the core project team to their activities. After all, the RT is involved because the project has experienced trouble and key stakeholders do not believe the project team can correct its own mistakes. Remember, in planning the assessment the work must be done as rapidly as possible and with as little disruption to the project team as they continue working on the project. The deliverable produced as a result of this step is the Assessment Plan.

Step 3—Conducting the Assessment

The RT is now ready to execute the Assessment Plan, which has three main areas of focus:

• Determining the true current status of the project
• Identifying the major threats, opportunities and problems for the project moving forward
• Establishing an extended team for the recovery effort

One of the keys to successful conclusion of this step is to get off on the right foot—which means conducting a kickoff meeting with the extended assessment team. This includes all RT members, project team members, customers, vendors (if applicable) and sponsors, as well as other key stakeholders whose support is required. The RPM needs to remind the extended team of the purpose, scope and objectives of the assessment. This can be accomplished by reviewing the charter with the group. Also, everyone must understand that the focus of the assessment is on helping the project team, not finding fault with past actions and decisions.

Executing the assessment plan includes:

• Conducting the interviews
• Analyzing the data
• Developing a rank-ordered list of findings

Conducting the Interviews

Good interview techniques are essential to gathering good information. Two assessors and one interviewee for each session yield the most productive information. While one assessor is asking the questions, the other documents the discussion. The roles can switch during the interview. Interviewers should:

• Emphasize the confidential nature of the interview
• Be careful of what they say and how they say it
• Not use a recorder, as people are more guarded when a recorder is present
• Ask open-ended questions
• Be on the lookout for insights into other project areas but be careful not to be seen as going on a “fishing expedition”
• Summarize the main points seeking confirmation from the interviewee

Analyzing the Data

Data analysis involves asking a lot of questions about the data and information contained in the project documentation, as well as information gained through the interviews. The purpose of the analysis is to fully understand the real status of the project. The RT needs to know what the data is telling them and, equally as important, what it doesn't reveal.

For example, an RT member analyzing the WBS should ask him or herself:

• Does the organization of the WBS allow adequate project tracking and control?
• Does the WBS level of decomposition allow adequate project tracking and control?
• Does each work package end with a physical deliverable?
• Is the WBS clear and specific?
• Does the work, as represented by the WBS, include everything that must be done to complete the project, including the project management activities themselves?

Probing questions like these must be asked for each piece of documentation collected. The RT should not assume anything. Interviewers should ask all the questions needed in order to uncover why the project is troubled and how to correct it. In addition to the WBS, the following project data should be thoroughly reviewed:

• Project charter and objectives
• Estimating and pricing details
• Project plans
• Project metrics and processes
• Statements of Work/business requirements document
• Signed external agreements with client and subcontractors (contracts)
• Signed internal agreements with business units

The root causes of troubled projects tend to be centered on such poor project management techniques as incomplete project planning, inadequate tracking and poor control. For example, rarely do troubled projects have a complete network diagram with full precedence relationships identified. If the project manager and his or her team do prepare a network diagram, rarely is it updated. What is particularly disturbing is the practice of simply creating a Gantt chart from a WBS (and usually an incomplete one at that) and using that for project control. This amounts to nothing more than managing a project from a task list, a “to-do” list, which is completely ineffective for all but the simplest projects.

By carefully analyzing the project documentation, a picture will emerge of the oversights and lack of sound project management practices. From this analysis, the RT will identify the threats, problems and opportunities facing the project and be in a position to rapidly develop and execute the project recovery plan.

Developing the Ranked Ordered List of Findings

Once the data has been analyzed, the RT will prepare its findings. The objective is to produce a well-defined list of threats, opportunities and problems ranked by order of severity. In many cases, the findings can be quite voluminous. Certain findings might overlap or be redundant. Therefore, the RT needs to consolidate and aggregate the findings to make them very clear and manageable in number. The use of affinity diagramming to reduce a large number of findings to key categories for recovery execution purposes is recommended. Other options include tools such as the Nominal Group Technique, Delphi Technique, Crawford Slip and Comparative Risk Ranking, which are elicitation techniques aimed at quickly gathering information from experts on various project issues or concerns.

Is Recovery Possible or Advisable?

Once the findings have been documented and approved, they are presented to the key project stakeholders. It is at this juncture that the organization has to ask two important questions: Should we attempt to recover this project? Is it even worth saving?

Answering this question can be a difficult task, but the process is made easier if well-defined criteria are used to evaluate the prospects of moving forward. Such criteria are specific to each organization. That said, the following are general scenarios that might lead to the decision to not recover a project:

• Business benefit cannot be delivered within a reasonable time or cost structure
• The political environment is not supportive of recovery
• The sponsor has departed and no replacement has stepped forward
• Business needs have changed
• Significant technological changes have occurred rendering the approach invalid
• Litigation is in process
• Market conditions have changed

If it is determined that the project is worth saving and the decision is made to move forward, the RT and the project team can do so knowing that the organization is committed to their collective success. At this stage we are ready to begin the recovery process. The deliverable produced as a result of this step is the Ranked Findings Report.

Purpose of Recovery

Recovery is defined as saving a project from loss and restoring it to usefulness. The recovery approach outlined in this paper will focus on meeting the business case objectives as either established at the outset of the project or revised as a result of the assessment phase—the most likely scenario. The RT's main goals in recovery are:

• Producing an achievable schedule
• Re-establishing customer and management confidence
• Re-baselining the project plan
• Sorting project problems
• Rebuilding the original project team

Step 4—Developing the Recovery Plan

The focus of this step is on developing a recovery project plan and assembling an extended team to accomplish the work. In many ways, assembling a team and getting the job done is a project in itself. However, the RT is now faced with a situation where, because of poor performance, they might have a difficult time obtaining buy-in and support or having motivated team members on board. Recall the characteristics of a troubled project—confidence has been lost, people are out of patience. In such a situation, once the RT has re-baselined the project, the schedule cannot slip again. This makes developing an achievable plan of paramount importance. The RT needs committed and dedicated team members to make this happen.

Given the dynamics of the situation, the plan developed for a troubled project is not similar to a plan for a new project. There are many key differences, many of which are listed below. Simply put, a project plan for a troubled project:

• Must not fail.
• Will be subject to extraordinary scrutiny. The team must be ready to defend every action they take.
• Provides for broad fundamental changes in scope, schedule and cost.
• Is of shorter duration.
• Is subject to tighter monitoring and controlling.
• Requires greater frequency of communicating and reporting.

The development of the recovery plan takes into consideration how the RPM will address people and personnel issues, the specific project management processes that will be employed moving forward, and the decisions that need to be made relative to the product/service which is the output of the project. To clarify, the RPM must:

• Focus on building everyone's morale
• Deal directly with personnel problems
• Resolve serious leadership problems
• Add people to the project carefully, if at all

When looking at processes used in the project the RT will:

• Establish a schedule based on inchstone
• Track schedule progress meticulously
• Record the reasons for missed inchstones
• Recalibrate the plan every two weeks
• Never commit to a new baseline until an achievable one can be created
• Painstakingly manage risks

Finally, in regards to the product of the project, forward progress will made only if the RT and key stakeholders—

• Stabilize the requirements
• Trim the feature set to meet schedule and cost constraints
• Reduce the number of defects and implement a quality control plan to keep them low
• Strive diligently to achieve a “steady state”

As can be inferred by the suggestions above, the practice of micromanagement plays a very important role in troubled project recovery. Avoided by most project managers as a discredited form of management, the practice of micromanagement in this environment is the cornerstone upon which success will be built. This micromanagement approach results in great detail and attention being paid to every aspect of work, an important ingredient in restoring the project to a steady state.

Take the concept of inchstones as an example. In a smooth running project, you might do a progress check every week. Using the inchstone method, you would check the progress every day. If normally you would check every day, we will establish hourly inchstones. By employing this method, the RT will know sooner, rather than later, if problems are preventing the achievement of forward progress.

It can easily be seen that using the inchstone approach requires more frequent collecting and reporting of data to all stakeholders. Although this level of administrative overhead would be excessive if used in a smooth-running project, on a troubled project it is mandatory. This inchstone practice alone makes a project plan for a troubled project vastly different from that of a regular project.

The deliverable produced as a result of this step will be the Recovery Plan.

Step 5—Conducting the Recovery

In recovery, you must begin with the end in mind. The “end state” the RT is working to achieve is a project that is no longer in recovery. It's on solid footing with a well-defined project control and management system, an achievable plan and a team that can get the job done. This is accomplished, as in any project, through the process of executing and monitoring and, in this case, absolute focus on the inchstone plan developed in Step 4.

As the team monitors the execution of each inchstone, it will conduct variance analysis at the end of each week. This analysis can only be accomplished if, on a daily basis, the RT is recording the inchstones completed and the daily labor hours recorded by task, skill and person. The collection of this data is only possible if everyone records their daily activities, which is not something that project team members typically do on other projects. You may find it helpful to use “desk-side labor logs,” daily accounting of hours worked on specific tasks by a member of the RT or extended team. The team must also maintain surveillance on other project control metrics, including:

• Earned value
• Defects
• Problems
• Risks

At the end of each week, the inchstone plan will be updated and the RT will:

• Re-plan the next rolling 3-week period
• Examine variances by estimator
• Define or re-define workload for next period
• Obtain new estimates for the next period from estimator
• Acknowledge progress (team, sponsor, customer feedback) to build morale

After three or four periods of sustained, accurate estimates and performance, the RT is ready to pull back from micromanagement and the inchstone process and begin concentrating more on the baseline project plan. At this juncture, the remaining WBS activities must be synchronized with actual project status. Remember, even though the project was in trouble, overall progress never completely stopped. Therefore, the remaining baseline items still need to be accomplished, provided that the RT has been successful in getting the project to steady state. If so, the RT is now ready to begin the transition back to the project team who will complete the remaining work items on the WBS and complete the project.

As the baseline activities are executed, the RT will keep a sharp eye on resources. Care must be taken to get staff on board and work initiated and completed on schedule. Execution must be perfect. There will be intense scrutiny and customers will want frequent and timely status reports. It's not just the project team's reputation that's on the line; often, the customer's job and status are also at risk. The RPM will continue to concentrate on morale building. Chances are, there is still a significant job left to do and the RPM needs to keep team members and other stakeholders committed and motivated.

When the project has been restored to a useful condition and the transition to the project team has been completed, an exit review with the project team and key stakeholders will be conducted. In the exit review, the RPM is looking for the stakeholders to “sign off” on the recovery effort and acknowledge that the RT has been successful and met its objectives. If the stakeholders agree, this is a major accomplishment for everyone. If, however, there is disagreement, it can be demoralizing for all involved. Therefore, the RPM should exercise caution before calling this meeting, ensuring that everyone will agree the objectives are complete before the meeting is conducted. The deliverable produced as a result of this step is the Exit Review.