Manage Scope Change or Let It Creep?

One of my favorite definitions of projects is “Projects are how organizations adapt to change.”  Projects are essentially the vehicle for organizational change.  Getting stakeholder agreement around that idea would not likely present much of a challenge.

Change within a project, however, is often the source of great consternation among project managers and stakeholders, particularly as it relates to scope.

Why do we get so frustrated with scope change on projects?  It’s hardly avoidable that our projects will look different tomorrow, next week, next month.

Perhaps it’s not that change, per se, is the problem.  Maybe it’s that unmanaged change is the problem.

What does it mean to manage changes on projects?  Four things should happen to changes on projects.  They should be:

Reviewed

Project changes need to be reviewed by the appropriate stakeholder as defined in the change management plan, however formal or informal that may be.  Someone needs to understand the change and be able to assess the impact to the project.

Approved

Once reviewed, changes need to be approved…or declined.  Someone needs to make the decision as to whether or not the change should be included.  Either way, an authority defined in the change management plan needs to give the thumbs up or down.

Documented

The decision needs to be documented as does the change itself.  All aspects of the project impacted need to be updated, including the PM plan itself.

Communicated

Finally, the change needs to be communicated to all stakeholders per the communications plan.  In particular, people in testing, training, or other areas downstream need to be informed so the change can be included in their work on the project.

The complexity of any of these steps needs to be scaled appropriately and, of course, can be considerable on a large, cross-functional project with stakeholders in many areas.

Scope changes that are not managed, however, make for creepy projects.  Scope creep, that is.

Every project manager is familiar with scope creep: those little things that get added without review, approval, documentation, or communication.

Is it ever OK for things to creep a bit?  Probably.  Some changes really are dinky little tweaks, variations, or changes by any other name, that don’t merit much fuss in trying to manage.  It would take more time to try to manage the change than it would to do it.  Implications for the project may be, in fact, relatively minor.

If a PM does decide to allow for small unmanaged changes, or finds out about a change that somehow got added without much in the way of review or approval, it’s best to try to range in and get the documentation and communication done as much as possible.  Anything to minimize surprises downstream is called for regarding the degree to which changes will be managed.

Change is what projects are all about.  Change also happens within them.  Review, approve, document, and communicate to manage it.  If the change isn’t always managed as much as you’d like, just be careful to not let it get too creepy.