Skip to content
Insights · Field notes

When scope arrives after the build has started

Mid-build scope changes are not unusual. The failure mode is not the change itself—it is handling it informally, inside an estimate that was never sized for it.

Across several engagements over the past two years, we kept encountering the same shape of problem from different directions.

On a pediatric practice build, we were mid-construction against a custom design when the agency discovered the source design was third-party-owned and not licensed for this client’s use. We pivoted to a template from the agency’s library—a reasonable solution, but one that arrived after build decisions had already been made around the original design. On an adult-dental multi-practice project, the engagement was already staged when the agency relayed a client directive: full brand replacement across every page, plus a switch in design and content reference. Not a small adjustment; a rebuild of the framing logic for the entire site. On a wellness templated build, work began before the copywriting brief existed. By the time the brief arrived, the page structure had been built against an earlier interpretation, and integrating the actual content required re-estimation and careful sequencing to avoid drift. On a separate multi-practice dental engagement, two unplanned scope bursts arrived mid-sprint, neither of which was in the original workbook.

These are different projects. The pattern is the same. The agency relays new information—sometimes from a client pivot, sometimes from a rights issue, sometimes from a delayed brief—and a build that was tracking cleanly now has to absorb work that was never priced or scoped.

The question in each case was never whether we could handle the change. We could. The question was whether handling it informally would silently expand the original estimate, put uncosted hours into the build, and surface only at invoicing as a gap between what was agreed and what was done.

That is the failure mode. Not the scope change—the informal handling of it.

The fix we landed on is discrete-ticketing discipline for any unplanned scope. Every new burst of work—a design pivot, a brand sanitisation sweep, a content restructure, an unplanned scope expansion—gets its own Redmine ticket before a single hour goes into it. The ticket carries its own estimate, scoped at the same row-level discipline as the original workbook. It runs through its own QA stream. It is not absorbed into the open build.

This does three things. It protects the original estimate from being quietly consumed by new work—the invoice at the end of the engagement reflects what was agreed, plus clearly labelled additions. It protects shared template components and build decisions from the pressure of a rushed addition that has to be integrated without destabilising what is already staged. And it gives the agency a clean record of what was additionally scoped and why, which is useful both for internal reporting and for the conversation with their own client about cost.

The agencies we work with closely have come to expect this response when a mid-build change arrives: a short hold, a new ticket, an estimate, approval, then work starts. It adds a step. It also means the engagement never ends with a cost surprise that nobody can explain.

A scope change handled as a discrete ticket is just another build phase. The same one handled informally is a problem that compounds quietly until it isn’t quiet anymore.

— Working on something similar?

If any of the above sounds familiar, we should talk.

Scroll to Top