Reduce Scope Creep with This One Question

Scope creep is inevitable in software projects. But that doesn’t mean that all scope creep is inevitable. When a client asks you for functionality that wasn’t in the original spec, why are they asking for changes? There can be several causes.

Some Preventable Causes of Scope Creep

• A competitor added a feature, and the project owner wants to match or exceed them before launching.
• Your client had a new idea or a new way to implement an existing feature.
• You have to make the app “better” before you launch.

When you hear these, you know that scope creep is happening, which means more hours for you, and a later delivery time for you client. If you’re billing hourly, that means the price is going up. If you are charging by the project, that means you’re eating the cost, making trade-offs with existing work in the backlog, or sending your client a change request, and the price is going up.

This process isn’t fun for anyone involved. Any steps you can take to reduce the chances of this happening would be a win for both of you.

Planning & Estimating Help, But They’re Time Consuming

You could write up a detailed project plan, which would involve spending a lot of unpaid time upfront. And even then, will that prevent the previous problems?

• It doesn’t stop your client desiring mimicry and calling it a competitive advantage.
• It doesn’t prevent your client from having new ideas.
• It doesn’t prevent the launch anxiety that causes last minute feature requests.

What if there was a quicker way to nip these problems in the bud?

Here’s The One-Minute Fix:

“What would make this project a home run for you?”

Adding this question to your client discovery process is a huge ROI. It doesn’t fix the problem 100% of the time, but it does get you a lot of project stability for a small time investment. There is one more caveat:

You Need The Right Kind of Answer

Let’s say the client responds with:

“We want to be the best in the market!”

That’s a start, but it’s not an achievable goal. We need to refine our Home Run Statement.

The Target Must Be Measurable

At any point after the project is complete, you need to ask yourself “Did we hit a home run?” and be able to answer with a definitive yes or no. There must be a metric that you can identify. “Best in the market” could mean “most downloads in our category in the app store.”

And don’t let the term metric lead you to believe this needs to be a sophisticated analytics answer. Your goal could be that the number of approvals you get from management equals one. What’s important is that you pick some finite, discrete way of identifying success.

So “most downloads in the app store.” is a great Home Run Statement, right?

Wrong.

The Target Must Be Under Your Control

You could build the best application in the world, and run the best marketing campaign in the world, and still not reach #1 in your market. You can’t make people buy your product, subscribe to your newsletter, or sign up for your course.

What if you build a great product, and Google puts out a free competitor the next day? Or Twitter buys your competitor and throws all of their weight behind them and not you?

It happens. When you pick your metric, you need to make sure you’re picking the right metric.

Choose a leader, not a Lagger

Set your metric to a number you can control. There are two types of metrics: leading indicators and lagging indicators. The key difference: leaders are controllable and happen before success. Laggers are evidence of success after the fact and are outside of your direct control.

Laggers are dangerous because they tend to be the sexier number that people brag about on Hacker News.

Example: A Simple Contract Strategy

Your content strategy is to publish a blog article every week with a call-to-action, the goal being to build your email list. What’s the leading indicator here, and what’s the lagging indicator?

• Lagging indicator: number of email subscribers.
• Leading indicator: number of posts published.

You can’t make people sign up for a mailing list, but no one can stop you from shipping content consistently.

After some discussion, you should have a solid Home Run Statement: A measurable, achievable goal for the project.

So How Does This Prevent Scope Creep?

When you don’t put down clear goal posts, there is nothing to stop them from changing. They’ll move on the opinions of people involved in the project from day to day. This swaying in the wind is particularly insidious because it looks and feels productive while killing your project from the inside.

The Home Run Statement is a gatekeeper that stops adverse, unneeded change within the project.

• Competitor add a new feature? If matching them isn’t going to help us reach the goal, then we can address it post-launch.
• Have a new idea? If it doesn’t fit into the current plan, then it can wait.
• If you have a launch date you want to hit, then you want to cut to ship, not add more features and delay.

I’m not endorsing waterfall or being completely resistant to change. I want you to be smart about change. Be strategic and deliberate, not impulsive and rash. The first question breeds the second:

Does the change help us move closer to our goal?

If yes, then go for it. You can feel confident that you’re making a smart call.

Having a clear target you can hit, with the discipline not to get distracted by shiny things on the way there, is a rare and immensely valuable skill. That’s how you get ahead of the competition and launch quality projects.