Managing Scope Changes

Managing Scope Changes

The biggest single cause of project overruns is changes in scope. It's what you did not plan to do that will sink you. Scope changes are insidious. If you do not manage them, your budget and schedule will be destroyed before you recognize that anything has happened. If you manage them well, your career as a project manager is assured.

If you have defined the project properly, you know what is in and out of scope. Therefore, managing scope changes simply means identifying them and estimating their impact on the project. However, it bears repeating that before you can identify what is out of scope, you must know what is in. Put negatively, if you have not adequately defined the project, you will now pay the price.

Origins of Scope Changes

Scope changes arise from four sources:

1. Overt client requests. The easiest scope changes to identify are those that the client requests. They are not always the easiest to deal with, since the client may not agree that they are changes, but they are always obvious.

2. Covert client requests. Many scope changes sneak in when someone on the client team makes an informal request to someone on the project team for "one more report," another type of inquiry, or a new area of functionality. Such a request becomes a problem when the team member acts on the request, building it into the system, without telling anyone elseincluding you.

These changes are not usually conspiratorial; nobody is out to cheat the system. They are, in fact, a consequence of what you want to establish: good working relationships between the project team and the client, a climate in which team members are encouraged to exercise judgment, and a professional attitude aimed at providing value. Unfortunately, if all this legitimate good will is not tempered with some control, the project's scope will explode.

3. Smuggled requirements. The most difficult types of scope change to detect are those that are introduced as part of normal information gathering. For example, your team is conducting a workshop to determine detailed requirements for the purchasing system, and among them is a set of requirements for calculating vendor payables. The scope of purchasing has just been expanded to encompass accounts payable.

When these types of scope change arise, it is not usually because user teams are intentionally trying to sneak in scope changes. They happen because business functions overlap and it is not always easy to determine where one ends and another starts.

4. Project team enthusiasm. Scope changes often arise from the project team itself. It is commonplace for team members to create new requirements. After all, why not provide a sales analysis by customer first name; the client may want to know sales to people named Fred.

You do not want to discourage new ideas from your team, but you also do not want them to act until you have talked to the client. In many projects, new features get added without the project manager's or the client's knowledge. They just seemed like a good idea to the team.

Identifying Scope Changes

You identify scope changes by following a few consistent practices that are designed to build in a sensitivity to change requests.

1. During the project kickoff meeting, state the scope and ensure that everyone on the team understands and accepts it.

2. Make sure that the scope is visible to everyone on the team through mottoes, pinups, and other "advertisements."

3. Ensure that the scope is included in orientation materials for new team members.

4. During the weekly team meeting, conduct a separate roundtable to review scope change requests.

5. Whenever you or your technical leaders need to make a project decision, ensure that the scope is included as one of the factors contributing to the decision.

6. During your period of reflection, include scope as a subject for review.

Scope Changes and Justification

Your first question in reviewing any scope change request or suggestion should be, "What position shall I take toward the change?" That is, will you support it and push for its approval, or will you argue against it? Your stance should be determined by the effect of the change on the project's justification. Since the entire purpose of the project is to provide some benefit, you must support only those changes that will increase the benefits or the probability that they will be realized. Once you have determined that that is the case, you will still need to estimate the cost of the change and compare that with the resulting benefits, but your first filter must be whether or not the change will provide any benefit at all. If it will not, it does not belong in your project.

Dealing With Scope Changes

Scope changes will affect the project budget and schedule, so your second question in assessing any scope change request should be, ''How much?" Answering this is a planning and estimating process that becomes especially complex because you need to incorporate the change into the existing project plan. A cautionary note: When you estimate a scope change, do not forget to include additional time for project management, quality control, contingency, and any other overhead costs.

A change of scope must be approved by the client before you act on it. As part of project planning, you should have defined a procedure for dealing with scope changes, including a means to submit change requests to the client. Exhibit 5.5 is a sample scope change request form. In any scope change request, you should specify a date by which you require a response. The change may be easy to handle up to some point in the project but difficult or more expensive after that. For example, a functional change may be readily included only until functional design has been completed.

A strategy that some project managers recommend is to look for a small scope change early in the project and submit a change request, offering to include it at no additional cost. The purpose is threefold: to exercise the change control mechanism, to give the client notice that changes will be scrutinized, and to demonstrate service by including the change at no cost.

When the Client Disagrees

In many cases, your client may insist that the change request is part of the original scope and that you include it. There will be gray areas where both you and your client are justified in your respective positions and you will need to negotiate. Ultimately, you may need to escalate the issue to your management. The danger to the project is that while you and your management are negotiating, valuable time is passing, as is the flexibility to act upon the changes.

Remember that there is a difference between an estimate and a price. The estimate reflects work effort, whereas the price is a management decision. You or your management may decide to include a scope change at no additional cost, but the extra effort is still required and the schedule will be affected.

Even though the client contends that a piece of work is not a change of scope, you can be sure the work needs to be doneat least in the client's opinion. You must therefore conduct two negotiations: one for the schedule and one for the budget.

The schedule must be renegotiated. The client was expecting results by a certain date and now will not receive them until later. Unless you can compress the schedule in some manner, the slippage is nonnegotiable: Work takes time.

The second negotiation deals with who will pay for the effort. This is a management issue distinct from project management. You may be expected to handle the negotiations, but in doing so, you are no longer acting as a project manager whose job is to ensure delivery of results; you are acting as a client or account manager. To be effective, you will need the support of your management in establishing a negotiating position and in helping you to maintain it.

What If?

The Team Has Accepted a Change Request Without Your Knowledge And Has Started Working on it.

Unless there are unusual circumstances, this is symptomatic of problems in your control of the team. The scope changes will mushroom, and you will not know what is happening.

Actions

Reestablish control. Estimate the effect of the change request on the schedule and budget and let the appropriate team members know what their generosity has cost.

Meet with the client to ensure that all change requests come through you and not to members of your team.

The Client Insists on a Change That Does Not Fit The Project Justification.

The only reason for the project is to provide benefits. Work that does not meet this criterion is wasted, and you run the risk that the project will ultimately cost more than was justified by the benefits.

Actions

Determine why the client wants the change and ask for an outline of how it would benefit the organization. If it enhances the original project justification, it may be reasonable to include it in the project.

If the change does not provide benefits or is unnecessary, it is your responsibility to go on record as opposing it. You may be instructed to include it, but you need to make your position clear.

Look for signs that the project is at risk. When clients start making unreasonable demands, you may be dealing with a project that has become an object of political tactics in the client organization.

The Original Scope is Ignored on The Grounds That The Additional Requests Are Vital To The System.

When a client rejects the original scope, you now have a project that does not have one. You will have no way of managing scope, and the project costs and schedule will balloon.

Actions

Determine what business conditions have arisen that have forced such a radical change of scope. If you cannot identify any, recommend that the original scope be maintained and that any enhancements be conducted as separate projects after implementation.

If you are overruled, state that since the original scope is no longer in effect, neither is the original project plan. Recommend calling an immediate halt to the project while it is rescoped and replanned.

If the client does not agree, you have two choices: Attempt to fit new requirements into the existing design, or announce that you cannot continue under these conditions.

Approved Scope Changes Become so Numerous That They Threaten The Intergrity of The Original Design.

The changes will ultimately lead to a compromised designin the worst case, one that must be abandoned. The project now runs the risk of becoming a mega-failure.

Actions

Call an emergency planning session with your key team members to review the scope changes, the probable future changes, and the current state of the project.

Review the design and identify the points where it is at risk.

Determine if the system can be redesigned while retaining the majority of the work that has been done to date.

Prepare a plan to implement the redesign and present it to the client and to management along with the reasons that the new design has become necessary.