Develop an IT project recovery plan

Rick Freedman presents a five-step plan for PMs tasked with rescuing a challenged IT project. He also urges PMs to consider the emotional aspects of project rescue.

I would bet that every project manager (PM) has heard about The Standish Group and its CHAOS studies, which purport to measure IT project success and failure rates. I say "purport to measure" because these studies, published periodically since 1995, have recently been questioned, especially by proponents of agile development. While the techniques of the CHAOS studies can be argued, most experienced PMs will agree with one of their key points: many projects are "challenged," struggling to deliver the promised benefits on time and on schedule. The latest CHAOS study, for example, places 44% of projects surveyed in the challenged category.

Many PMs have also experienced the dreaded "project that wouldn't die," an initiative that lost its way and careened out of control, but, due to the difficulties associated with admitting failure, limped on for years, wasting resources and careers along the way. Some proportion of projects in the challenged category surely fit this description, and terminating zombie projects is an important topic, but one for another post. In this post we'll instead examine those projects that, although circling the drain, are worth saving.

Notwithstanding the growth of Project Management Offices (PMOs) and the application of robust project methodologies, projects continue to struggle or fail, with teams, sponsors, and stakeholders denying the calamity staring them in the face. Admitting failure in the business setting is difficult and potentially career-threatening. Nobody wants to raise her hand and tell sponsors that their investment is in jeopardy and that the glowing benefits described during the initiation phase are turning into a heap of ashes. In project rescue, admitting the problem is often the hardest part, but it is the necessary first step to recovery.

Whether a project is on the fast track to success or the road to disaster, the critical measurements of time, scope, budget, and quality still apply. When one or all of these elements is out of whack, our central job in project rescue is to:

  • assess the status of those metrics objectively and dispassionately,
  • perform a limited "root cause" analysis,
  • develop a "get well" plan that the entire stakeholder community can believe and support,
  • execute that plan effectively, and
  • bring the project to successful closure.

We'll look at these recovery efforts in detail, but first let's touch on the emotional aspects of project rescue.

Once it has been acknowledged that a project is in trouble, my experience is that an explicit "get well" program is an absolute requirement for recovery. Rather than trying to sneak in under the radar and thus shield the team from scrutiny, a candid admission that the project is in danger and that we're making a focused effort to set it aright is the only way to begin regaining trust and enthusiasm. Many failing projects have acquired the aura of inevitable disaster, making the rebuilding of belief and positive momentum a deciding factor in recovery. PMs tasked with rescuing challenged projects ignore these psychological aspects at their peril, as many well-intentioned recovery programs have foundered on the rocks of despair and cynicism.

1. Assess the status dispassionately

Projects get into trouble in a variety of areas, from unrealistic budgets and schedules to unexpected technical problems. Some common causes of project difficulty include

  • Technical challenges
  • Skill mismatches or deficiencies
  • Inadequate or unclear requirements
  • Inadequate or unrealistic planning
  • Vendor or partner failures
  • Methodology weakness or misapplication

The mechanics of project assessment should be familiar to any experienced PM: As in any discovery or due diligence effort, we need to review existing documentation, such as plans and charts, interview participants and team members, develop a project history that outlines the events that led to the current challenges, and review any deliverables to assess their quality and completeness.

There are as many reasons for project failure as there are projects, and the emotional elements of morale, ego, and self-protection always come into play. It's one thing for the project to run into unexpected skill-set issues, but it's quite another for a team member to actually admit that they're not quite the genius advertised. Team members can usually tell when a sponsor is applying the "make-it-so" style of management, but it's another to confront that sponsor and deflate their expectations. Project recovery teams walk a fine line in the assessment phase, as we need to recognize and acknowledge these human as well as substantive issues, yet remain neutral and objective so as not to discredit our own findings.

2. Perform a limited "root cause" analysis

Tracing challenges back to causes is critical to the development of a recovery plan, but, again, it is a fraught exercise. The last thing a recovery team needs is to take on the mantle of a "project audit," which is guaranteed to trigger evasion, secrecy, and protective behavior, rather than the candor required to determine a course correction. Facilitation techniques such as brainstorming, force-field analysis, and pareto analysis can be employed, but, whatever method is used, the key is to retain a neutral, nonjudgmental, and nonthreatening atmosphere.

3. Develop a "get well" plan

The obvious starting point in the development of a project recovery plan is the triple constraint of time, scope, and budget. My experience is that unrealistic assumptions in one of these three areas is the underlying problem in the vast majority of challenged initiatives. Artificial deadlines and budgets, imposed by management fiat rather than by objective analysis, are easy to identify but difficult to adjust, as many corporate cultures encourage the "make-it-so" style of management and the "can-do attitude" of employees. This is where the acknowledgment that the project is in danger of failure is a plus; it enables us to concentrate the mind of our sponsors and remind them that unattainable expectations, far from "making it so," instead make it fail.

The best recovery plans look at time, scope, and budget as a blank page, avoiding the trap of getting snared in existing assumptions. The best project recovery plans also apply strict risk management to every element of the plan, as poor risk planning is a key cause of failure. Failing projects are orphans; project recovery teams need to re-engage their stakeholders and convince them that this project can be saved. Success must be redefined clearly and often must be scoped down; one of my key questions is "what's the minimum deliverable required to satisfy the core objectives?" All the project disciplines, from project communication to project change management, must be applied in a consistent manner, and strong leadership is vital.

4. Execute the project recovery plan

Execution of the recovery plan should start with a high-visibility communication program, so that all sponsors and stakeholders know how we plan to rescue this effort and what their role is in the recovery. Without belief and participation, the best recovery plan has little chance. Once the organization is behind the effort, rescue execution, like project execution, is a matter of discipline, consistency, control, and leadership. Since these elements are often missing in challenged projects, it's especially important that we display them in rescue; stakeholders, even if supportive of the rescue plan, will quickly abandon it if it starts to careen out of control again.

5. Bring the project to closure

Closure and customer acceptance are important in every project. In rescue efforts, their significance is magnified. While few PMs would choose to experience a failing project, the lessons we can learn from them far outweigh those from gleaming success stories. The rescue effort has required the team to discover and acknowledge the causes of failure, making the retrospective that much easier by removing justification and rationalization from the discussion. The learning opportunities afforded by challenged projects are enormous; failing to harvest them is criminal.

Explicit acceptance of the result closes the chapter on the project and gives us an opportunity to remind our stakeholders that even seriously challenged projects can be saved by a healthy application of reality-based planning and consistent discipline. Like a losing sports team that conquers a top-ranked competitor, facing defeat and prevailing can boost confidence and change the dynamic for the better.

Related TechRepublic resources


Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

Editor's Picks

Free Newsletters, In your Inbox