Launch Readiness Review¶
Cross-functional readiness review — instantiates Transition Readiness Assessment
Convenes every function that owns a piece of a public launch to confirm the target is defined, all owners are go, and no cross-team dependency is still open before the switch is flipped.
A Launch Readiness Review treats readiness as a coordination problem rather than a technical property. Its defining move is to bring every function that owns a piece of a public-facing launch into one room and ask each for an explicit go/no-go on its own scope — marketing, sales, support, legal/compliance, operations, and any external partner — then map the dependencies between those owners and require each closed before commit. It exists to catch the failure where every team is individually ready but the launch as a whole is not, because a hand-off between two of them was never owned or closed. It is the wide seam-checker, not the deep operability check its operational sibling performs.
Example¶
A bank is launching a new consumer credit card to the public. The review convenes the card-product team, marketing, compliance, the call center, fraud/risk, app engineering, and the third-party rewards partner. It opens by pinning the target: card live to the public with applications open, rewards active on first swipe, and servicing staffed for launch-week volume. Each owner then declares go or no-go for its own piece — marketing's campaign is scheduled, compliance's disclosures are approved, the call center is trained and staffed, fraud rules are tuned, the app-store build is released, and the partner's redemption API is live.
Individually, everyone reports ready. The dependency map surfaces the gap: marketing's launch email fires Tuesday, but the rewards partner's redemption API does not go live until Thursday — customers would apply, receive the card, and find rewards dead for two days. No single team's own check would have caught it, because the failure lived in the seam between marketing's timing and the partner's readiness. Outcome: the review holds the campaign three days to align the two, and the launch goes out as one coherent event instead of a two-day embarrassment.
How it works¶
- Seat every owner. Each function that owns a launch dependency gets a seat and speaks only to its own scope — this is not a vote on the whole, but a set of per-function declarations.
- Pin the target first. The review fixes exactly what "launched" means so every owner assesses readiness against the same finish line, not their private one.
- Map the seams. Cross-team hand-offs and shared dependencies are drawn out explicitly, each assigned an owner and a closure date; an un-owned dependency is treated as a no-go.
- Go only when all-go and all-closed. The coordinated launch commit is issued only when every owner is go and every shared dependency is closed — the two conditions are separate gates.
Tuning parameters¶
- Breadth of the table — which functions get a seat and a veto. Wider catches more seams but slows consensus and invites a lone holdout; narrower is faster but can miss the function whose gap sinks the launch.
- Owner veto vs. advisory — whether a function's "no-go" blocks the launch or merely flags a risk to the decision authority. Hard vetoes resist override; advisory keeps one cautious team from holding the whole launch hostage.
- Dependency depth — how far the map reaches (direct hand-offs only, or second-order partner-of-partner). Deeper surfaces hidden seams; shallower stays tractable.
- Lead time before go-live — how far ahead the review runs. Early leaves room to fix gaps but readiness can decay before launch; late reflects true state but leaves no time to remediate.
- Reconvene trigger — whether a slipped date or a scope change forces a fresh review rather than trusting a stale all-go.
When it helps, and when it misleads¶
Its strength is catching the "everyone's ready but the launch isn't" failure — the un-owned seam between functions that no single team's own check surfaces — and extracting a public, date-bound commitment from each owner at once.
Its central failure mode is turning into theater: when the launch date is politically fixed, the review exists to bless it, and owners feel pressure to say "go" rather than raise a real gap, so the meeting launders a decision instead of testing one. A room of peers under deadline is also prone to collective optimism, and the review can over-index on the functions that have a seat while missing the one that does not. The discipline that guards against this is to require each owner's go to rest on its own function's evidence rather than the room's mood, to log every no-go with the specific open dependency named, and to treat the launch date as a movable output of the review rather than a fixed input.[n1]
How it implements the components¶
transition_target_state— the review opens by pinning exactly what "launched" means, so every function assesses readiness against one shared target rather than its private definition.stakeholder_readiness_map— its core artifact: a per-function go/no-go across every owner of a launch piece, making a single team's gap visible against the whole.dependency_map— it draws out the cross-team hand-offs and shared dependencies between those owners and requires each closed before commit.
It does not codify the pass/fail conditions themselves — that is the Preflight Checklist — or aggregate graded evidence and gap severity, which is the Readiness Scorecard; the production-operability side (monitoring, support, rollback) belongs to the Operational Readiness Review, and the proceed / delay / abort decision and its authority sit with the Go / No-Go Meeting.
Related¶
- Instantiates: Transition Readiness Assessment — the wide, cross-functional gate that confirms a public launch is coordinated before commit.
- Consumes: the Operational Readiness Review's ops sign-off and each function's Readiness Scorecard supply the per-owner status this review rolls into one launch decision.
- Sibling mechanisms: Operational Readiness Review · Readiness Scorecard · Preflight Checklist · Go / No-Go Meeting · Phase-Gate Review · Gap Remediation Plan · Migration Readiness Assessment · Clinical Discharge Readiness Check · Disaster Reentry Check
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Cross-functional owners make a bounded go-or-hold launch disposition after confirming target, ownership, and dependency closure.
Nearest alternative: Assessment, Review & Assurance — Readiness is checked, but the operative output determines whether the launch switch may be flipped.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Cross-functional product and project management developed launch-readiness reviews that close ownership and dependency gaps before release.
Related originating lineages:
- Computer Science & Software Engineering — Software release management contributed production cutover checks and deployment ownership.
- Engineering & Design — Formal readiness-review practice supplied evidence packages and go/no-go discipline.
Review resolution: Both independent reviews place the primary lineage in organizational_management. The queued differences (alternate_origin_disagreement) concern secondary metadata rather than primary provenance. The final retains engineering_design, computer_science only where a reviewer supplied a formative-lineage rationale; downstream application by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis records the relationship among origin traditions, while domain_reach=multi_domain records application breadth separately. encyclopedia_synthesis=false reflects whether either reviewer identified a corpus-specific synthesis, and confidence=high preserves the more cautious evidence assessment.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The review coordinates across functions; it assumes each function has already run its own internal readiness check (its scorecard, its operational review) before arriving. When it becomes the place where readiness is first discovered rather than confirmed, it is being used too late — the seams it exists to check get found with no time left to close them.
[n1] The Launch Readiness Review — and its aerospace sibling the Flight Readiness Review — is an established milestone in large-program management, in which each responsible discipline formally polls "go" or "no-go" before a launch is committed. The term is used here in that standard sense, generalized to any public go-live where several functions must be go at once. ↩