Leadership

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

About

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...

6 comments
PMPsicle
PMPsicle

Don't forget to assess the politics of the situation. Any project that has careened out of control has become a political issue -- even if politics wasn't the reason for its failure. Internally, anyone who is associated with the project will be trying to avoid being blamed. Externally, anyone with an interest will be trying to push their agenda since this is a pre-approved project with no (currently official) goals.

CultOfTech
CultOfTech

... and it'd be too easy to overlook THE most crucial factor Rick is trying to make here. It is the "emotional aspects of project rescue" - kudos though on hi-lighting it in a separate paragraph just before the "meat" of the topic (the five points). My point...? It's all easy to be objective and clinical about a mess that's not yours to begin with and you may be great as a PM in that aspect... but never overlook the basic factor that the resources in play here are also human-beings!! Once again, kudos, Rick.

director
director

The article is a good overview to project rescue, but it makes one of the classic mistakes when it refers to Time, Cost and Scope. A vast number of PM's think this way but the ones who really shine out are those who instead think about Time, Cost and Benefits as the three measures of success. Yes, it is Scope that delivers Benefits, but ask yourself this, "if I descope this piece of the project, will I lose All, Some or None of the benefits?" and the flip side, when scope is increasing, "if I increase the scope by adding this extra piece, will this increase my benefits Significantly, Somewhat, or Not at all?". Sadly if the focus is only on the Scope and not on the Benefits then the behaviours are not always what is needed... This is becuase some PM's consider Change Control to be "a way of saying NO". Whereas Change Control, when used to increase OR decrease a project's scope, should be seen as means of saying "YES, but there will be an impact" and then where the impact assessment demonstrates that the benefits associate with the Change Request make it a more attractive business case overall then the approval becomes a no-brainer. I urge all PM's to focus on Time/Cost/Benefits rather than the more narrow Time/Cost/Scope. Best regards for recovering your Projects from the brink of failure:-) Iain www.imb-consulting.co.uk

mameenuddin.aisc
mameenuddin.aisc

Indeed very informative article for someone who at this moment is experiencing exact symptoms of project getting derailed. However, have been candid with management and the recovery plan has been placed under execution. This article exactly details what approach we have taken but in chocolate wrapped way. Great Info Sir.

RickFreedman
RickFreedman

Iain; Great concept, and nicely phrased. The connection between Scope and Benefits is rarely made explicit, but it clearly is a constructive way to think about our work. If PMs can be successful at forging a direct connection between the benefits that a particular feature or function delivers and the "scope" element, whether its a user story or a traditional requirement, it opens a new way of communicating with our customers and positions us to have the right sort of negotiation. Now we're negotiating about real business benefits and value rather than about pet features or the emotional attachment to a particular idea. This deserves some more exploration. Thanks for the feedback.

Editor's Picks