The following techniques and best practices can be used to help manage scope on your project.

This supplemental content comes from the TenStep Project Management Process.

Proactively Manage Small Change Requests Using Alternative Processes (5.2.P1)

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 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. (5.2.P2)

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. 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.

• Project Manager Discretion. (5.2.P3)

From a practical standpoint, it may make sense for the project manager and 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. This authority must be explicitly delegated by the sponsor. 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. (5.2.P4)

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 was $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 early on small scope changes, 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. 

Do Not Use Estimating Contingency for Scope Changes (5.2.P5)

One of the steps in the estimating process is to add contingency hours to reflect the level of uncertainty associated with the estimate. (For instance, if the effort hours were estimated at 5,000 hours, you might add 500 hours for contingency, which reflects a 90% confidence factor and 10% uncertainty.) Once the contingency is approved, there will be pressure on the project manager to use the contingency to absorb additional requirements. The client might say, “Why do we need to invoke scope change management for this 100 hour enhancement. You have 500 hours of contingency built into your estimate!”

The project manager must resist the temptation and the pressure. The purpose of the estimating contingency is to reflect uncertainty in the estimates. There will be plenty of opportunities to utilize the contingency when activities take longer than expected. Do not use the estimating contingency to absorb extra work. If the project estimates were accurate, you should return the contingency to the client at the end of the project (or consider the contingency as additional profit if you have an external client).

Freeze Scope Change Requests Late in the Project (5.2.P6)

Do you think that as long as you are managing scope change requests diligently, the client should be free to make changes all the way through the project? It is true that changes toward the end of the project tend to take more time and effort to accommodate. However, you might think that as long as the sponsor is willing to approve increases in budget and time to make the change, the client should be able to do it.

This is normally true, but only up to a point. There comes a time in a project where it just doesn’t make sense to make additional changes or absorb additional requirements. That is the time to gain a commitment for a change freeze. Not only are new changes expensive to implement, they are a distraction to the project team.

Depending on the nature of the project, this freeze is usually implemented after the user acceptance testing is approved and the team is getting ready for the “drive to implementation”. At this point, the team is focused on implementing the solution. The team may be working overtime. The project manager may be micromanaging the project to ensure all of the details are carried out on time. At this point in the project, scope change requests are not only costly, but they are also very disruptive. The team can lose focus and become mentally deflated. You may find that the next time there is a “drive to implementation” the team will get sloppy and make mistakes, since this would be the second time they performed these implementation activities.

The better approach is to hold these changes on a backlog and deal with them as enhancement requests after the solution is implemented and stable. (This refers to change requests and not bugs. The users may uncover bugs and errors in their testing and these errors do need to be fixed before implementation.)

If you get agreement on a change freeze date, your team can focus on delivering the current solution. Of course, if there is a change request that absolutely must go in, you can still allow the sponsor to make the call. However, gaining agreement on a freeze date will eliminate the need for additional changes on most projects.

Make Sure Only the Sponsor Approves Changes – Not Users and Client Managers (5.2.P7)

A typical problem on a project is that the team does not understand the roles of the sponsor, client and end users in the area of change management. In general, the project sponsor is the person who is funding the project. If the client were embodied in one person, it would be the project sponsor. The sponsor is usually high up in the organization and not easy to see on a day-to-day basis. In most cases, the sponsor designates someone in his organization to make most decisions on a daily basis.

The people that the project team tends to work with most often are end users. End users are the people that use the solution that the project is building. The end users are the ones that will generally make requests for changes to deliverables. It doesn’t matter how important a change is to an end user, the end users cannot make scope change decisions and they cannot give your team the approval to make a scope change.

In proper scope change management, the sponsor (or their designee) must give the approval. The end users can request scope changes, but they cannot approve them.  The end user cannot allocate additional funding to cover the changes and they cannot know if the project impact is acceptable. If the change is important enough to the sponsor, he will approve it, along with the appropriate budget and duration changes. If the change is not important enough, it will not be approved. However, it will be the sponsor making the decision, not the project manager, client manager, project team or end users.

Don’t Think that Saying ‘Yes’ to Change Requests Shows Good Client Focus (5.2.P8)

The project manager and project team sometimes think that they are being client-focused by accepting scope change while still trying to deliver the project within the original commitments. However, if the project is delivered late or over budget, it is usually not good enough to point out all the additional work that was included because of this ‘client focus’. The project sponsor and your managers don’t want to hear about it. In most cases, the project will not be seen as successful since it did not deliver as promised within the agreed–upon budget and delivery date.

The sponsor is the primary client representative. Allowing the sponsor (or their designee) to make scope change decisions shows good client focus. If the project team or project manager approves scope changes, he is not showing good client focus from the sponsor’s perspective.

Include Deferred Benefits in the Cost of a Scope Change (5.2.P9)

The project sponsor cannot make an informed decision on a scope change request without understanding the business value of the change and the impact to the project. Typically the project manager provides information on the impact to the project in terms of effort, cost and duration. A common deficiency in determining the impact, however, is that the estimates do not take into account the cost associated with deferred project benefit.

In other words, your project will result in a benefit to the company. The benefit usually starts immediately after (or soon after) the solution is implemented. If a scope change request results in the project being delayed, the cost of the scope change should include not only the cost of the actual change itself, but also the cost of the delayed benefit.

Look at the following example.

Let’s say your project costs $100,000. The business benefit is $5,000 per month in increased revenue (or decreased cost). As the project is progressing, the client makes a change request that will cost $5,000 and add one more month to the project. The change has a payback of $1,000 per month.

You may go to the sponsor with a change request that states that there is a $5,000 cost and a payback in five months at $1,000 per month. However, the part that is missing is the cost associated with implementing one month late. In this case, implementing one month later than planned also costs the company $5,000 in deferred benefits, making the total cost of the scope change request $10,000. The sponsor may or may not still approve the change. However, taking into account the lost value associated with a project delay should be a part of the scope change impact for the sponsor to see and understand.

Allow the Sponsor to Make the Decisions. An Engaged  Sponsor Will Usually Say ‘No’ (5.2.P10)

One of the neat things about enforcing the discipline of having the sponsor approve scope change requests is that, unless the change is very important, the sponsor will usually say ‘no’. The sponsor is usually someone high in the organization. He normally doesn’t want to hear about requests for small changes. He wants the original project fulfilled within the original commitments for cost, effort and duration. Even though it may be hard for the project manager to say ‘no’, the project sponsor usually doesn’t have any problem saying ‘no’ to the people in sponsor’s own organization.

Hold Everyone Accountable for Scope Management Process (5.2.P11)

Many scope management processes work well at the project manager level, but get compromised by team members. If the project manager is diligent in enforcing the scope change rules, the client may try to go directly to team members for changes. For instance, when an agreed-upon report is delivered for review, the client may request a second report to provide more clarity. The team member may agree to the work (showing ‘client focus’). The result is that the activity takes too long or resources that could have been applied to other high priority work get absorbed working in an area that is out of scope.

The bottom line is that everyone needs to be held accountable for the scope management process. Team members must understand the process and why it is important. The client must also understand the process and its importance. Don’t consider these procedures to be only of interest to the project manager and the sponsor. Make sure the procedures are communicated to the entire team.

When clients request scope changes directly from team members, bring this to the attention of the client manager or the sponsor. When team members make commitments for work that is out of scope, deal with it promptly. The first time it happens it may be considered a training matter. The next time it might be a performance problem.

Utilize a Change Control Board for Large, Cross-Functional Projects (5.2.P12)

Sometimes on very large projects, the project sponsor does not feel comfortable making the scope change decisions alone. This may especially be the case if the effect of the change will impact other organizations. It may also be the case that multiple organizations are participating in, or contributing to, the project funding, and want to have some say in evaluating scope change requests. For these cases, a group of people might be needed to handle the scope change approval.

A common name for this group is a Change Control Board. If a Board exists, it may be more cumbersome to work through. However, the general scope change management process does not need to change dramatically. For instance, there is still a document for the initial the scope change request. The project team needs to determine the impact and cost to the project. The Board must consider the impact, the value to the project, the timing, etc., and then make a determination as to whether the request is accepted.

The Scope Change Procedures must be somewhat more sophisticated to account for the Board. For instance, you need to clarify who is on the Board, how often they will meet, how they will be notified in emergencies, how they will reach decisions (consensus, majority, unanimous, etc.), how incremental work will be paid for, etc.

Create a Backlog List of Change Requests that are not Accommodated During the Project (5.2.P13)

It is possible that the sponsor may not approve scope change requests during the project, but they may be viable requests that can be done at a later time. These types of change requests should be captured on a backlog list. After the project is completed and the solution is moved to the support organization, there may be opportunities for enhancements or a Phase II project. However, even at a later date, these changes will be implemented only if they are approved and if funding is available.