Scope Management Does Not Mean Scope Stoppage

This is Part 1 of a 2-part post.

I would like to address what seems to be a common misunderstanding regarding the term “scope creep.”

I read a recent question posted by a LinkedIn colleague titled “Why do so many project managers think scope management means scope oppression?” I like the question this post raises. I agree with the premise of her post, which is that we need to anticipate and expect change, and while it is our job as PMs to have a recommendation regarding the requested scope change, it is management who ultimately decides if the time and cost impact is worth taking to make the requested change to scope.

However, I disagree with one point made. This may be an issue of semantics, but I want to make sure we are all on the same page. The author says that “scope control has been described (incorrectly) by some PMs as ‘eliminate scope creep’.” Given the agreement from the responses she received, this seems to be a commonly misunderstood concept.

The misunderstanding relates to a different understanding of  scope creep. I had learned, and continue to teach in my classes, that scope creep results from adding unapproved changes. According to Wikipedia, scope creep “refers to uncontrolled changes in a project’s scope.” Controlled changes are fine. But we do want to stop uncontrolled changes.

I agree with her that, unfortunately, when we talk about scope management with stakeholders, they (and too many PMs) only picture the negative and not the positive aspect of this. They see their future requests being denied rather than PMs better managing the scope so the project can be delivered successfully. Nobody likes to be forced to define everything up front, because they often don’t know exactly what they want and do not want to limit their ability to change their mind in the future.

We have to take on a more healthy approach, letting stakeholders know that changes will be allowed if they make sense given our objectives and constraints. I don’t want to stop *all* changes. That is unhealthy. But I do want to eliminate changes that shouldn’t be made, or in other words, scope creep. Our job is to manage changes so they are for the good of the project.

Project success is defined as delivering a project on time, on budget, and within scope. This includes the original plan PLUS approved changes. We are not locked-in to all of the original estimates.

There is no expectation (on my projects) that change won’t happen, because as we all know that is not reality. The idea is to manage it for the good of the project – accepting some changes (where they make sense) and denying others that are deemed to be out of scope. I work with my teams to phrase scope management in a positive way, and I make it clear up front that I know changes will occur and it is our responsibility to help control them so we can deliver to the real constraints, which are normally budget and time.

I will continue this thought in my next post.

From Vicki Wrona

In this article

Join the Conversation