Implementation Readiness Review¶
Test or assessment — instantiates Implementation Feasibility Alignment
Reviews whether people, resources, workflows, authority, support, and risk controls are ready enough to proceed.
An Implementation Readiness Review is the integrative go / hold / de-scope gate held just before commitment. It aggregates the readiness of the whole operating system — are the people trained and certified, is the support layer staffed, are contingency controls defined, are resources in place — grades each dimension against a "ready enough" bar, and issues a decision: proceed, hold until a gap closes, or de-scope so the roll fits what is actually ready. It is a review of evidence, drawing on capacity maps, pilot results, and readiness signals rather than generating new field data itself. Its defining move is that it must end in a proceed decision with teeth — every red or yellow dimension has to trigger a hold or a de-scope, never a note filed and forgotten.
Example¶
A satellite operator holds a flight readiness review before committing a launch campaign. Unlike a review of who has authority, this gate polls whether the operating system is ready to fly. Each subsystem reports against a required maturity bar — the ground crew's certification status (people), the anomaly-response procedures and on-call staffing (support scaffold), and the abort criteria and contingency controls. Readiness is graded red / yellow / green against a target Technology Readiness Level[n1].
Most subsystems are green, but one science sensor sits at TRL 6 where the plan assumed TRL 7 — a yellow. The board does not cancel and does not wave it through. It de-scopes: fly the mission with a documented workaround and hold the one dependent experiment that needs the immature sensor until it matures. The output is a conditional go — proceed on the ready parts, defer the unready one — which is exactly what an honest readiness gate produces: not a verdict on the whole idea, but a graded decision that lets the ready scope move while the gap closes.
How it works¶
- Aggregate readiness signals. Pull evidence across dimensions — trained people, resources, support, risk controls — from capacity maps, pilots, and prior reviews.
- Grade against a bar. Score each dimension red / yellow / green against an explicit "ready enough" threshold, not against perfection.
- Force a decision on every non-green. Require each red or yellow to trigger a hold, a de-scope, or a targeted fix — no silent passes.
- Issue the go / hold / de-scope. Produce a single proceed decision that may be conditional, scoping the roll to what is genuinely ready.
Tuning parameters¶
- Dimension weighting — how much each readiness area counts toward the overall gate. Heavy weighting on safety controls slows go but reduces brittle launches.
- Readiness threshold — how ready "ready enough" is. A high bar prevents failures but can stall a design forever.
- Red/yellow action rules — what a given grade forces. Strict rules prevent theater; loose rules invite it.
- Reversibility weighting — how much a hard-to-reverse roll raises the bar to proceed.
- Board independence — whether reviewers are separate from the team that built the design; independence sharpens findings but adds friction.
When it helps, and when it misleads¶
Its strength is forcing an explicit go/no-go with de-scope as a real option, so a design ships on its ready parts and holds the unready ones instead of launching whole and breaking. It is the gate that turns scattered readiness evidence into one accountable decision.
Its failure mode is checklist theater: the review green-lights because the boxes are ticked, without letting any finding change the plan — the yellow sensor flies anyway because the schedule wants it to. It can also over-conservatively hold forever, mistaking "not perfect" for "not ready." The discipline that guards it is the rule that every non-green must alter a decision — a hold, a de-scope, or a resourcing move — and that "ready enough," not "ready," is the bar.
How it implements the components¶
capability_requirement— verifies the people and skills the design needs are trained, certified, and present.support_scaffold— confirms the training, escalation, and maintenance layer is staffed and in place before go.scope_adjustment_rule— the gate's output: proceed / hold / de-scope / phase, scoped to what is ready.
Unlike its near-twin Governance Readiness Review, it does not adjudicate the authority stack (governance_and_decision_rights, incentive_fit); and because it reviews evidence rather than producing it, actually running the design in a live setting to see whether it holds (operational_validation, workflow_fit, adoption_risk_signal) is the job of Operational Pilot.
Related¶
- Instantiates: Implementation Feasibility Alignment — it is the pre-commitment gate that converts readiness evidence into a go/hold/de-scope decision.
- Consumes: Operational Pilot supplies the live-condition evidence the gate weighs; Capacity Mapping supplies the people-and-resource readiness inputs.
- Sibling mechanisms: Governance Readiness Review · Operational Pilot · Feasibility Study · Deployment Plan · Capacity Mapping · Workflow Fit Analysis · Process Walkthrough · Training and Support Package
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: The review evaluates people, resources, workflows, authority, support, and risk controls and produces an implementation-readiness finding.
Nearest alternative: Decision, Gate & Allocation — The finding may authorize proceeding, but readiness assurance is the defining operation.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Evidence-graded readiness gates descend from engineering maturity reviews and Technology Readiness Levels.
Related originating lineages:
- Aviation & Aeronautics — NASA developed the canonical TRL scale for flight technology.
- Organizational & Management Science — Stage and launch governance materially generalized readiness review to organizational implementation.
Review resolution: Both reviewers independently assign engineering_design as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The record preserves independently developed forms rather than treating every alternate as mere application. It has established independent use across several domains, but that does not make it domain-free. The encyclopedia entry generalizes the established mechanism without creating a new composite lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Technology Readiness Levels — a 1-to-9 maturity scale originated at NASA to grade how proven a technology is, from basic principles (1) to flight-proven (9). Readiness reviews use such graded bars so "ready enough" is an explicit threshold rather than a gut feeling. ↩