Scope Creep vs. Valid Project Changes

I’m working on a project right now where the original plan looked like this:

• A staff member would use her laptop at home to record a screen-capture video in which she’d talk through training material while sharing slides.
• The footage would be passed to a video editor for very minor edits.
• The video would be shared with its intended audience.
• Reception and effectiveness of the training video would be assessed.

If well-received, a new project might be initiated in the future to re-record the training in the studio, with higher-quality footage of the trainer speaking on camera, and her slides would be edited into the video by the editor afterward. But this was not guaranteed, and if it happened, it would be a separate project.

It was a good plan that limited the amount of staff time put into this training until after we had feedback on the initial proof-of-concept version.

But after we started the project, we learned this person does not have the correct equipment to record this video at home on her laptop, so discussions began about filming the initial version of the video in the studio anyway.

Is this scope creep?

I’ve worked with people before who consider any project change to be “scope creep,” and by referring to changes in this way, they’re saying that all changes are bad, a mistake, or shouldn’t be happening.

It would be convenient if projects could always proceed according to the original plan with no changes, but unfortunately this would ignore the real point of projects. Projects don’t really exist to create the stated product, service, or result. They exist to meet business goals (by way of said product, service, or result). If something occurs and the project must change in order to meet business goals, then it should change.

So how can you as the project manager spot project changes that are good and necessary, and when is the label of “scope creep”—project change for the wrong reasons—appropriate?

You can determine which type of change you’re looking at with two simple questions.

1. Why is the change happening?

Here are some reasons a project change should happen and isn’t scope creep:

• As stated earlier, if the business needs something from the project that’s different from when the project started—either because the business changed, or its market or external environment changed.
• If the original plan for meeting product, service, or result requirements is no longer viable, or if a better (faster, cheaper, fewer resources) way to do so is discovered.
• If a new opportunity related to the project is discovered AND (see next section) the correct people approve the associated changes to seize it.

The above short list of reasons encompasses a LOT of possibilities. Maybe a world disaster happens and the needs of a large set of customers change, so businesses may adapt their projects in kind. Maybe a new tool is released that will speed up production but requires a significant reworking of the plan. Maybe a customer requests an extra feature and business leaders decide it’s worth delivering. But most good project changes will fall into one of these 3 categories.

In contrast, most genuine scope creep happens because a stakeholder sees an opportunity for a change that seems better from their viewpoint, but the change has not been vetted as a worthwhile use of business resources or approved by the correct person. Either it doesn’t meet one of the above criteria, or there hasn’t been a sufficient assessment of whether it does. Often these ideas come from someone working on the project directly, or from the client who will receive the project’s deliverables.

Ideas are great, but proper assessment is important, because many projects compete for company resources, and those resources need to go to the best places. “Just adding a feature” to one project may inadvertently steal resources from another project that was more important. Which leads to the second question…

2. How is the change happening?

How does a good, warranted, non-scope-creep change happen? The short answer is “through the proper channels.”

Some companies and projects have a clear change control process. It may be simple (ask one person) or extensive (fill out several documents for review by a change board). But if this process exists, then using it is your answer. Approved changes should be made. Unapproved (or unassessed) changes, if they were to happen, would be scope creep. Along these lines, sometimes project managers will say “change isn’t scope creep, uncontrolled change is scope creep.”

In other companies a change process is less clear, but you can still trace which person or people get final say on a project or certain parts of it. These are the people who must approve a change in order for it to move forward and become an official part of the project rather than scope creep. If you have a hard time identifying these people, I explain how to do so in my blog “5 Practical Tools for Getting Decisions Made.”

The best project changes should have favorable answers to both of the above questions. Technically all that is required is that the change is approved correctly, even if it isn’t approved for the right reasons—but you as project manager have the opportunity to advocate for reconsideration if you honestly think the change is misaligned with business interests.

So what does this mean for my scenario above? Pivoting to a more formal, extensive video production process isn’t scope creep yet because it hasn’t happened yet. It does meet the “if the original plan is no longer viable” criteria under the first question. But all the correct people—say, the person ultimately in charge of the project and the person in charge of video resource allocation—need to determine if the identified solution is the best one before moving forward.

Project changes can be (and often are) assessed with much more detail and nuance than I’ve described above, but if you keep these basic principles in mind, you’ll be able to start a productive conversation and be on your way to embracing valid project changes while avoiding scope creep.