Integrated Readiness and Release Review¶
Governance gate — instantiates Concurrent Cross-Functional Integration
A whole-system readiness gate that checks the release unit operates end to end and that a named owner accepts the transition — not that each function is locally green.
An Integrated Readiness and Release Review is the whole-system gate before go-live. Its defining stance is refusing the "local greens roll up to ready" fallacy: it verifies that the release unit operates end to end across operations, support, safety, supply, compliance, and adoption — and that a named operating owner actually accepts the transition — rather than aggregating each function's self-report of "done." It produces a release decision with conditions, residual risk, a transition plan, and a rehearsed rollback. It is the final acceptance of the assembled system, distinct from the mid-course Cross-Functional Design Review that settles one tradeoff, and it consumes the continuous evidence produced by the Integration Build or End-to-End Increment rather than generating it.
Example¶
A state agency is about to launch an online benefits-eligibility service replacing paper intake. Every team reports green: the web app works, the rules engine passes its tests, the call center is trained, the data migration ran. But the readiness review runs an actual end-to-end operational trial — a real applicant journey from submission through eligibility determination to caseworker follow-up and payment — modeled on an Operational Readiness Review[n1]. It finds two whole-system gaps no local green revealed: when the rules engine flags an edge case there is no owned path for a caseworker to override, and the rollback plan was never rehearsed.
The gate issues a conditional go: launch to one pilot county, with the override path owned and the rollback rehearsed first. And it requires the benefits operations director — the operating owner — to sign that they accept the running system, rather than the project team declaring victory and walking away.
How it works¶
- Review whole-system evidence, not local rollups. Operations, safety, support, supply, compliance, adoption, data, training, and rollback — as one system.
- Run an integrated operational scenario end to end through the real transition, including the awkward paths.
- Inspect open exceptions and confirm named owners accept the transition. No unowned go-live.
- Decide go / conditional-go / hold with conditions and residual risk; keep an independent safety path; monitor follow-through.
Tuning parameters¶
- Gate strictness — a hard gate vs. a risk-accepted conditional go; how much open risk can still pass.
- Evidence breadth — which readiness domains are in scope for this release unit.
- Trial fidelity — a full operational rehearsal vs. a tabletop walkthrough.
- Rollback requirement — rehearsed vs. merely documented.
- Exception tolerance — how many and what severity of open items still permit go.
When it helps, and when it misleads¶
Its strength is catching the whole-system failures that local greens hide — the unowned handoff, the unrehearsed rollback, the support desk that isn't actually staffed — and forcing a named owner to accept the running system rather than a pile of completed deliverables.
Its failure modes are an unowned go-live, an unresolved exception waved through, and support that turns out not to be ready. The classic misuse is a rubber-stamp gate that ratifies a launch date already fixed politically, accepting one deviation after another because "it's always been fine" — the normalization of deviance[n2]. The discipline that guards against it is an independent safety path, no local-green rollup, a rehearsed rollback, and an explicit owner sign-off on the transition.
How it implements the components¶
integrated_readiness_release_and_transition_record— the gate assembles the whole-system readiness evidence, exceptions, residual risk, rollback, and the accepted transition record.integrated_outcome_and_system_boundary— it verifies whole-system behavior against the defined end-to-end outcome and release unit (the Integrated Product or Service Team defines that outcome; the review verifies achievement of it).
It does not run continuous integration through development (that's the Integration Build or End-to-End Increment), resolve mid-course tradeoffs (Cross-Functional Design Review), or govern interfaces (Interface Control Document and Contract Test). It is the final whole-system acceptance, not the day-to-day machinery.
Related¶
- Instantiates: Concurrent Cross-Functional Integration — the review is the archetype's whole-system go/no-go.
- Consumes: Integration Build or End-to-End Increment supplies the end-to-end test evidence the gate weighs.
- Sibling mechanisms: Integration Build or End-to-End Increment · Integrated Product or Service Team · Cross-Functional Design Review · Big-Room Planning or Concurrent Set-Based Workshop · Shared System Model or Digital Thread · Interface Control Document and Contract Test · Dependency and Change Notification Board · Cross-Functional Swarm on Integration Constraint
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: The whole-system gate makes a bounded release-or-hold disposition after end-to-end operation and named-owner acceptance are established.
Nearest alternative: Experiment, Test & Rehearsal — End-to-end behavior may be tested, but the operative output is release authorization.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Whole-system readiness reviews before operation are rooted in systems engineering and major technical-program assurance.
Related originating lineages:
- Aviation & Aeronautics — Aerospace operational-readiness gates materially provide the canonical system-operator-support review form.
- Organizational & Management Science — Named transition ownership and cross-functional release governance materially broaden it beyond aerospace.
Review resolution: Both independent reviews place the primary lineage in engineering_design. The queued differences (alternate_origin_disagreement, origin_mode_disagreement, domain_reach_disagreement, encyclopedia_synthesis_disagreement) concern secondary metadata rather than primary provenance. The final retains aviation_aeronautics, organizational_management only where a reviewer supplied a formative-lineage rationale; this does not convert downstream applicability into origin. origin_mode=cross_disciplinary_synthesis because the entry's present form deliberately composes methods from the documented lineages. domain_reach=multi_domain records application breadth separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] An Operational Readiness Review is a real gate used in aerospace and large-system programs to confirm a system, its operators, and its support are ready to operate — as opposed to confirming that development is merely complete. It is the canonical model for a whole-system readiness gate. ↩
[n2] Normalization of deviance (Diane Vaughan, from her study of the Challenger accident): the gradual acceptance of small unresolved deviations until they become routine, quietly eroding the safety margin. A hard readiness gate exists precisely to resist it. ↩