Project Recovery

Do any of these sound familiar? The project feels like a lie as the project plan has little in common with actual events. There is complete lack of trust between customers, managers, and developers. No one has any sense of schedule or cost. All attempts at fixing the project just make things worse. In spite of chronic overtime the customer has lost all hope of every receiving the system. The team's morale is low and attrition is high. These are the common symptoms of a project in dire need of recovery. Project recovery is a rescue effort to save the project, setting the project again on credible schedule, budget, and quality. Recovery often requires establishing a new schedule and budget calibrated to what the team can produce as well as re-scoping the project. Project recovery is a limited period of time of strong intervention by a determined external expert taking decisive actions to save the project. You need project recovery assistance when there is no hope of ever meeting any schedule or staying on any budget, or when quality is out of control as fixing one bug introduces new defects. The goals of recovery is to stop the hemorrhaging and deliver on a new date and scope, to restore trust across the project stakeholders, to rekindle faith in the team's own abilities, and to avoid the crisis again in the future.

Over the years IDesign was called to save projects from the brink, and we have successfully lead project recovery efforts, gaining unique experience and insight in rescuing projects in distress. IDesign's recovery does not focus on fixing symptoms such as the schedule or the budget, but instead addresses the root causes of the failure, by regaining control over the project. We use recovery as a bridge from despair to delivery, capped in duration, after which we return the project to conventional project management.

While there is no formula to project recovery (since every case is unique) we have found a few general techniques and approaches that are always instrumental in designing and executing project recovery:

  • Design review using root cause analysis to identify why things went wrong. We identify deterministic causes (which doomed the project out of the gate), execution failures, and process failure. For each reason we itemize how it contributed to failure, mapping it to specific behavior and practices, drawing lessons and educating the team and management. We use project design tools to reconstruct what actually took place and learn what is the team's true capabilities and potential.
  • A salvage operation deciding what can be saved, what must be salvaged, and what must be discarded. We rely heavily on quantified analysis methods, not opinions, measuring the quality and complexity of the various components in the project, and estimating the ROI of each salvage activity.
  • Damage control to determine the impact on other projects, followed by a crucial effort to stabilize quality, to limit the damage to this and other projects.
  • Basic practices overhaul. We redefine the project fundamentals across quality, process and architecture. These were almost always the root cause of failure and we often can't afford to wait post-recovery to establish best practices.
  • A comprehensive recovery plan. We calibrate the plan to what the team can produce, negotiated across all project stakeholders, incorporate the salvaged items, restructure the team and decide on the new activities.

The recovery plan is key to effective recovery. In essence the recovery plan is nothing but project design for the recovery effort, using regular project design techniques and tools. However, unlike regular project designs (such as the ones taught in our Project Design Master Class) the recovery plan is always short-term, and not aspiring for the fastest schedule or cheapest delivery, or to use the correct system design. These attributes are secondary to delivering the project and rebuilding trust, so we design the recovery for minimum acceptable risk, using our method for project design and quantified risk.

Once the initial success is demonstrated and the new practices took root, IDesign disengages, because the project must stand on its own feet. We often do remain in contact for periodic health checks, design reviews, and similar related activities through our virtual architect service.

Click here to watch a webcast outlining some of our project recovery techniques and contact us for additional information.