Most Recovery Plans Don’t Recover Projects. Here Is How To Make Them Do.
Most project managers, planning and project control personnel have been in the uncomfortable situation of having to explain to the client why the project is running behind schedule. This is often followed by the demand or promise to present a recovery plan (RP) outlining the strategies for bringing the project back on track.
However, after it is submitted, the project either recovers for a short while and then relapses into slippage again, or does not recover at all. The reason for this is usually because the RP did not address the real causes of the problem.
This cycle is repeated over and over, to the disappointment of all stakeholders.
So, why is it that these RPs do not recover projects? I will present a few reasons why. I believe you can point out some others. However, before I do so, I think it is important to identify three common terms used in reference to project schedules:
- Baseline Schedule
The Project Management Institute (PMI) defines the Baseline Schedule as the approved version of the schedule model that can be changed only through formal change control procedures, and is used as a basis for comparison with actual results. This is the overall project schedule approved by the client. It is the flight plan, outlining how the contractor or the project team intends to execute the project, hoping that all things work well.
- Revised Schedule
When Murphy’s Law has completed its work on the baseline schedule, and the slippage is so much that the project completion date is no longer realizable, the client may request, and the contractor may submit a revision of the schedule with a new, realistic completion date. This is the revised schedule. It becomes the new or revised baseline schedule upon approval by the client.
- Recovery Schedule
If the slippage is such that the project team still believes that there is a realistic chance of completing the project on time by taking additional measures, then the contractor may be requested to submit a recovery schedule.
The recovery schedule outlines the strategies and measures that the project team intends to take to bring the project back on track. Such measures may include fast-tracking – performing activities in parallel instead of in series as earlier planned. It can also include crashing – adding resources or working overtime, at no additional cost to the client.
As you may have noticed, the main difference between the revised schedule and the recovery schedule is that the revised schedule changes the original completion date. The recovery schedule does not.
With that out of the way, we will now examine why most Recovery Plans do not recover project. Here are some of the reasons:
- Not Identifying or Ignoring the Root Cause
Very often, recovery programs are prepared based on wrong premises; the root cause or causes have not been uncovered because people are not asking the right questions. Perhaps, the delivery of a major equipment is delayed. This is often reported as vendor or manufacturer delay. However, the main reason may be that manufacture or fabrication cannot proceed because of delay in engineering decisions. Simply asking Why until no further answer or explanation can be advanced may lead to the root of the problem.
For example, in one project the client and contractor had a disagreement concerning the inspection and test plan for a major equipment, resulting in the delay of shipment. The contractor was advised to submit a recovery plan while the issue was not yet resolved. I insisted that there was no need for a recovery plan if the disagreement was not resolved. That is common sense! But how many times have contractors submitted a ‘recovery plan’ that begins to slip before there are printed out, because the root cause of the delay has not been identified, or is ignored?
- Poor Documentation and handover of schedule or project assumptions.
Poor documentation of project and schedule assumptions by the proposal team, and handover to project team upon contract award, have been at the root of many project travails. This may be construction equipment capacity description, project personnel competency levels, etc., on which the original schedule was based.
The result is the deployment of personnel with lower competency levels, ostensibly to save cost, resulting in lower productivity than planned. If the RP only considers the number of personnel and not their competency levels or productivity, then the RP will not recover the project.
I encountered a case where a brownfield project was delayed because civil works was significantly behind schedule. Upon review of the contractor’s labor report, I discovered a curious fact: the contractor had deployed much more people than planned and yet the activity was still behind schedule.
Further investigation revealed that planned productivity per person was 3 times what was being delivered. Contractor needed to triple the number of personnel in order to meet up! Moreover, this was a remote location with limited accommodation!
- Lack of management support:
In many cases, project recovery may require the commitment of critical organizational resources beyond the direct control of the project manager. In such situations, management buy-in should be obtained before hand. Otherwise, the program will fail, either because of lack of commitment, or because the commitment comes late, after available resources have already been deployed elsewhere.
Management support may come late because the project team has not been very transparent with reporting, a very common occurrence because nobody wants to look bad before management. The result is that management is kept in the dark concerning project travails until it is too late.
- Solo Effort of the Planning Engineer
It is shameful to say this, but all too often you find that the RP is left to the planning engineers to prepare without the involvement of the team. The program produced lacks realism because those concerned, who actually do the work, were not consulted. The whole team, or at least those who supervise the work, should be involved in preparing the recovery plan. This does not only ensure that estimates are realistic, but it enhances ownership.
- Ignoring historical performance trends
Unfounded and undue optimism about the future and ignoring historical performance trends often attend the preparation of recovery programs. This may spell doom for the RP. At any given point in time, historical performance trend is the only realistic and unflattering prediction of future performance. This must be taken into account, unless it is clearly demonstrated why future performance will be different.
- Unrealistic Initial Baseline Schedule
Sometime the initial schedule was clearly unrealistic. Contractors often take the unrealistic initial completion date imposed by the client and work back, even when it is clear to them that the imposed dateline is not realizable. Some even build the liquidated damage indicated in the ITT package into their contract price, to protect themselves. Consequently, when advised to submit a recovery program, they simply reschedule all the outstanding project tasks from the contract completion date, often arriving at a recovery program that looks like the figure below.
The items listed above need to be address in order to make recovery plans actually lead to project recovery. I do not assume that these are all the reasons why recovery programs do not lead to project recovery.
Perhaps, you know of other reasons why. Your comments are welcome.
I will will work you through the process of preparing a recovery plan in the next essay.
Thanks for reading.
