Scope Change Request Template¶
Template — instantiates Scope Creep Containment
A standard intake form that makes a scope change unmentionable until its requester has stated fit, value, cost, owner, and what it displaces — turning casual asks into structured, logged records with the admission questions built in.
A Scope Change Request Template is the standard form every proposed change must be written onto before it can be considered — and the friction of filling it is a feature, not a bug. Its defining move is to make an addition expensive to propose casually: the requester, not the delivery team, must state up front what the change is, why it fits (or doesn't) the charter, what value it adds, what it will cost, who will own it, how reversible it is, and what would be removed or deferred to make room. By encoding the admission questions as required fields, the template turns "hey, can we also…" into a structured artifact that self-documents into a ledger entry. It captures and structures; it does not decide and it does not compute cost — its power is that a change nobody will write down is a change that never enters, and a change that is written down becomes a permanent, comparable record.
Example¶
A design agency is redoing a client's e-commerce site on a fixed statement of work. Clients being clients, the change requests come by email, hallway, and Slack: "can the hero video autoplay?", "add a store locator", "make the checkout match our new brand deck". In the agency's old habit, junior designers absorbed the small ones and only the big fights reached the account lead — and the project bled margin.
The agency institutes a Scope Change Request Template. Now any change, from anyone, has to arrive on the form: description, in-scope per SOW? (y/n), business value, estimated effort, who owns follow-up, what we'd deprioritize to fit it, does this need a contract amendment? The store-locator request, once written out, obviously needs a new integration and a contract amendment — the client, seeing the form, decides it can wait. The autoplay tweak is trivial and gets logged and done. The brand-deck restyle, filled in honestly, reveals it touches every template in the build; it goes to a change order. Each submitted form drops into a running change log, so three months later the agency can show the client exactly which requests were made, accepted, or deferred, and why. The form did most of the containing before anyone even weighed the merits.
How it works¶
What distinguishes the template from a blank feature request is that its required fields are the admission gate, and its submissions are the record:
- Mandatory fields encode the rule. Fit-to-charter, value, cost, owner, reversibility, and displacement are not optional prompts — an incomplete form is not a valid request, so the admission questions get answered by construction.
- The requester does the work. By putting the burden of justification on whoever wants the change, the template raises the cost of frivolous asks and lowers the load on the delivery team.
- Submission is logging. Every completed form becomes a durable entry in the scope change record — accepted, rejected, or deferred — so the ledger populates itself as a side effect of intake.
- It captures, it doesn't judge. The form organizes a request for decision; the yes/no is rendered elsewhere.
Tuning parameters¶
- Field rigor — how many questions are required and how detailed. More fields catch more hidden implications but raise friction; too many and people route around the form entirely.
- Friction level — deliberately how hard the form is to file. High friction suppresses casual creep but can also suppress legitimate fast-moving changes; low friction keeps flow but weakens the filter.
- Auto-logging — whether submissions flow straight into the change ledger or are transcribed by hand. Automatic logging keeps the record complete; manual invites gaps.
- Waiver path — whether tiny changes get a lightweight lane. A good waiver keeps the form from being bureaucratic overkill, but a loose one becomes the leak.
When it helps, and when it misleads¶
Its strength is prevention by friction and self-documentation: it stops the smallest, most insidious additions — the ones too minor to convene anyone over — simply by requiring them to be written down, and it leaves a complete record, in the spirit of the formal change request that ITIL and project-management practice place at the front of any change process.[n1] The very act of filling it often kills a bad idea before a decision is needed.
Its failure mode is checkbox theater: a form filled in with hollow answers ("value: high; cost: low; displaces: nothing") that satisfies the ritual while hiding the truth, so the template documents creep rather than deterring it. It can also breed a shadow channel — if the form is too heavy, changes migrate back to Slack and the record goes blind. The guarding discipline is to keep the fields honest and load-bearing and the friction proportional: the template contains scope only if a false answer is caught downstream and a true one is cheap enough that people actually use the form.
How it implements the components¶
scope_change_ledger— each submitted form is a durable record of a requested change, so the ledger of additions, rejections, and deferrals accretes automatically from intake.scope_addition_admission_rule— the template's required fields are the admission questions (fit, value, cost, owner, reversibility, displacement) made mandatory at the door.
The form captures the request; it doesn't rule on it or price it: it does not render the verdict — that is the Change Control Board's application of the rule — and it does not compute the capacity_and_dependency_impact_model (the Impact Assessment Checkpoint) or choose the offsetting subtraction_or_tradeoff_path (the Plus/Minus Scope Review); it only asks the requester to name them.
Related¶
- Instantiates: Scope Creep Containment — the template is the front door that turns casual asks into structured, logged requests.
- Sibling mechanisms: Change Control Board (decides on the forms this template produces) · Impact Assessment Checkpoint · Deferred Scope Parking Lot · Rebaseline Workshop · Scope Drift Dashboard
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Scope Change Request Template operates by imposes mandatory admission fields and evidence requirements on every future scope-change request. That concrete deployed or enacted form is Rule, Policy & Commitment under the frozen taxonomy.
Nearest alternative: Interface, Display & Cue — Although Interface, Display & Cue can support this mechanism, the frozen evidence makes its operative form the act that imposes mandatory admission fields and evidence requirements on every future scope-change request; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Formal intake requiring value, cost, ownership, and displacement is project change control.
Related originating lineages:
- Accounting & Auditing — Logged approval records materially support governance and auditability.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: a standard intake form that makes a scope change unmentionable until its requester has stated fit, value, cost, owner, and what it displaces — turning casual asks into structured,….
Review resolution: Both blind reviewers agree that organizational_management is the primary historical origin. Explicit reconciliation of alternate_origin_disagreement starts from reviewer_a's mechanism-specific evidence: Formal intake requiring value, cost, ownership, and displacement is project change control. Reviewer A proposed alternates=accounting_auditing, origin_mode=single_lineage, domain_reach=multi_domain, and encyclopedia_synthesis=false; reviewer B proposed alternates=systems_cybernetics, origin_mode=single_lineage, domain_reach=multi_domain, and encyclopedia_synthesis=false. The final record retains every independently supported alternate from either review (accounting_auditing, systems_cybernetics) without an arbitrary cap, selects origin_mode=single_lineage to represent the combined lineage evidence, and records domain_reach=multi_domain and encyclopedia_synthesis=false. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The template and the Change Control Board both carry the admission rule, but from opposite ends: the template encodes the questions as fields a requester must answer, while the board renders the judgment on the answers. The template also feeds the same change ledger the Rebaseline Workshop later archives — the template writes the entries as they arrive; the workshop preserves the whole trajectory at a reset.
[n1] Change request (ITIL / project management) — the standardized record used to formally propose, document, and route a change through an approval process, capturing its rationale, impact, and disposition so that changes are traceable rather than ad hoc. The template is that record made the mandatory point of entry for scope changes specifically. ↩