A few months ago, my friend Tom Mochal published a piece in his TenStep periodical Email blast about how to deal with a stream of "small change requests" on a project. It read as follows:
Proactively Manage Small Change Requests Using
Alternative Processes
Everyone can recognize and appreciate that a scope change request process must be invoked for large changes to the project. However, you may encounter resistance to formal scope change management for small requests. The client and other project team members may consider this to be an unnecessary overhead for such small decisions.
They might be right. There are three alternate techniques to employ that may help with small changes. Note that none of these options implies that you are not managing and tracking scope changes. These are just additional techniques to use that may be more appropriate for managing small scope changes. If none of these options are in place, the project manager should utilize the normal default scope change management process on all changes.
Batching Small Requests.
It is not always practical to get the sponsor to approve all small scope change requests each time one is requested. The project team usually does not have day-to-day access to the sponsor and it is hard to get the sponsor's attention for these small requests. It is a better use of time to batch the small changes up into a bundle. This means that you keep track of the small scope changes, their business value and their impact on the project. Then, when they hit a certain threshold, you take them all to the sponsor for approval.
That is, instead of visiting the sponsor ten times for small scope changes, you batch them all together and see the sponsor one time. At that meeting you and the client discuss all the proposed changes (or perhaps just the larger ones in the batch) and get sponsor feedback on whether they should be done. Even though these are small changes, they should still go through scope change management. Otherwise you are susceptible to scope creep. The benefit of having the sponsor approve the small changes is that if the scope changes are approved, the sponsor should also approve the incremental budget and time needed to get the work done.
Discretion.
From a practical standpoint, it may make sense for the project manager and a tactical client manager to be given discretion to approve small scope change requests under some threshold of effort hours and cost. This decision-making authority should not be assumed - the sponsor must explicitly delegate this authority. This discretion assumes that the project is on or ahead of schedule, and that the changes do not make the project exceed the agreed-upon cost or duration.
If the project is in any risk of not meeting its cost or duration commitments, this discretion should not be used - even for a one-hour change request. If the project is at risk of missing its deadline or budget commitments, all scope change requests must go to the sponsor for approval, either individually or in batches. If the sponsor approves the changes, the project should receive corresponding budget and schedule relief as well.
Scope Change Contingency Budget.
In some organizations it is common to allocate a scope change contingency budget to handle small changes. Your organization may recognize that a certain level of scope change is inevitable and you may be allowed to allocate a percentage of the total project budget to account for this level of change. For example, you may have a 5% contingency added to your budget for scope change. If your total project budget were $500,000, your scope change contingency budget would be $25,000. However, the implication here is that this contingency budget will be all that is allocated for small scope change requests.
The client must manage the budget to make sure all of the small scope changes can be accommodated. If the client uses the budget up on small scope changes early on, there will be nothing left for later change requests. This puts the client in a position of rationing the changes to ensure that only the most important changes are approved. This budget is used for change requests under a certain dollar or hour threshold. Larger requests can still be made but they would go through normal scope change management and be evaluated by the sponsor.
Good suggestions, Tom. If there is going to be a stream of "small changes" the client must also recognize the extra cost of the extra effort involved in processing those changes. On my first contract in Canada, at one point I was getting a change request every day. We had three people (including myself) simply studying the impacts, distributing the request to work package leaders for their assessment of the impact on their areas, estimating the overall effort involved and submitting our responses for approval. If the client didn't agree with the costs we came up with but wanted the change anyway, that was even more work.
One problem with "banking changes" for submission as a group is that very often such changes are only revealed by work in progress and hence require a rapid decision. I think it is unfair to expect the project manager to be making what is essentially a client decision. It only works if there is a very good relationship and trust between the client representative and the project manager. Otherwise, if the client is going to operate that way, then the client must supply the necessary decision-making support.
My solution to disruptive changes, though I must admit somewhat unpopular, was to simply stop work until I got an answer - and report the delay to the end date and draw down on contingency. I think it only had to happen once or twice before a more satisfactory arrangement was established.
