Project in Recovery (not THAT Recovery!)

When a project has been close to failure and shut down is not an option then my repetitive approach to resolving the remaining issues usually goes something like this:

1. Agree on the Recovery Project Charter
   1. Scope
   2. Objectives
   3. Budget
   4. Staff
   5. List of Open Risks, Issues, Change Request
      (preferably these lists will be placed in Recovery Project Priority Sequence as part of producing the Charter)

The approach I have taken once we get agreement on the Charter is very tactical and focused on only a few possible activities and outcomes.  It’s simplistic but has been very effective for me in the past.

Create a Daily Punch List that starts with an early morning meeting of all contributors to the Execution of the project.  This should include representation from the Executive, Business, and Technical teams.

The agenda for this meeting is fairly simple:

• Review the open list of the highest priority Issues and Change Requests that remain unresolved
  • On Day One, this will require that the team spend the appropriate time to establish this Priority sequence if it has not already been done as part of the Charter.
• Determine the current status of the highest priority items and agree that:
  • Progress has been made
  • The Priorities have not changed to some other items that are lower on the list
• Discuss the as yet inactive items on Issues and Change Requests to determine an agreeable combination of the following:
  • Priority – on an appropriate scale with clear definitions of what each level means and how each item qualifies for that level
  • Outcome – determine one of THREE possible outcomes for each item:
    • People – The person or group who represent each item may need to be informed of some capability of the solution as already built that can address their issue without making any changes to the proposed solution.  This could mean that education, training, and demonstrations are needed to convince the submitter(s) / owners of each item that they were unaware of the already built and tested capabilities of the proposed solution.
    • Process – The processes and integration points into and out of the proposed solution need to be changed so that the capabilities of the automated part of the proposed solution can address each item.  This could mean that although the automated solution is capable of resolving the item, the data preparation and usage around the solution was not sufficient to allow these features to be shown.
    • Product – The proposed solution, whether it is an in-house developed solution, a pre-packaged and configurable licensable software product, or a combination of cloud and internet features and custom programming, does not have the capability to address each item and, therefore, must be changed.  This could have been caused by unclear Requirements and Specifications; misinterpreting some Requirements into Specifications and / or code, or missing some Requirements entirely.This Outcome will often require that additional planning and funding be provided before the change / fix can be staffed and implemented.

If one early morning meeting does not provide the time to go through the entire open item list (Risks, Issues, and Change Requests), then more brief meetings should be scheduled each day until the entire list can be handled in ONE Meeting!

Ultimately, these lists should show progress of being reduced on a Daily Basis with a predictable schedule so that the newly Planned Completion Date for the Recover Project becomes measurably achievable.

Thanx, bgbg