Managing Scope Changes
,Regardless of the project management life cycle (PMLC) model you choose, you will have to deal with scope change requests coming from the client and from the project team. In some cases, you'll be expecting these change requests, and you'll be ready to process them. In other cases, you will not be expecting them (or at least won't want them), but that doesn't absolve you from having a way to process them. You need to have a scope change management process in place as you start the project so you can deal with both the expected and unexpected changes that will come your way.
The Scope Change Management Process
It is difficult for anyone, regardless of his or her skills at prediction and forecasting, to completely and accurately define the needs for a product or service that will be implemented 6, 12, or 18 months in the future. Competition, client reactions, technology changes, a host of supplier-related situations, and many other factors could render a killer application obsolete before it can be implemented. The most frequent situation starts with a statement that goes something like this: “Oh, I forgot to tell you that we will also need ...” or “I just found out that we have to go to market no later than the third quarter instead of the fourth quarter.” Face it: Change is a way of life in project management. You might as well confront it and be prepared to act accordingly.
Because change is constant, a good project management methodology has a change management process in place. In effect, the change management process has you plan the project again. Think of it as a mini-JPPS.
Two documents are part of every good change management process: the project change request and the Project Impact Statement. Here's a brief description of what each of these documents contains:
Project change request — The first principle to learn is that every change is a significant change. Adopt that maxim and you will seldom go wrong. What that means is that every change requested by the client must be documented in a project change request. That document might be as simple as a memo but might also follow a format provided by the project team. In any case, it is the start of another round of establishing COS. Only when the request is clearly understood can the project team evaluate the impact of the change and determine whether the change can be accommodated.
Project Impact Statement — The response to a change request is a document called a Project Impact Statement. It is a response that identifies the alternative courses of action that the project manager is willing to consider. The requestor is then charged with choosing the best alternative. The Project Impact Statement describes the feasible alternatives that the project manager was able to identify, the positive and negative aspects of each, and perhaps a recommendation as to which alternative might be best. The final decision rests with the requestor.
One of the following six possible outcomes can result from a change request:
It can be accommodated within the project resources and timelines — This is the simplest of situations for the project manager to handle. After considering the impact of the change on the project schedule, the project manager decides that the change can be accommodated without any harmful effect on the schedule and resources.
It can be accommodated but will require an extension of the deliverable schedule — The only impact that the change will have is to lengthen the deliverable schedule. No additional resources will be needed to accommodate the change request.
It can be accommodated within the current deliverable schedule, but additional resources will be needed — To accommodate this change request, the project manager will need additional resources, but otherwise the current and revised schedule can be met.
It can be accommodated, but additional resources and an extension of the deliverable schedule will be required — This change request will require additional resources and a lengthened deliverable schedule.
It can be accommodated with a multiple-release strategy and by prioritizing the deliverables across the release dates — This situation comes up more often than you might expect. To accommodate the change request, the project plan will have to be significantly revised, but there is an alternative. For example, suppose that the original request was for a list of 10 features, and they are in the current plan. The change request asks for an additional two features. The project manager asks the client to prioritize all 12 features. He or she will give the client eight of them earlier than the delivery date for the original 10 features and will deliver the remaining four features later than the delivery date for the original 10. In other words, the project manager will give the client some of what is requested earlier than requested and the balance later than requested. I have seen several cases where this compromise has worked quite well.
It cannot be accommodated without a significant change to the project — The change requested is so substantial that, if accommodated, it will render the current project plan obsolete. There are two alternatives here. The first is to deny the change request, complete the project as planned, and handle the request as another project. The other is to call a stop to the current project, replan the project to accommodate the change, and launch a new project.
An integral part of the change control process is documentation. I strongly suggest that every change be treated as a major change until proven otherwise. To not do so is to court disaster. That means every change request follows the same procedure. Figure 6-2 is an example of the steps in a typical change process. The process is initiated, and the change request is submitted by the client, who uses a form like the one shown in Figure 6-3. This form is forwarded to the manager or managers charged with reviewing such requests. They may either accept the change as submitted or return it to the client for rework and resubmission. After the change request has been accepted, it is forwarded to the project manager, who performs an impact study.
Figure 6-2: A typical change control process
Figure 6-3: Change control form
The impact study involves looking at the project plan, assessing how the change request impacts the plan, and issuing the impact study, which is forwarded to upper management for final disposition. They may return it to the project manager for further analysis and recommendations or reject it and notify the client of their action. The project manager reworks the impact study and returns it to upper management for final disposition. If they approve the change, the project manager will implement it into the project plan.
Management Reserve
One way to control the abuse of client-generated scope change requests is to set up a time contingency in the budget. Just as a dollar budget has a contingency line to take care of unexpected expenditures, so also should a project schedule have a contingency for the unexpected. This is called management reserve. There is a good way to account for management reserve in the project schedule and there is a bad way.
Consider the bad way first. In this case, you might hear a task manager saying: “It should take about three days to complete this task, and I am going to put five days in the schedule to account for the unexpected.” What's wrong with this approach? Just about everything. First, the two days of padding is hidden in the plan. The three-day task will mysteriously expand into a five-day task. That is Parkinson's Law (work will expand to the time allotted to complete it) and not at all what was intended. Second, the two days of padding is very arbitrary and will accomplish nothing more than confusing the project schedule and taking away the project manager's ability to effectively manage the schedule.
Now take a look at the good way to account for management reserve. First, add up all of the labor for all of the tasks in the project. A percentage of that total will become management reserve, and it will be tacked to the end of the project tasks as the last task before the project is complete. The percentage that you allocate to management reserve can vary. I have seen ranges from 5 to 10 percent. The same approach can be used for a sequence of tasks that lead into the critical path. Do the same calculation for that sequence and add the management reserve to the end of the sequence just before it merges back into the critical path. This idea shares a lot in common with the concept of a buffer in Critical Chain Project Management (CCPM). Critical Chain Project Management is discussed in detail in Chapter 10.
The client needs to know how much contingency time has been put into management reserve task. You need to explain to the client that every scope change request costs time. The time to process the request and the time to accommodate the change in the schedule make up that time. That time will be deducted from the management reserve task. When that time is spent, the only way the client will be able to make additional scope change requests is if the time is somehow replaced in the schedule. They can do that by deleting some future requirement not yet put into the solution. The time associated with that deleted requirement will be credited to management reserve.
Scope Bank
Another way to control client-generated scope change requests is to set up a Scope Bank with a deposit of time in it. In principle, this is very similar to management reserve and operates the same way. The time to process and incorporate a scope change request into the project schedule is deducted from the Scope Bank and that time is added to the project schedule. Clients can make deposits to the Scope Bank by deleting requirements from the solution. The Scope Bank will be adapted to some of the PMLC models in Part II.