The Essential Process"How much time has passed since the project break point was reached? It all depends on the nature and size of the project. In most cases, however, it should not be more than one to three weeks in duration. Anything more than this will begin to lose the attention and faith of the extended project team. Too little time and the answers and solutions may lack sufficient accuracy and wisdom to be effective. If you cannot find the answers to rescue the project in this timeframe, you will need to restructure the objectives of the initiative to further break it into smaller phases."
"The project team, and specifically the manager charged with rescuing the project, will need to change focus from investigation mode to a tactical, hands-on one. The Execution phase requires a different set of skills and focus from the project rescue manager. This new involvement can be summarized as 'Lead-Track-Resolve'."
"Leadership is needed to implement the rescue plan and ensure that the extended team remains committed and focused on the results. Frequent tracking activities are necessary to capture the truth about what is really happening. Resolution will be required to deal with the additional problems that will arise in this phase."
"'Lead-Track-Resolve' is illustrated in the center of the figure below, with some of the factors that could potentially damage the momentum of the project once again shown around the perimeter of the circle. These factors are particularly nefarious because they cannot be mandated away by the executive sponsor. These wildcard problems could or could not materialize, so mitigation strategies have to be reasonably flexible. This is the reason for building contingency into the project rescue plan."
"Identifying these issues before they become big problems through extensive and proactive tracking provides an opportunity for resolution with minimal use of contingency built into the project plan. It is a good idea to preserve as much of this contingency as possible for as long as possible. Leadership abilities are required to offset the negative emotions that will arise when yet more problems appear and the team confidence starts to waver."
"The following list identifies some problems that can plague a project at this stage of the rescue life cycle:
- Inaccurate information collected Despite reasonable efforts to validate the information that was collected in the assessment and planning phase, some facts could just be plain wrong and will need to be readdressed.
- Overconfidence Overconfidence needs to be actively managed to avoid a false sense of security. Overconfidence is as bad as a lack of confidence. Overconfidence can lead to shortcuts and assumptions that prove to be false. It can also create conflict within the team by rubbing some team members the wrong way.
- Missing skills Someone can look great on paper and do well in interviews, and may be the best you can find, but there may still be some missing skills.
- Contradictions Some of the basic objectives, requirements, and metrics may be in conflict as deeper analysis is done in this phase.
- Technology problems Certain conditions may never have been identified and tested and materialize only after a lot of work has already been expended.
- Employee burnout The project team may be working so hard and intensely that some members begin to burn out and lose productivity."
"Mitigation strategies should be in place to deal with each of these problems, or at least reduce their impact. A contingency or workaround should be planned for each of these and other similar problems that may still materialize despite your best efforts."
"There is another set of problems that could arise in this phase; however, these problems can be addressed by the executive sponsor. Some examples of these include the following: process problems, change of direction, new business requirements, loss of buy-in, and funding cuts. These can and must be dealt with by the executive sponsor and business users. New requirements cannot be accepted in the current release. Funding cuts cannot be accepted by the project team unless time is set aside to assess which functionality can be removed from the scope of the project. Accepting these types of changes is the same as starting another project and needs to be treated as such."