Impact Assessment Checkpoint¶
Evaluation procedure — instantiates Scope Creep Containment
A required analysis step that, before any change is decided, traces its full downstream cost — capacity, dependencies, hidden follow-on work — and measures how far it moves scope from the original charter.
An Impact Assessment Checkpoint is the mandatory analysis a proposed change must pass through before anyone is allowed to decide on it — the step that turns a request's cheerful headline ("just add a column") into its true, traced-out cost. Its defining move is to surface the iceberg beneath the ask: the capacity it consumes, the dependencies it disturbs, the verification and support burden it drags along, and how far accepting it would push the work away from what was originally chartered. It renders a verdict on magnitude, never on whether to proceed. The checkpoint exists precisely because scope creep runs on locally-cheap-looking additions whose real cost is downstream and invisible at the moment of the ask; the assessment makes that cost visible in time to be weighed.
Example¶
A university lab has a funded study with a pre-registered design: one primary hypothesis, a fixed sample of 240 participants, one analysis plan. Six weeks in, a co-investigator proposes adding a secondary measure — "while participants are already here, let's also collect a short cognitive battery." It sounds free. The lab has adopted an Impact Assessment Checkpoint: no addition to the protocol reaches the PI's decision until its impact sheet is filled.
The assessment traces the ripple. The battery adds twelve minutes per session, which pushes total session time past the ethics-approved limit — triggering an IRB amendment (a dependency), a re-consent (more follow-on work), and a longer session that raises dropout risk (a capacity-and-quality hit). It also introduces a second outcome family, which the checkpoint flags against the original charter: the study was designed and powered for one primary question, and adding an inferential secondary measure moves it materially toward a different, larger study. The checkpoint's output is not "no" — it is a one-page impact sheet: "adds ~4 weeks, requires IRB amendment, moves the design outside its pre-registered scope." With that in hand, the decision is easy and honest, and it is made by someone else.
How it works¶
What distinguishes the checkpoint from a casual "sounds fine" is that it is a procedure with required outputs, run before the decision:
- Trace, don't estimate. It follows the change outward through dependencies — what else has to move, break, or be re-tested — rather than pricing only the visible task. Second-order work is the whole point.
- Measure drift from the charter, not the backlog. It reports how far the accumulated scope would sit from the original perimeter if this were accepted, so the comparison point can't quietly reset to the already-expanded present.
- Produce a standard artifact. Every assessment yields the same shape — capacity delta, dependency map, follow-on work, distance-from-charter — so decisions rest on comparable evidence.
- Stop before the verdict. The checkpoint hands its findings to whoever holds admission authority and stops there; mixing analysis with decision is how impact assessments get bent to justify a foregone yes.
Tuning parameters¶
- Assessment depth — a quick triage sheet versus a full dependency trace. Deeper analysis catches more hidden work but costs time on every request, so most programs tier it by change size.
- Ripple horizon — how many dependency hops out the trace follows. A short horizon is fast but misses second-order breakage; a long one can chase the whole system.
- Charter-distance metric — which dimensions "distance from original scope" is measured on (deliverables, effort, stakeholders, verification burden) and how coarse the reading is.
- Trigger threshold — which changes must pass the checkpoint at all; set it too high and small-but-entangled changes skip assessment.
- Confidence tagging — whether each estimate carries an uncertainty band, so a shaky number isn't treated as fact downstream.
When it helps, and when it misleads¶
Its strength is that it forces the hidden cost of an addition into the open before commitment, and it keeps the measuring stick planted on the original charter — the two things a naïve "is this a big change?" conversation never does. It is the analytical counterpart to any dependency- or ripple-effect analysis in change management.[n1]
Its failure mode is analysis captured by its consumer: an assessment written to reach a conclusion the requester already wants, with rosy capacity numbers and a truncated dependency trace, so the sheet launders a bad addition as a studied one. It can also curdle into bureaucratic drag if every trivial change demands a full trace. The guarding discipline is to keep the assessor's incentives separate from the decision and to tier the depth to the change — the checkpoint is only useful if its numbers are honest and it stays out of the verdict.
How it implements the components¶
capacity_and_dependency_impact_model— its core output: the traced model of what the change consumes and what it disturbs, including hidden follow-on work.original_vs_current_scope_comparison— it quantifies how far accepting the change would move the total scope from the chartered baseline, keeping the anti-amnesia comparison alive.
The checkpoint informs the decision but never renders it: it does not apply the scope_addition_admission_rule (that verdict is the Change Control Board's) and it does not choose the offsetting cut — the subtraction_or_tradeoff_path is worked in the Plus/Minus Scope Review.
Related¶
- Instantiates: Scope Creep Containment — the checkpoint supplies the true-cost evidence that scope decisions depend on.
- Sibling mechanisms: Change Control Board (consumes this checkpoint's findings) · Plus/Minus Scope Review · Scope Change Request Template · Scope Drift Dashboard · Requirements Traceability Matrix
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Impact Assessment Checkpoint operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a required analysis step that, before any change is decided, traces its full downstream cost — capacity, dependencies, hidden follow-on work — and measures how far it moves scope from the original charter
Independent corroboration: The frozen evidence defines Impact Assessment Checkpoint as 'A required analysis step that, before any change is decided, traces its full downstream cost — capacity, dependencies, hidden follow-on work — and measures how far it moves scope from the original charter', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: A mandatory gate checking downstream work and charter drift is a project and change-management control.
Related originating lineages:
- Computer Science & Software Engineering — Software change-impact analysis materially supplies dependency tracing and ripple-effect checks.
- Engineering & Design — Design reviews and configuration-control gates provide an independent engineered-change lineage.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Independent reviewer agreement; medium confidence.
Notes¶
The checkpoint is diagnostic; the Change Control Board is decisive. The single most common way to hollow out a change process is to let the same person who wants the change also write its impact assessment and cast the deciding vote — collapsing analysis and decision into one seat is exactly what this mechanism, kept separate from the board, is designed to prevent.
[n1] Impact analysis (change management / software engineering) — the practice of identifying, before a change is made, the set of artifacts, components, and downstream work a change will affect, so the "ripple effect" of a modification is understood rather than discovered after the fact. The checkpoint institutionalizes it as a gate every scope change must clear. ↩