Project Rescue and Recovery

A few years ago, we had a run in with the healthcare industry. I think of it this way since is sounds like a run in with the law. Doctors are the law, or so they think. Do as they say, or else. The problem was that my wife, at 46, was having a heart attack and had a hidden... oops... I almost spoiled the story. Unbeknownst to me, Doctors rarely think about two things being wrong; they only work on one issue at a time. Those of us who live in project work realize this assumption can have grave consequences. What the doctors in this case needed was an anal-retentive, tenacious, asshole of a Project Manager whose objective was a successful project. As Gene Kranz so aptly said, "Failure is not an option," the product, service or end result of this project was a life—my wife's. However, I am getting ahead of myself. Let me take a few minutes to set the stage to show my mistakes and how years of project recovery experience helped. I will keep it brief.

In many years of recovering failing projects, I have found a few management actions whose rationale seem completely absurd. Regardless of my efforts, I am unable to understand or dissuade them from their decisions. These decisions either precipitate the failure or greatly exacerbate the project's dilemma. Regardless, due to management's level of shear desperation, they can only be classified as stupid decisions. If there were the Darwin awards for management, these would qualify.

Full implementation of agile project management requires a top-down approach. The differences in reporting, resource dedication, team structure, and customer relationship from traditional project management methodology requires buy-in at the highest level of the company. Educating superiors and customers on the benefits of agile project management is difficult, especially if they have a religious belief in classical project management style. Implementing a pilot project is the best way to quell their fears. Unfortunately, in a recovery this luxury is unavailable—the turn-around becomes the pilot.

From years of experience in recovering red projects, I estimate that only a third of all problems that affect red projects are actually on the project; the other two-thirds are in the surrounding organizations. Poor policies and procedures or lack of commitment by the customer, vendor, integrator, or organization overshadows problems on the project. Unfortunately, project managers do not have the authority, or even the influence, to address these issues. Their only course of action to complete the project successfully is to band-aid the problem. This must change if companies are going to quickly and accurately implement business initiatives.

It is amazing how people on failing projects neglect to look at their own issues prior to blaming someone else. Yes, blame is easy and on red projects since no wants to be the source of the issues. The truth is, everyone is at blame, so before bringing in an auditor or recovery manager, tidy up your house first.

Red project recovery is a four-step process. One must, however, determine a short-term plan for the project. It takes time to get to a resolution and it is nonsensical to continue spending money at the current rate. Other than doing nothing, there are two remaining options:

The four steps to bring a project back from red. They are:

1. Project Audit;
2. Data Analysis;
3. Solution Negotiation;
4. Plan Execution.

Like any recovery, be it twelve-step or four-step, it goes nowhere without realization of the problem. Step zero is acknowledging the failure. Without this step, the problems and subsequent resolutions will not have full recognition and the project recovery will fail due to the lack of management support. With realization, the recovery process has meaning.

Reading an article the other day, the author was lamenting on how Project Managers were under educated and needed to know more about earned values analysis, risk probability determination, finite schedule development and other tools that make a Project Manager great. She was arguing that certifications, like PMI's PMP^® certification, needed to have more testing on those subjects.

Select any area to learn more:

Months ago, maybe over a year, now, I was blasted for talking about innovation in the context of information technology (IT) projects. The gist of the complaint was that all IT folks think they are building some new groundbreaking, revolutionary application that requires the latest in technology's tools. I agreed with his argument, qualifying that although this seems to be a pervasive theme, IT is a discipline that needs to keep one-foot in the pioneering frontier. Regardless, I had to concede that many innovative initiatives are more about a technician playing with some new toy. Jobs like implementing ERP interfaces to manufacturing execution systems (MES) only sound new. Unfortunately, I must say, "been there done that." Most IT is neither new of innovative. To avoid squandering funds, executives must understand and direct what needs to be innovative and permeate the company's culture with that knowledge. Otherwise, the wasted time and expense will suck a company dry.