Scope Creep Kill Switch
I drafted this last week. Haven't used it in anger yet — but the need showed up twice this month, which is usually when I start writing things down.
The plan is to run it on the next project where something tries to sneak into the brief mid-build. I'll update this post with what held up, what didn't, and what I'd change.
For now, here's the logic.
The problem with scope creep
Scope creep doesn't announce itself. It arrives as a reasonable question — "while we're in there, could we also..." — and by the time you realise the project has doubled in size, it's too late to say no cleanly. You're already committed.
The reason it's hard to stop isn't that people are careless. It's that most additions look legitimate in the moment. The problem is that they're being evaluated one at a time, without accounting for their combined weight on delivery, complexity, and the original reason the project exists.
This workflow is a gate, not a veto. The goal isn't to refuse everything. It's to force a deliberate decision instead of a passive one.
Phase 1: Spot the signal
Not every new idea mid-build is scope creep. The first step is recognising when something is actually trying to expand the brief.
Signals that something is creeping in:
- A requirement surfaces that wasn't in the original brief and wasn't a known unknown
- An existing feature starts growing ("while we're at it, let's make this more flexible")
- A stakeholder sees the work-in-progress and has new ideas
- Something that was out of scope gets quietly added to the task list
- The definition of "done" starts shifting
Signals that something is fine:
- It was always implied and just not written down
- It's a bug fix, not a feature
- It reduces scope rather than adding to it
- It was explicitly included in the brief under a different name
If it's not clearly one of the above, treat it as a candidate for the gate.
Phase 2: Name what it is
Before deciding anything, name the type of addition you're dealing with. There are three:
Type A — Aligned addition. It fits the original objective, doesn't change what "done" looks like, and the effort is small. These usually get absorbed. The risk is that ten Type A additions add up to a Type C.
Type B — Scope drift. It changes a component or feature beyond what was originally planned, but the core delivery stays intact. These get deferred unless there's a hard reason to include them now.
Type C — Project killer. It changes what the project fundamentally is, shifts the delivery timeline, or introduces a dependency that wasn't accounted for. These get killed, logged, and revisited in a separate brief.
The naming step matters because it forces you to articulate what you're actually looking at before you run it through the gate.
Phase 3: The 3-question gate
Every candidate goes through three questions. They need to pass all three to stay in scope.
1. Does it change what "done" looks like?
If yes, it requires a formal scope change — sign-off, timeline review, resource reallocation. You can't silently expand the finish line. If no one has authorised that change, the answer is no.
2. Who raised it — and does that person own the outcome?
An addition raised by the person accountable for delivery carries more weight than one raised by someone observing the work. Observation generates ideas. Accountability generates requirements. They're not the same thing.
3. Does it block something that's already working?
If absorbing the addition requires touching something stable, you're introducing regression risk for an unplanned feature. That's almost never worth it mid-build.
If it fails any of these, it goes to the kill switch.
Phase 4: Pull the kill switch
Killing a scope item isn't the end of the idea — it's the end of this idea in this project. The distinction matters, because the fastest way to get scope creep resistance rejected is to treat it like a permanent veto.
The three outcomes:
Absorb. It passed the gate. It's small, aligned, and doesn't change the delivery. Add it to the task list with a note that it was formally reviewed and included.
Defer. It's a real idea but not for this project. Add it to a backlog with a description, the context it came from, and why it was deferred rather than killed. This is where Type B additions land.
Kill and log. It's out. But it needs to be logged, not just dropped. Record what it was, who raised it, why it was cut, and where to find it if it becomes relevant later. This is the step most people skip, and it's the reason the same additions keep resurfacing.
The kill log is the difference between a decision and a dismissal. People accept decisions. They resent dismissals.
Phase 5: Lock and communicate
Once the gate decision is made, it needs to be communicated — not to get approval, but to close the loop. Whoever raised the addition should know the outcome and the reason. If they don't, the idea will come back.
What to communicate:
- What the addition was
- Which outcome it got (absorbed / deferred / killed)
- Why — one sentence
- If deferred or killed: where it went and how it can be revisited
This doesn't need to be a meeting. A short written note works. The goal is that no one feels like their idea disappeared into a black hole, even if the answer was no.
The short version
- Something new surfaces mid-build. Before doing anything, recognise what kind of signal it is.
- Name the type: aligned addition, scope drift, or project killer.
- Run it through the 3-question gate. It needs to pass all three.
- Pull the switch: absorb, defer, or kill. Log every outcome.
- Communicate the decision to whoever raised it. One sentence, one time.
What I'm testing this on
I'm running this against the next thing that tries to expand mid-build — most likely something on this site, which has a habit of accumulating ideas between commits.
The parts I'm least sure about: the naming taxonomy (three types might collapse into two in practice), and whether the kill log format I'm using is granular enough to be useful later or just ceremonial. I'll know more after one real cycle.
I'll update this when I have results.