Project scope refers to the box that defines the work of
your project. The boundaries of the box separate the areas your project will be
responsible for versus those areas your project will not be responsible for. It
provides the baseline against which you can perform scope change management
throughout the project.

One of the conflicts project managers face is that they
don’t want to say no when someone asks for a scope change. Since the
requestor is usually a client manager, stakeholder or end user, the project
manager usually feels an instinct to do whatever is needed. Saying “no” to the client
request means not being client focused, or not satisfying the client’s needs.

However, there’s a simple way to get you out of this yes/no
dilemma. The secret is simply to understand that the project manager doesn’t
have to be the “no guy.” In fact, the project manager doesn’t need to decide
one way or another.

The project manager’s job is to identify scope change requests
and take them through the scope change management process. The next time a
client asks for a change in scope, ask him to send you an e-mail explaining the
new capability and the business value of the change. Have him include a
description of the consequences if the change is not made. Determine the impact
to the project on terms of budget and schedule and then send the benefits and
costs to the sponsor for approval.

If the client insists on the need for the change, explain
that you’re not disagreeing with him, but it’s just not your call. The sponsor
makes decisions on scope change requests.

Placing the focus on the sponsor to make scope change
decisions changes the entire dynamic of a discussion. It shifts the pressure
from the project manager to the client, forcing him to explain the benefits
well enough that the sponsor will approve. The project manager can then focus
on what he or she should be doing—proactively and effectively executing the
scope change management process.