Project recovery or putting projects back on track is a key ability that project managers need to possess and will be valued by their employers. Project recovery involves many steps that include examining the overall project environment, and examining specific problem areas to carry out root cause analysis, and implement the most important corrective actions as determined through Pareto charts and weighted decision tables. Carrying out root cause analysis requires experiential insights to look for clues in common problem areas, closely examining the area further to identify the root cause. Having a better understanding of project requirements helps project managers to identify root causes of requirements related problems and hence implement corrective actions.
A recovery plan differs from a typical project plan in four key areas: Purpose, content, governance, and personnel. The project recovery plan is not aimed at delivering the project, per se. The existing project will have its own scope, plan and benefits it is aiming to achieve. The recovery plan instead will be focused on getting the existing project back on track. Its sole reason for being will be moving the existing project from one that is failing to one that is now set up for success.
Identify the changes
Having identified requirement change as a critical success factor, the questions are if requirement change should be avoided and if it is possible to avoid or easily control requirement changes. Projects will be refined as time goes by and a certain level of changes is essential to ensure that the project is successful eventually. Therefore, it is neither desirable to avoid requirement changes and nor is it possible to avoid them because customers will be very forceful in demanding requirement changes.
Managing changes
A standard way of managing requirement changes is by applying a change control procedure. There are standard steps in these change control procedures – requirement changes are registered through a change request form and are documented in a change request register with assigned numbers. Then, the priority of the change is determined and impact is analysed. If the changes are few that can be managed through a change control procedure, the level of changes can be considered to be manageable. On the other hand, if requirement changes are going unnoticed or the changes become so high that carrying out impact analysis becomes an unmanageable overhead, then, we say that the requirement changes are at an unmanageable level.
Projects always start off with good intentions. Good intentions are in the forms of certain tangible objectives. These objectives are usually project objectives, derived from the business objectives. Once a project is in implementation, these good intentions sometimes become more difficult to obtain. As soon as the project deviates beyond a manageable threshold, distress signals are sounded and the project becomes labelled as troubled or a red-project. Once a project is troubled, a decision is required — to recover or not. If it is not recovered it is usually the end of the project and it is known as a terminated or failed project.
Need some more help?
We have helped a wide variety of leading global brands across multiple industries to manage change. To find out more about how we can work together, get in touch with us by filling out the contact form on our website and one of our experts will be in touch. Visit our website and fill out the contact form, and one of our experts will be in touch to have a friendly chat to find out more about your business.
