Rescue My Project™

an overview of troubled projects and how we deal with them

Abstract

Estimates indicate that troubled and failed projects cost the global economy billions of dollars annually (Sessions, 2009). In today’s fast-paced, competitive world organizations need to ensure that time and money directed to projects result in a positive return on investment. The reality of troubled projects needs to be brought into the mainstream. When project managers are faced with a troubled project, they need to be given support and a methodology to get those projects back on track. This paper discusses why projects fail, the warning signs that a project is troubled, the triggering events and introduces a methodology for effectively and efficiently planning and executing the entire project rescue process.

Introduction

Any project, at any organization, and with any team can fail. However, projects never go from being well managed, on budget, and on schedule to outright failures overnight. There is always a transitional period, during which the project is “troubled” and it is during this time that a window of opportunity exists in which to rescue the project (ESI International Inc, 2006).

When the first signs of trouble appear, a common reaction is denial. When the problems are left uncorrected, and the project deteriorates to the point where it can no longer be ignored, there is a tendency to invoke rash actions, such as assigning more resources, mandating overtime, or even firing team members in an attempt to correct the situation and address the desire to lay blame. Unfortunately, none of these actions aids in the recovery of the project because they are unplanned and have not been developed to address the root causes of the problems that are plaguing the project.

There is a common notion that by virtue of the fact that a project was started, it should automatically be recovered; however, sometimes the best business decision is to cancel the project. In this case, there is still a process that needs to be followed to gather the necessary information to accurately establish that the project is not worth saving and then gracefully execute the termination process.

Causes of Trouble

In today’s corporate environment, it seems that every organization is battling the problem of too many projects with too many deliverables for the time, budget, and resources available. The difficult task of trying to meet demands with limited resources means that projects are at high risk of becoming troubled right from the beginning.

There are many reasons why projects fail and it is rare that failure can be attributed to one cause. Very often there are several factors that, in concert, lead to a project’s failure. The specific details of exactly what went wrong will be unique to each troubled project; however, for the purposes of introducing the high-level factors, the following categories summarize some of the common reasons projects fail:

  • Poor requirements definition and scope management – Requirements must be precisely defined, agreed upon, and then managed. Requirements can change over time, but these changes need to be evaluated and carefully implemented through a change control system. When requirements are imprecise, ambiguous, or are lacking agreement, it will be impossible to satisfy deliverables. When scope is inadequately managed, the stage is set for failure.
  • Inadequate organizational support and stakeholder alignment – If an organization is not fully committed to meeting the objectives of a project, if there is a weak business case, and stakeholders are in conflict over the goals of the project, the conditions are ripe for failure.
  • Inadequate risk management – Every project has risk. Risk must be planned for and actively managed. Unplanned and/or unmanaged risk is almost guaranteed to cause problems.
  • Communication problems – Well-planned communications on the project that keep everyone informed of what they need to know are crucial to success. Stakeholders must be continually aware of the latest progress and issues to allow for early detection and correction of negative trends. Effective communication also ensures that project team members clearly understand their roles and responsibilities, their work packages, deliverables, and the acceptance criteria for those deliverables. Everyone on the team knows the processes that are being followed and are informed of changes in a timely manner. When communications are poorly planned or executed and stakeholders and team members are unaware of information affecting them, the project will struggle to be successful.
  • Inadequate resources – If the right people and materials are not assigned to a project, it will make success difficult. The right number of human resources with the right training and skills must be committed to the project. The equipment and material required to deliver the project must be properly identified, planned for, and made available.
  • Inadequate project management methodologies – Although all of the above mentioned factors should be addressed through proper application of project management methodologies, it is important to highlight the role that inadequate project management processes plays in a project’s failure. A project must be formally and accurately planned and this plan needs to be documented and made available to all stakeholders and project team members. An effective change control system needs to be in place and, as important as selecting and communicating the project management processes to be followed are, adherence to these processes must be enforced for the entire life cycle of the project. It is rare that a troubled project won’t have problems of some type, which directly stem from inadequate establishment or enforcement of project management methodologies.

Another consideration in the occurrence of project troubles relates to the cost of changes. In a normal project life cycle, stakeholder influence, risk, and uncertainty will be high at the beginning of the project when the cost of implementing those changes is low. As time progresses, the cost of changes to the project increases. At the same time, in a healthy project, stakeholder influence, risk, and uncertainty will be decreasing. The increasing cost of changes as the project progresses is a normal pattern; however, if the factors creating change are not decreasing, the chances of a troubled project are greatly increased.

Declaring Project Trouble

Despite the fact that there are often a multitude of symptoms indicating that a project is experiencing trouble, there can be great reluctance to admit that there are problems. Low team morale, unhealthy conflicts, incomplete deliverables, exceeded budgets and schedules, angry customers, and high defect rates are all glaring symptoms of a troubled project. The root causes for the trouble are not likely trivial, but the very fact that a project is in trouble should always be clear. And, yet, there is still great reluctance to say or do anything.

The longer you wait to declare trouble, the more time and money will be required to recover the project and the higher the risk that the project will be outright cancelled. The sooner you deal with problems, the easier it will be to have successful solutions.

Exhibit 1 illustrates the impact of delaying the declaration of project trouble. As the project’s health deteriorates, the cost and time of recovery and the risk of project cancellation increase.

Impact of Delaying Declaration of Project Trouble

Exhibit 1 – Impact of Delaying Declaration of Project Trouble

The reasons for not declaring trouble are many and varied but, as a group, they are called suppression factors. Suppression factors can be defined as conditions that cause project team members to either knowingly or unknowingly ignore signs that a project is troubled and avoid bringing the issues to the attention of management, stakeholders, and other key decision makers.

Suppression factors cause the true project status to be hidden or distorted. This prevents the timely identification of a situation needing corrective action and deprives management of critical information that results in decisions being made without accurate input. Some examples of suppression factors include denial, strong incentives, fear, and apathy.

Symptoms of Trouble

There is no exact definition of a troubled project, and the specific criteria by which a project will be identified as troubled are unique to every organization. In general, however, it can be said that when a project’s trends in time, cost, and scope variations (the triple constraint) have exceeded defined, acceptable tolerance levels, and it is believed that without immediate corrective action, the project will fail, then the project is considered troubled (ESI International Inc., 2006).

Symptoms should serve as alerts to deeper problems; they do not equal the source of the problem. Just like a fever is a symptom of something wrong in the body, project symptoms are indicators of deeper project troubles. The following list provides a few examples of trouble symptoms:

  • Low team morale
  • Consistently missed milestones
  • Incomplete documentation
  • High defect rates
  • Defensive attitudes and lack of trust
  • Unresolved issues
  • Stakeholder loss of interest

It is important to recognize the difference between project troubles and project risk. Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective. Trouble is a certain event or condition that has either already occurred or will inevitably occur. Trouble always has a negative effect on at least one project objective. When a risk event does occur, it can potentially cause a project to be troubled, which is especially true when risks are unplanned, unmanaged, or unknown.

There will always be a trigger event that leads the project owners or sponsors to declare the project troubled and initiates the project rescue process. The trigger event is more than just another trouble symptom; it is the final event that directly results in official declaration of trouble and initiates action. There are an infinite number of things that could be trigger events and some are listed below:

  • Project is trending 30% or more over estimated budget and/or estimated deadline
  • Project can stay within acceptable cost and time tolerances only by reducing quality to a point where value and integrity of the deliverable are reduced to an unacceptable level
  • Project completion date cannot be estimated
  • Requirements are continually changing
  • Dysfunctional communication exists
  • Project goals and constraints are mutually exclusive
  • Team morale is negatively impacting the performance of the project
  • Excessive overtime is being used

Project Rescue Process

Once a project has been identified as being troubled, the project rescue process is initiated. It must be clearly understood by the original project manager, rescue project manager, project sponsor, and the rest of the project team that the project rescue is a project unto itself. The project rescue activities align with the classic definition of a project. It has clearly defined start and end dates, it creates a unique result, and it is progressively detailed as the project is better understood. In parallel to the project work, the project rescue will require planning and resources and will have clear objectives and deliverables.

The project rescue process is illustrated in Exhibit 2.

Project Rescue Process

Exhibit 2 – Project Rescue Process

There are a number of different outcomes that can result from a project rescue:

  1. The project is completed successfully within original tolerances for time and cost. This is an ideal scenario that is usually not possible. If a project has gotten so far off track as to initiate a project rescue, then the chances of being able to complete the original project scope within the original time and cost budgets are very low.
  2. The time and cost estimates and/or the project scope definition are reevaluated and redefined. Solutions to root causes are implemented, the project team is reassembled, and the project continues with a focused approach on working toward the new project criteria.
  3. The project is terminated. There can be solid business reasons why terminating a project is a better choice for the corporation than implementing a project recovery. The graceful termination of the project will ensure that an effective communication plan is put into place, legal and human resource considerations are addressed, all components of the project that can be reused are salvaged, and the project resources are reassigned.

When a project is in crisis and stress levels and expectations are high, following a well-defined, structured process and using appropriate tools and templates will facilitate delivering findings, recommendations, and corrective action plans with efficiency, expediency, and accuracy.

Assessment Phase

The assessment phase is the first, critical step in the project rescue process that must be completed once a project has been identified as being troubled. There are three objectives to the assessment phase:

  1. Determine the current state of the project
  2. Determine the root causes of the problems
  3. Determine the changes that need to be made

Before root causes can be determined and change recommendations developed, it is crucial that the current state of the project be well understood. The rescue project manager must understand what has been done and what has not been done. He or she needs to determine the current status of work packages, schedules, costs, defects, risks, resources, and issues. He or she also needs to understand the project management plan and what processes are currently being employed for managing communications, change, and control.

Once the current project status is fully understood, the next objective of this phase is to determine the root causes of the problems. Sometimes multiple problems or symptoms can be traced back to a single root cause. Taking a conscientious, thorough approach to the root cause analysis will create the foundation upon which effective corrective action can be developed.

The final objective of the assessment phase is to determine the changes that need to be made. These are the recommended corrective actions that specifically target resolution of the underlying root causes that are behind the project’s troubles. An effective project decision cannot be made without having a good understanding of what is required to recover the project.

There are five key elements to ensuring a successful project assessment:

  • Right people – The assessment team needs to include people with sound knowledge of project management methodology and the technical aspects of the project.
  • Senior executive commitment – The project team needs to know that senior executives are committed to the assessment and view it as a priority. Team members and stakeholders need to be aware that they are expected to allot time to this activity and be as cooperative as possible.
  • Open access – The assessment needs to be granted open access to all project information and team members. If the current status of the project is hidden or if key aspects of processes, for example, are not open for audit, an accurate view cannot be achieved.
  • Decision makers – Indecisiveness will slow down the assessment process. It is important that the assessment team have access to those with the authority, knowledge, and experience to act decisively.
  • Planning – Well-organized, detailed planning is a key success factor for the assessment. You need to know exactly what you are going to do, how you are going to do it, in what timeframe, and what you are ultimately going to deliver. Without solid planning, the assessment runs the risk of taking too long (while the original project continues to get more off course) and not delivering effective, accurate information.

The assessment process has a number of different steps, with each step having a specific purpose, inputs, and outputs.

  • Create assessment charter
  • Create assessment plan
  • Conduct assessment
  • Determine current status
  • Determine root causes
  • Create assessment report
  • Develop recommendations
  • Write the report

Project Decision Meeting

The purpose of the project decision meeting is to answer the following two questions:

  • Is the project worth saving or is it better to terminate?
  • What are the immediate actions that need to be taken regardless of whether the project will be recovered or terminated?

Determining whether a project should be recovered or terminated can be a very difficult decision to make; however, it is important that this decision be made as objectively as possible to ensure the best outcome for the organization. As Peter F. Drucker, author and esteemed management consultant, said, “There is nothing so useless as doing efficiently that which should not be done at all.”

The facilitator of the project decision meeting needs to keep this meeting focused on the facts of the project and lead the meeting participants through a variety of considerations that will ultimately form the basis of the decision. Questions need to be asked to fully explore areas of the project related to approval, originality, alignment with business strategy, technological considerations, customers and markets, and the current project status (Kapur, 2001). The answers to these questions will ultimately form the basis of the decision as to whether or not to recover or terminate the project.

When the decision is to recover, there are three fundamental strategies for recovery that can be implemented independently or that can be combined to produce additional strategies:

  • Reduce project’s scope to speed time to completion.
  • Increase productivity by implementing short-term process improvements.
  • Slip the schedule to allow the scope objectives to be satisfied to the quality level expected.

An example of combining these strategies would be to reduce the scope as much as reasonably possible, increase productivity where it is possible to implement improvements rapidly, and slip the schedule as necessary to accommodate the remaining scope.

Recovery Phase

The recovery process is a project unto itself whose unique services are the creation and implementation of plans and processes to get the original project on track for success and to restore the project team to a productive, fully functioning state. The recovery project will implement change on the original project to trend that project to a successful completion. It is important to remember that the delivery of the original project’s product or service is not a deliverable of the recovery phase. That remains a deliverable of the original project.

There are three key objectives to the recovery phase:

  • Develop a plan that will facilitate meeting the business objectives, either as originally established, or as redefined as a result of the assessment and project decision meeting.
  • Establish the processes necessary to ensuring the successful implementation of the plan.
  • Restore confidence and morale to the project team and all stakeholders.

The recovery process has a number of different steps, with each step having a specific purpose, inputs, and outputs:

  • Create recovery charter
  • Create recovery plan
  • Conduct recovery
  • Create recovery report

There are four key elements to the success of recovery. Three of these elements—right people, senior executive commitment, and planning—are the same elements that were discussed for the assessment phase. The fourth element that is necessary for recovery success is diligent monitoring. The recovery project manager needs to know at all times exactly what is going on within the recovery project and within the original project. He or she needs to understand the impact of implemented change requests, the trends, issues, risks, and communication status. This is a role that requires rigorous application of project management methodology.

Termination Phase

The termination phase is initiated when the outcome of the project decision meeting is to terminate the project. The purpose of the termination process is to gracefully end the project when the project decision meeting has determined that it is better for the organization to terminate the project rather than recover it.

There are four key objectives of the termination process (Kapur, 2001):

  • Ensure all human resource and legal implications that could result from the project cancellation are identified and addressed.
  • Plan and execute the announcement of the cancellation in a coordinated manner that ensures customers, stakeholders and project team members are provided with accurate and timely information.
  • Salvage usable equipment, documentation, and knowledge.
  • Reassign team members and release resources.Simply coming to a hard stop on the project without properly planning and communicating can leave team members in an even more demoralized state that could impact performance on new projects and make it difficult, if not impossible, to salvage usable equipment, documentation, and knowledge. Failing to end a project through a well planned termination process will only compound the organization’s project troubles.

Closing Phase

The purpose of the project closure phase is to ensure that all of the administrative tasks required to officially end the project are completed.

The following are the objectives of the project closure:

  • Establish lessons learned and generate a lessons learned report.
  • Gather historical records related to the project recovery or termination.
  • Close any contracts specifically related to the recovery activities or any outstanding contracts that have not already been closed as part of the termination process.
  • Complete all administrative activities that can include the following actions:
  • Obtain customer approval that the acceptance criteria for the recovery or termination were satisfied.
  • Ensure transition plan has been successfully executed in the case of a recovery.
  • Ensure salvage plan and resource reassignments have been successfully executed in the case of a termination.

This phase is important to any project, but even more so when the closure is for a troubled project. There are valuable lessons to be learned and being able to capture what went wrong and how it was fixed will provide immeasurable value to future projects. Malcolm S. Forbes, publisher of Forbes Magazine said, “Failure is success, if we learn from it.”

Summary

Troubled projects can happen in any organization, with any team. When trouble does happen, it is important that the trouble be acknowledged and the urge to invoke rash decisions be avoided. Following a well-defined methodology for determining the sources of the trouble, creating plans for either termination or recovery, and then executing those plans with meticulous monitoring will enable project teams to trend their project back to a healthy operating state.

Baumbach, C. (2008, May). Why projects fail (and how to avoid the pitfalls). Retrieved July 2008, from http://esj.com/articles/2008/05/13/why-projects-fail-and-how-to-avoid-the-pitfalls.aspx

Center for Business Practices. (no date). Troubled projects: project failure or project recovery. Retrieved July 2008, from http://www.pmsolutions.com/uploads/pdfs/Troubled_Projects_Research_Summary.pdf

ESI International Inc. (2006). Saving troubled projects: five steps to rapid recovery. Retrieved July 2008, from http://www.esi-intl.com/en/Skills-Development/Knowledge-Center/White-Papers/Saving-Troubled-Projects---Five-Steps-to-Rapid-Recovery.aspx

Kapur, G.K. (2001). How to kill a troubled project. Retrieved July 2008, from http://common.ziffdavisinternet.com/download/0/1299/cioinsight_whiteboard.pdf

Mochal, T. (2005, July). Strategies for turning around a troubled project. Retrieved July 2008, from http://downloads.techrepublic.com.com/abstract.aspx?kw=strategies+for+turning+around+a+troubled+project&docid=173667

Sessions, R. (2009, November). The IT complexity crisis: danger and opportunity. Retrieved April 22, 2010 from http://www.objectwatch.com/whitepapers/ITComplexityWhitePaper.pdf

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2010, Brian H. Munroe, PMP
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.