Skip to content

Scope Change Ticket

Change-control protocol — instantiates Sufficiency-Bounded Work Containment

Routes every proposed addition to an agreed scope through a filed, logged ticket that must be justified and approved before work starts — so the default answer to 'while we're at it…' is no.

Scope rarely balloons in a single decision; it grows through a hundred small "while we're in here…" additions, each individually reasonable and collectively fatal to the boundary. The Scope Change Ticket interrupts that by forcing every proposed addition to an agreed scope through a filed ticket — what's being added, why, what it costs, and what it displaces — which is then approved or declined by someone with the authority to say no. Its defining move is flipping the default from yes to no: absent a ticket, the addition simply does not happen, and every one that does is recorded. It converts silent, cumulative scope creep into a series of visible, owned, individually-justified decisions — and the running ledger of tickets becomes the standing evidence of how far scope has drifted and why.

Example

An agency is building a marketing site against a fixed statement of work. Mid-project, the client's requests start arriving by chat: "can we also add a blog?", "while you're at it, make the header sticky," "small thing — multilingual support." Each sounds minor; together they would nearly double the build. The agency routes all of them through scope change tickets. Each request becomes a ticket noting the added effort, the impact on the launch date, and the cost, which the account lead — who holds the authority to decline — resolves with the client. The blog is approved as a paid addition with a moved date; the sticky header is folded in as trivial; multilingual support is declined into a phase two. Nothing is silently absorbed, and at hand-off the ticket log shows precisely where the extra weeks went — a record no one could have reconstructed from memory.

How it works

  • No ticket, no change — additions to agreed scope do not proceed until filed; an un-filed "while we're at it" is simply out of scope.
  • Each ticket carries its cost and its displacement — not just what to add, but what it delays or pushes out, so the trade-off is on the table.
  • An authority decides, not the requester — approval sits with someone empowered to hold the line, separating "I'd like this" from "this is approved."
  • Every ticket is logged, approved or not — the ledger accumulates into a visible record of drift and the rationale behind each accepted and rejected change.

Tuning parameters

  • Ticket threshold — how large a change must be to trip the gate; too low and trivial tweaks drown in process, too high and creep slips under the bar.
  • Approver level — who holds the authority to say yes; higher-level approval resists pressure better but slows the response.
  • Default disposition — whether an un-actioned ticket defaults to declined or merely deferred; a decline-default contains harder.
  • Displacement rigor — how precisely each ticket must quantify what it pushes out; more rigor deters frivolous asks but raises the filing cost.
  • Review cadence — whether changes are resolved continuously or batched into periodic scope reviews; batching resists piecemeal pressure but delays legitimate additions.

When it helps, and when it misleads

Its strength is that it is the sufficiency-oriented specialization of formal change control:[1] it stops death-by-a-thousand-additions, assigns ownership to each expansion, and leaves an audit trail of where scope actually went. Its counter-pressure is structural rather than personal — the requester meets a process, not an individual's mood.

It misleads when the gate approves everything: rubber-stamping re-imports the very creep it exists to stop. Set too aggressively, it becomes friction people route around, and "shadow scope" grows outside the ledger. The classic misuse is running it backward — filing tickets to document changes already made rather than to decide them. The discipline is to keep the approver genuinely willing to decline, tune the threshold so it catches real additions without taxing trivia, and require the ticket before the work, never as after-the-fact paperwork.

How it implements the components

  • expansion_request_gate — it is the gate: every scope addition must pass through a filed, approved ticket before any work begins.
  • scope_drift_log — the accumulating ticket ledger is the drift log, recording each accepted and rejected change and its rationale.
  • counter_pressure_authority — approval is vested in a role empowered to decline, institutionalizing push-back against expansion so it doesn't rest on an individual's nerve in the moment.

It gates additions arriving from outside; it does not time the team's own deferrable decisions (finish_line_recalibration_loop, Last Responsible Moment Review), nor cap the effort a single accepted task may consume (resource_container_statement, Timebox with Early-Exit Rule).

Notes

The log is often the ticket's most valuable output. Even changes that would have been approved anyway become reconstructable after the fact, so a program can see how much of its overrun was deliberate scope and how much was drift — a distinction that is invisible without the ledger.

References

[1] Change control — the standard project-management practice of routing changes to an agreed baseline through a formal request-and-approval process, often via a change-control board. The Scope Change Ticket is its sufficiency-oriented specialization: the default disposition is decline, not approve. ↩