It would be great if the problem always showed up as “scope giant leap,” wouldn’t it? You were planning to introduce one new feature for the next major release, but suddenly, somehow, your team finds itself working on seven features all at once—all while under the pressure of meeting the original release date. How did this happen? Simple: The process suffered a little bit of scope giant leap. Solution? That’s also simple: “Let’s just stop working on those extra six features that weren’t part of our original plan.”
But it never happens that way. That’s why it’s called scope creep. Just one little extra bit of work here, a tiny new commitment there, an innocent promise to add a few more whatchamacallits to that part of the product… and suddenly you’re short on resources, your development team is exhausted, and you’re in danger of missing an important deadline.
How can you keep this from happening? How can you prevent these little steps in the wrong direction, these seemingly innocent additional requests and promises, from adding up to a situation that overwhelms your team and slows your product’s progress?
Here are five ideas for combating scope creep. (And make no mistake: It is combat, because you’ll be fighting off these requests from everywhere, all the time.)
5 Ideas for Combating Scope Creep
1. Share your product roadmap (early, frequently, and with everyone involved).
If you build it correctly, your product roadmap will reflect both your strategic blueprint for the product and the realities your team will be working with in terms of resource, budget, and time constraints.
When everyone on your cross-functional team can see this high-level view of your product’s plans, priorities, and the strategic thinking behind it all, they will be more likely to understand how a request for what might seem to be a small additional bit of functionality will, in reality, have to disrupt some other part of the product’s progress.
So the more often you refer to and share your product roadmap with your organization, the clearer it will be to everyone that your finite resources for this project can’t afford scope creep.
2. Determine exactly what will constitute scope creep on your plan.
There are the obvious, easy-to-spot types of scope creep. One idea leads to another, and another, and another. You can’t do them all, not in the time you have or with the number of coders on your team. That’s scope creep everyone understands (even though some people will still try to persuade you to engage in it.)
But then there are subtler forms of scope creep. For example, “I know we agreed on doing basic platform support for our app’s first release—just to let users access it with iOS or Android—but maybe we should go for optimum support, and include Windows phones, a desktop version, etc.”
That’s scope creep, too, and it can be an enormous time and resource drain—even though it can sound like just a more robust version of your original plan.
One of the sneakiest ways that scope creep can slip into your product development process is when it comes disguised as something else, like improving or “fleshing out” something you had already agreed upon.
So you’ve got to define for your team exactly what every step of your plan includes. Anything outside or in addition to that original plan? You can treat it as a change request and review it. But unless and until you give it the green light, it’s scope creep.
3. Build “scope monitoring” into your routine.
One of the easiest ways to fall victim to scope creep is by losing sight of your original strategic plan and the priorities you’ve set for your product. When that happens, and someone comes along and says, “Hey, maybe we could tell the developers to go for optimum platform support instead of our original basic plan,” you’re vulnerable to saying, “Sure. Why not?”
So refer regularly to your strategic plan. Pop open your product roadmap often and share it with your team, so you can all stay connected to your original strategic thinking and regularly review that thinking against the day-to-day work you’re all engaged in. If that work is moving the plan you all agreed on down the field, great. If it’s not, you could be suffering scope creep.
4. Discourage your developers from over-delivering.
We know: This sounds awful. But as a product manager, one thing you should always remember is that your developers will often care deeply about the work they’re doing and will want it to be perfect. And in an ideal world—a world without budgets, or deadlines, or customers eagerly waiting for a finished product they can buy—you’d want your dev team building to perfection.
Unfortunately, though, you are always going to be working against the clock (and the accounting team), so you’ll need your developers to stop short of perfection and do the greatest work they can in the time they have allotted to them.
As difficult as it might sound, in some cases, your product will need to be only as good as your team can make it before launch. And if they want to make it better than that, well, that’s scope creep, too.
5. Make it easy to suggest and track great ideas for later.
One final suggestion for avoiding scope creep is to encourage your cross-functional team to contribute their product ideas and requests, and to make it as easy as you can for them to do so.
Then make a practice of periodically reviewing these ideas with your team, vetting and scoring them according to your key metrics, and, when it makes sense, updating your product roadmap to accommodate strategically viable items.
When you communicate to your executive stakeholders and the other teams across your company that you are open to product suggestions, but that those suggestions will have to wait their turn to get their fair hearings, you will be reinforcing to everyone in the organization your commitment to adhering to the scope of your product’s existing plan.
And that simple statement, along with the other tips here, can help you grow a company culture that understands the dangers of scope creep and actively discourages everyone from engaging in it.
