Tip #4: Rescuing a Project from Scope Creep

Tip #4 in the "10 Tips for Project Rescues” article dealt with scope creep; I provided some advice on symptoms of scope creep and how to detect them. This article explores this phenomenon in a little more depth and also provides some guidance on how to correct the problem. First of all, it’s important to determine the cause of the unmanaged changes as they lend themselves to different remedies.

The first step is to determine who is asking for the changes. Once you’ve identified the source, determine whether they have been identified in your RACI or RASCI chart (or Project Charter). Stakeholders who have legitimate reasons for asking for change should be identified in the project’s RACI or RASCI chart; if they aren’t, find out from your sponsor if they were overlooked by the previous PM or weren’t included because they have no business asking for changes in the first place. The solution to the problem of non-stakeholders making changes to the project is simple to resolve, or at least the solution is straight forward; it may not be that easy to implement. Ensure that the Change Management process includes a step for determining whether the requester of a change is a stakeholder and for rejecting a request if they are not. Educate the project team on the process and ensure that the rejection of a request happens at your level and not at theirs.

The above assumes that the project has a Change Management process documented in a plan that was signed off with the others at a Gate Review meeting. If there isn’t a process, you’ll have to start from scratch before any other steps are taken. Once you’ve crafted a plan that describes processes that are compatible with the organization and project. Crafting a Change Management plan is outside the scope of this article however there is information available on the three O website which could help at: http://threeo.ca/changemanagementtipsc700.php. Once you and your sponsor are satisfied with the plan, have all the key stakeholders sign off on it. The best way to do this is to conduct a Gate Review meeting and have them sign off on this plan along with any other plans that have been authored or updated.

You’ll have to be prepared for the "back door” changes that may happen once the people who have been cut off from submitting change requests receive notice that they are no longer permitted to make changes to the project. Once you’ve refused to consider a change they’ve asked for they may attempt to circumvent the process and go straight to the team member they view as the ones likely to perform the work they’re asking for. You need to prepare the team for this possibility and instruct them on the proper way to handle the request, which is to refer the requester to you (or anyone you’ve designated as the PM in charge of Change Management). If you have difficulty handling the requester, ask your sponsor to manage the situation for you. Asking for help during the rescue phase of a project is never a bad thing. Identifying a problem and its solution is what stakeholders will expect from you. Asking for help as part of the solution will provide the sponsor with the opportunity to have a positive influence on the project and contribute to the rescue.

The person asking for changes may be a stakeholder identified as such in the RACI or RASCI (or Project Charter or other project artifact) in which case they have every right to ask for changes. The changes should be because their business has changed, their processes have changed in response to a new policy or legislation, or some other external stimuli. These are legitimate reasons for change; we’ll get to how to address them a little later. Check the records for the requirements gathering process. Was this stakeholder solicited? If the stakeholder wasn’t solicited for their requirements there may be a significant gap in the requirements which will have to be addressed by soliciting all their requirements and doing another round of planning and scope, schedule, and budget reconciliation. Include any other stakeholders who were missed in the exercise. If you’re satisfied that the stakeholder was solicited and given a proper opportunity to identify their requirements the error is on the stakeholder. This doesn’t mean their mistake shouldn’t be corrected through requesting changes but it does mean that all the stakeholders and especially the sponsor should understand the reason for the changes. The stakeholders on your CCB (Change Control Board) may take this into account when deciding on the changes.

The above scenarios cover just about all the invalid reasons for changing the project that I know of. If there are more, I haven’t encountered them. What you’re left with after all these possibilities have been eliminated is request for change that is being stimulated by influences external to the project. Since these stimuli are beyond your ability to control, or indeed anyone in the organization, they have to be dealt with by the project’s Change Management process. If the volume of these changes is overwhelming the team’s ability to address them, it may be time to re-scope the project and re-plan accordingly. If you feel that the team and process can cope with the current volume of change there are still some steps that can be taken to take the pressure off the team.

One of the challenges that projects face when dealing with requests for change is finding the time to analyze the requests. Analysis is a critical part of the process; without analysis the impact on schedule and budget can’t be known and an informed decision on whether to make the change is impossible. One way to relieve the pressure this places on project resources is to estimate the effort required to analyze the change requests and add this time to the project schedule. You can also forecast the effort required to analyze those requests not yet received from the number you’ve received to date and the stage of the project. Iterative projects should only estimate analysis effort for the upcoming or current phase and plan that work into the phase. Effort required for analysis will not be available for other work. I should explain here that it is reasonable to expect SMEs to provide some bandwidth for analysis without breaking it out from the rest of their work. How much bandwidth should be negotiated at the outset of the development phase, but when the project is behind schedule because SMEs are snowed under with change requests you need to create some breathing room so that the project can be brought back on schedule. The SMEs must be given the opportunity to remain on track by having all their work budgeted.

Estimates of the time required for analysis of a change request backlog are likely to have one of two effects: either the sponsor will refuse to allow the time you’ve requested for estimates or they will approve the estimates and the subsequent schedule changes. If your sponsor refuses to accept your estimates they can reject all or most of the changes and place some sort of restrictions on change requests. Restrictions should be negotiated with the stakeholders; either by the sponsor or by you with the sponsor’s backing.

Now that you’ve identified the root problem or one of the root problems that caused the project to deviate from the plan you’ll need to determine how the project should move forward. I’m assuming here that you’ve implemented corrective actions to address the scope creep. If not, that should be your first step.

There are a variety of reasons that could cause a project to go over budget and/or fall behind schedule. Although "scope creep” is a "usual suspect” in this area it is certainly not the only suspect; others are discussed elsewhere in this series of articles on project rescue. The remedy for these problems varies with the problem but the approach to getting the project back on track contains some step common to every scenario.

One of the most important elements of your rescue is the Lessons Learned session. Lessons learned are important at any critical project juncture and even more so when a project disaster has initiated a rescue effort. If you don’t believe me, just look at the airline industry where lives depend on not repeating mistakes. No planning activities should be begun until the Lessons Learned session has been completed and avoidance strategies identified that will eliminate past mistakes. The reasons for any successes the project has enjoyed should also be identified and captured. The lessons should be available to aid planning.

The first step in moving the project forward will be to determine if it should continue at all. This will require you to update the Business Case and/or Project Charter or any other source of information detailing what the project is expected to deliver and the project cost. Getting the project back on track will come at a price. Either the schedule and budget will have to be increased in order to deliver the original scope, or the scope will have to be reduced in order to deliver to the original schedule and budget, or some combination of the two. To re-plot the schedule you must have addressed any issues with incomplete requirements, missed stakeholders or the like. Once these have been addressed you should have a better picture of the actual scope of the project. Re-plotting the schedule will require you to break new work down and estimate effort and duration.

Projects that have gotten into trouble because of a significant change in external influences such as new technology, regulations, or laws will have to have the magnitude of the change these influences will have on the project. In some cases the change may be so great that it is worthwhile defining a new project altogether and in others the existing plans can be re-worked to deliver what the organization needs. The final decision should rest with the project sponsors and should be based on the degree of change to the Charter or Business Case. Your input should be ready if it is called for.

A decision to define a new project will require the team to begin the cycle at the initiation phase. This is not to say that all the work completed to date must be scrapped; the approach chosen for the new project should balance the amount of work that can be used in the new project with the new goals and objectives defined for the new project. Deliverables contracted for with an external vendor will present a different set of circumstances. The vendor is entitled to complete the contract and realize the profits anticipated in the original agreement. The vendor may be in a position to alter the work to be done and the contract, or they may not. Where a decision is taken to scrap an existing project that includes a contract with a vendor the cost of cancelling that contract must be weighed in the decision.

Re-calibration of the existing plans will in all likelihood require visiting all the project’s plans. An increase or decrease in scope will require you to re-visit the Quality Management plan because new deliverables, features, and functions will require new tests. The Risk Management plan will also have to be re-visited to account for the new threats and opportunities the new goals and objectives will introduce. The Procurement Management plan, if one exists might also have to be updated.

Since this tip deals with projects where "scope creep” was identified as a cause of the project problems I’ll focus the rest of my advice on the areas of schedule, requirements and design documentation, and budget, all areas that must be changed to reflect the new direction of the project. New requirements will mean updated documents – Business Requirements documents, design documents, specifications, training manuals, user guides, and etcetera. The development or updating of these documents must be identified in the WBS, scheduled, and resourced. Referring to your Lessons Learned may enable the team to make effort and duration estimates for the rest of the project work more accurate than in the past. Don’t neglect to identify buffers for the analysis of forecast change requests where history warrants it. It’s impossible to accurately predict the quantity and complexity of any change requests that might be made so beyond making the most accurate prediction that the study of past history will allow all we can do is warn the organization when a buffer limit is approaching and the impact that overrunning the buffer will have (either a change request for more SME bandwidth and/or time or a halt in the change management process).

Once you’re satisfied with the new project plans it’s time to review them with the sponsor. There should be no surprises for the sponsor; you should have kept him or her informed throughout each step in the recovery process. Laying out your approach to your rescue should gain your sponsor’s trust providing you have chosen the right approach. Gaining the sponsor’s trust in your approach to the rescue will make the job of selling them on your new project plans that much easier. Once these have been reviewed and approved by the sponsor it is time to organize the first Gate Review meeting for the project. A "Go” decision from that meeting will start your rescued project off on the right foot; now the job becomes making certain the project performs to the new plans.