Don’t Be a Creep: What Is Scope Creep & How to Address It

‘Scope creep’ is a term that describes how a project’s goals and requirements (its ‘scope’) can begin to ‘creep’ past the allocated time and budget. This happens, typically, when features or deliverables start to be specified/demanded after an agreed project timeframe has already been agreed.

But that’s not the only way scope creep can happen. As the ‘creep’ implies, it’s a thing that can slowly creep its way into any project at almost any stage. Even at the beginning, before work commences, new feature requests or last-minute ‘we need X’ can force you to rapidly reconfigure your initial project’s scope - affecting timeframes and budget.

For an issue that impacts both agencies and clients, cutting down on scope creep is fortunately mutually beneficial. For a client, it saves them time and money. For us, the agency, it minimises frustration and leads to a more complete product.

How to address scope creep

Scope creep means your product team, whether in-house or an agency, must allocate time/resources to implement features or changes you have not accounted for in the initial brief. The only way they can accomplish this is to spend less time elsewhere, leading to bugs and poor performance, or charging more money to fit in the additional work. So essentially, scope creep either means you’re losing either time or money on your project.

It also means that the end-product won’t match the original brief in terms of budget, timeframe or features. When scope creep is not addressed, what is delivered might have the new ‘creep’ features but be missing the fundamental aspects of the product. For example, you might launch your new property app with an exciting new AR-viewing feature, but if the enquiry forms are broken, you’ve let scope creep derail its effectiveness.

Addressing scope creep is not always simple, but it is theoretically a case of understanding what scope creep is, how it is caused and how you can manage those causes.

What causes scope creep?

Sadly, this answer is often down to you.

No, not you specifically, but it’s often those who work in-house in any kind of supervisory/ownership role who unintentionally cause scope creep. Some of the most common reasons are:

Lack of clarity over the initial scope

A project must begin with a clear understanding of what its requirements are. Sadly, people commonly mistake what this means. You don’t need every single possible detail and feature agreed from the get-go. Instead, you need a solid idea of the functionality required to make your digital project meet your user’s needs.

The first stage of any project should therefore involve mapping our user’s needs against features and functionality. This must include someone working on the project from a technical element to help with time/cost estimates.

If you’re in-house working with an agency, it should include both sides of the project. Here at KOMODO, our workshop session helps CTOs and potential product owners understand what their users need and plan a project that delivers the core functionality required in the right time frame.

How to create clarity

Mapping out an ‘MVP’ or minimum viable product is key to your success here. The MVP should have an agreed list of the minimum features a product needs to work for its intended audience. By establishing this, you can avoid scope creep early on because you’ll have clear visibility over what the team will work on and what features must wait until further development cycles. We use the MoSCoW prioritisation technique at KOMODO to help truly understand these needs and requirements.

Still, that doesn’t help with…

Stakeholders and third party demand

Those not directly working on a project are less likely to understand scope creep. Instead, they’ll have their own views about what should or should not be included in the product and will have little real-world understanding or empathy for the challenges these requests cause.

To remedy this, you need your stakeholders or upper management to understand exactly what your project’s timeline looks like and why it has been planned that way. This can mean briefing them afterwards or even having them involved at the workshop stage.

Bring key stakeholders into the fold

Get one of these senior members into the initial discovery workshop, or at least show them any presentations or plans you have BEFORE the project commences. Make it clear that each ‘cycle’ will be fixed and cannot be changed - perhaps even agree on a sign-off process at the beginning of each development phase so the stakeholders know they have agreed to X functions/features and won’t be able to request more this time around.

Delivery team challenges

Project teams are, after all, composed of people. People have personalities, and unfortunately, that can change how your project is delivered. This can take a few different forms:

1. A lack of clarity or understanding between your goals and what the project team thinks it needs to create can cause issues to crop up. If the development team, for example, doesn’t know about a certain checkout function you wanted but haven’t made clear, they can’t account for the time it will take, which will inevitably lead to delays.

2. ‘Vacuum’ development - if you’re a small in-house team, you need to be sure that your agency and your team members are working together in a collaborative way that doesn’t cause conflict. Suppose your own in-house development professional changes something without telling the agency or the other way around. In that case, there could be issues created by releasing parts of the product on outdated code, leading to time-consuming remedial fixes and update work.

3. Design and development should be integrated from the beginning and agree on the output together. What development might consider a smaller task could be a large one for a UX designer and vice-versa.

How to overcome delivery challenges

Whether you’re working solely in-house or with an agency, try to adopt a more collaborative and clear approach. All teams involved in the project should be aware of requirements from the initial brief and have been given a chance to offer feedback and help shape the ‘MVP’ we mentioned earlier.

Lack of project management function

Hey, we’re all about good communication. Who isn’t? But as a seasoned software agency, we know what happens if we allow for a completely unmanaged flow of communication between our delivery team and our clients.

While it might seem ideal to you that you could just immediately get in touch with the developer working on your product, it can only ever lead to scope creep. Unmanaged contact usually leads to new feature mentions, a lack of clarity and overall miscommunication, which all spell disaster for the project’s timeframe.

In what might sound like a confusing yet simple statement, learning how to avoid scope creep in project management is about respecting the importance of a good project manager.

How to stop confusing communication

Thankfully this is an easy fix. Ensure there’s a project manager agency-side and appoint someone in your own team to manage the relationship. Product owners are typically this middle-ground who can help manage agency output against in-house expectations.

Inevitable creep

Sadly, despite all of this being addressed and your best intentions from the get-go, it’s almost inevitable that SOME scope creep will occur. Even the most watertight projects can see new things slip into their development cycle. Whether that’s as a reaction to a platform update such as an Android OS change forcing your product to adapt, or something more innocent, such as a wrong estimate from your UX designer.

How to stop inevitable creep

You can’t. But you can mitigate it by planning in contingency time. As long as the bare MVP is fully identified and worked to, you’ll be able to plan for some additional time to address issues, fixes or small updates during the project.

Solving scope creep won’t solve everything

As we’ve mentioned a few times, some of the changes you have to make in a digital project’s life cycle include reactions to updates and bug fixes. None of these things are technically ‘scope creep’ as they aren’t adding to the original scope, just impacting its time frame.

Solving scope creep alone doesn’t prevent a project from experiencing time and budget-related challenges. What it DOES do, however, is limit the amount of additional cost you’ll need to spend for your project to go ‘live’.

By planning a timeline to launch your minimum viable product, getting stakeholders to ‘buy-in’ to this plan and getting the delivery team’s input, your project can minimise the risk of scope creep and stick to the budget.

So, for a quick recap, let’s do one last run-through of how to avoid scope creep:

1. Collect user requirements and needs as initial research for the project.

2. Make the scope of the project clear by creating it with user needs, delivery team insight and feasible timing in mind.

3. Involve your agency or your client directly in the scoping process. Each needs to be happy with the other’s ideas.

4. Create contingency time for bug fixes, QA suggestions etc.

5. Work through a central pillar of communication, whether you as a product owner or through a project manager.