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.
Recovered projects are projects that have deviated past the acceptable thresholds, but due to interventions, the project objectives have been recovered to an appropriate level to still provide acceptable benefits to the stakeholders.
Says Hannes van den Berg, MBA, PMP, Managing Director of ProjectLink: "What happens when a project is troubled, and a recovery effort is initiated, and all the project objectives are back on track, but the project still fails in meeting its true objective, the business objective, the reason for existing in the first place?"
Recovering a project that is really troubled is not for the fainthearted. Van den Berg believes recovery is not achievable and repeatable without a project recovery methodology. The more complicated a project is, the greater the importance of a recovery methodology.
Several project recovery methodologies exist. Many of the project recovery methodologies have a four-step process, namely (1) audit/identification of current status, (2) analysis of the problems (fault finding), (3) negotiate the recommended actions, and (4) implement the recovery plan.
Exhibit 3 depicts the high-level project recovery methodology and associated actions:
Step 1: Audit the project. The primary aim of this step is to review all the project documentation to determine the current status. All the relevant stakeholders should be interviewed to obtain their understanding in terms of expectations, issues and risks. Most of the problems should be identified through the audit process.
Step 2: Analysis of the problems. Analyse every identified problem on the project. Identify the burning platforms. Also ensure that the basics are put in place, such as redefining or confirming the scope of the project. Identify the real schedule and cost drivers. Suspend or eliminate deliverables in the scope that are not immediate requirements for achieving the project objectives and reschedule it as far in the future as possible. Draw up a new plan aimed specifically at the recovery effort. Be realistic in terms of what is achievable with the current funds and resources.
Step 3: Negotiate the recommended actions with the major principals. The principals' support is critical to implementing the recovery plan. Present the recovery plan to them, substantiate every action in the plan, and negotiate where possible. This negotiation will also create new expectations and ownership from the stakeholders and ensure that the new baselines will be the ones that measurement is made against.
Step 4: Implement the recovery plan. Follow a sound project management methodology. Control the project by means of the performance measurement baseline and manage issues actively. Make sure communication channels are open to the stakeholders; keeping them informed is a critical success factor for continued support, otherwise they might get easily disillusioned. Escalate major issues to ensure that the steering committee also takes ownership in the project. Enforce discipline; this is no time to relax! Celebrate every achievement, because this will motivate the team.
Project managers are usually measured by the performance of the project against the agreed on project objectives, usually related to the constraints of time, cost, scope and quality. It is therefore not often that a project manager would really focus on the benefits of the project as defined in the business case, even though one can argue that the project manager should. Usually the project sponsor and/or the project steering committee are the ones that would focus more on the business objectives because their performance is measured against it.
From experience on other types of projects, once a project goes into execution, the focus is diverted to the implementation of the project and very little attention is given to the business objectives. "This is even more so in the recovery process; recover the agreed-on project objectives, because meeting this will lead to a successful project delivery, a popular, but mostly incorrect, belief!" states Van den Berg.
The project sponsor and steering committee are also not necessarily in a position to fully comprehend the outcomes of the business objectives. They often rely on the project manager to provide them with the information on the outcome of the project. During the recovery process, the danger exists that the project manager and project sponsor get fixated on the ruthless pursuance of the actions required for recovery, thereby neglecting the implications to the business case by compromises on the project objectives.
The business case often has several assumptions used for financial modelling and planning, which are never validated. Once the project goes into implementation, the focus is entirely on the execution and no one really revisits these assumptions. Thus, there is no owner to validate or invalidate these assumptions, revise the business case accordingly, and analyse the outcome.
How do you remedy this situation? Here are several remedies:
* Ensure that the project manager and/or project sponsor fully understands the business objectives and what the impact might be on decisions made concerning the project objectives. Involve the project manager in the business case; no single person focuses more on a project than the project manager.
* Always consider what the impact might be on the future operations or users when you are recovering the project and the subsequent actions that you take.
* Never start a recovery effort before understanding the reason or benefits required from the execution of the project; you will be able to identify and question issues related to the business case. This will ensure that any decisions made on the recovery effort are made in context and with the implications and outcomes in mind.
* Project managers should always take ownership of the assumptions made during the study phases/business case development; chances are good that no one else will. A dedicated effort should be embarked on to validate/invalidate the assumptions as soon as possible. Best practices from systems engineering can be implemented, traceability.
* The business objectives must always outrank the project objectives on a project. This must be a ground rule on the project whenever any decisions are made.
* Most recovery methodologies require focus on the basic elements of a project due to the burning platforms. Be aware that by only focusing on the burning platforms, you might neglect other not so obvious elements that might lead to unknown consequences. Plan to address all issues once you have control over the project.
* The environment changes continuously; schedule environmental scanning sessions frequently to validate that the business case is still completely relevant.
* What quite often happens with external recovery efforts is that the project is recovered, and the recovery team moves on. Where skills are lacking, provide training and leave the project with enough momentum to ensure sustainability.
* When decisions are made on the project objectives, revisit the various options that were considered during the initial business case. These might be options related to the market, logistics, commodities and so forth.
Van den Berg concludes: "When you are asked to recover a troubled project, make sure that you approach the project correctly. Do not start off by neglecting what the true goal of the project was. Make sure that the business case is sound, and only then pursue the project objectives and recover the project. Take ownership of the business and project objectives; even though you might only be a part-time designated project recovery manager, chances are that no one else would. Remember: Don't always recover the project, sometimes you need to rethink the business case."
References
Project Management Solutions (2006). Troubled projects: Project failure or project recovery. [Electronic Version] Retrieved from http://pmsolutions.com/
Vargas, R. (2009). Identifying and recovering troubled projects: How to rescue your project from its failure.
Retrieved from http://ricardo-vargas.com/articles/recoveringtroubledprojects/
Williams, T.C. (2011). Rescue the problem project: A complete guide to identifying, preventing, and recovering from project failure. New York: AMACOM.
Share