How-To

When the brief changes mid-project (and what to do about it)

Scope change is one of those things that gets talked about like it's a failure — something that happened because someone didn't plan well enough. We've never quite seen it that way.

Scope change is one of those things that gets talked about like it's a failure — something that happened because someone didn't plan well enough. We've never quite seen it that way.

By the time a project is a few months in, the business usually knows more than it did at the start. A feature that seemed essential turns out to be less important once users start interacting with the system. Something that felt like a nice-to-have in the spec becomes critical once the team sees how the thing actually works. That's not poor planning. That's what happens when you start turning ideas into software.

The question isn't whether the brief will change. It usually does, in some way. The question is whether the project is set up to handle that without going sideways.

What we try to establish early on is a shared understanding of what change means in the context of a project. Some changes are genuinely within the spirit of the original brief — a refinement of something that was always intended, not a new ask. Others are expansions that weren't scoped, and those need to be named honestly, with a real conversation about what they mean for timeline and budget.

The spec document we produce during discovery does a lot of the work here. When something new comes up, the first question we ask is: is this in the spec? If it is, we build it. If it isn't, we have a conversation about whether it should be added, deferred, or dropped. Having that reference point removes a lot of the friction that scope changes usually create. There's no ambiguity about what was agreed.

The worst outcomes we've seen — on projects we've inherited, and occasionally on our own — happen when change gets absorbed silently. Work gets added without being documented, timelines slip without explanation, and the client ends up with a system that's partly what was agreed and partly something else, with nobody quite sure which is which.

When a brief changes, the most useful thing to do is name it and make a decision together. That conversation is almost always easier than the alternative.

Let's find where you're losing money

The discovery call is free. We'll talk about what's slowing your business down — whether that's outdated software, no visibility into your numbers, or too much manual work. Yuvati will give you an honest view of what would help, and whether we're the right fit to build it.

[email protected]
Please enter your name
Please enter a valid email address

Message sent

We'll be in touch within one business day.