In Defense of the Project Scope

The new PMBOK Guide has a simplified structure for Control Scope. In the 3rd Edition, the equivalent process, Scope Control, had 7 inputs, 4 tools and techniques, and 8 outputs. The 4th Edition has 5 inputs, only 1 tool and technique (Variance Analysis) and only 5 outputs. That's 11 total, down from 19 in the 3rd Edition.

They go like this:

Inputs: Project Management Plan, Work Performance Information, Requirements Documentation, Requirements Traceability Matrix, and Organizational Process Assets.

Tool and Technique: Variance Analysis

Outputs: Work Performance Measurements, Organziational Process Assets Updates, Change Requests, Project Management Plan Updates, and Project Document Updates.

This is the formal structure around "Control Scope", otherwise known as managing scope creep.

And that's important. But is there more to the story? Funny you should ask. There sure is.

The view of the project manager as Proud Defender of Scope is a good one. And Scope Creep is indeed usually a villain. No question there. However, there are times when the PM must have her or his antennae up for "upscope". Upscope, in the form of new project work which is formally accepted into the project via the project's formal change process, is a good thing.

The PMBOK Guide puts it in rather vague and dull terms, but it says it: "If the approved change requests have an effect upon the project scope, then the scope statement, the WBS, and the WBS Dictionalry are revised and reissued to reflect the approved changes".

In other words, it IS okay to say yes to scope change - even scope growth - even significant scope growth - as long as it is warmly welcomed into the project as opposed to what unfortunately happens so often in the real world. Admit it - it's happened to you. It insidiously slithers into the project under the guise of "a favor for the customer", "something cool we can do for a really small amount of effort", or via poorly documented requirements that are vague enough to let scope creep in as if it were dressed up as an original requirement.

In your projects, harness this attitude amongst your PMs. They should be Defenders of Scope, yes. But they also should be Upscopers. By Upscopers, I mean that they have the potential to bring in more business and benefit by being on the lookout for "good scope" and by bringing that scope into the project consciously and publicly. Note all of the outputs of Control Scope: Updates to the PM Plan, Updates to the Scope Baseline. Updates to other project documents. This is what PMI is saying - you can say yes, just make sure that the project accounts for and communicates that yes. Knowing that you can say yes, and that you can account for valid scope change will help create a change in mindset for your project managers. Remember, valid scope change integrates that change into the project plan, and may even effects on the charter if siginifcant enough.

Perhaps you could even reward your upscoping project managers in some way for creative upscope opportunities. There is a lot to be said for a PM who not only manages the project they're handed, but grows it "horticulturally" instead of letting wild weeds pop through the unwatched pavement of your project.

And that's the end of this article. Or is it?