Launch Readiness Fundamentals
I.
Defining Launch and Go-Live
- A.A launch, or go-live, is the point at which a solution moves from being built and tested to being actually used - the moment the design and development work described in earlier modules becomes real for the people it was built for.
- B.For a fundamental, foundational-scope solution - a single feature, a small workflow change, a narrowly scoped fix - a launch is usually a single, well-defined event: a specific date and time when a new capability becomes visible or usable.
- C.This is different from a large, multi-phase rollout, which a more senior OFA or project manager would coordinate; the launches an OFA 1 supports are smaller and more contained, but the underlying discipline - confirming readiness, coordinating with the right people, communicating clearly - is the same discipline at any scale.
II.
Launch as a Test of Earlier Stewardships
- A.A launch is not the finish line for the OFA's own stewardship; it is the point where earlier stewardships are tested against reality.
- B.The requirements work of Module 4 and the testing work of Module 7 both exist to make a launch trustworthy — a launch of a solution nobody validated against its documented requirement is simply an unverified guess released into production, and this module's role is to help make sure that never happens.
III.
Scope of the OFA 1's Role
- A.An OFA 1 does not decide when or whether to launch — that decision belongs to a a project lead, or a product owner, informed by the readiness signals described below.
- B.What an OFA 1 does, under guidance, is help initiate that launch responsibly.
- C.This distinction matters because a new OFA who feels pressure to personally approve or block a launch is operating outside their actual role - the job is to surface accurate, well-checked information, not to make the go/no-go call.
IV.
Core Launch-Support Activities
A.
Verifying Deliverables Against Requirements
Before a solution goes live, an OFA 1 who helped document the original requirement is well positioned to check that what was actually built and tested matches what was asked for - not a slightly different, more convenient version of it.
B.
Coordinating With Technical Teams
Confirming with the team that will perform the deployment what needs to happen, in what order, and which environment (see Appendix H) the change is moving into.
C.
Running Basic Launch-Readiness Checks
- 1.Working from a checklist rather than assuming readiness informally:
- a.Has testing been completed and signed off?
- b.Is every known defect either fixed or explicitly accepted?
- c.Is there a rollback plan if something goes wrong?
- d.Has everyone who needs to know been told?
D.
Communicating the Launch
Drafting, under a senior OFA's direction, a clear notice to the people affected - what is changing, when, and what they should expect - so a launch is never a surprise to the people who depend on the outcome.
V.
Checklist Overview
- A.The table below is a starting checklist an OFA 1 helps work through before a fundamental solution goes live.
- B.A senior OFA or supervisor owns the final go/no-go decision; the OFA 1's role is to confirm each item honestly, flagging anything unresolved rather than assuming it is fine because the launch date is close.
| Readiness Check | What It Confirms |
|---|---|
| Requirements traceability | Every documented requirement has a corresponding, tested deliverable, with no unflagged, "silent" scope changes |
| Test completion | All planned test cases have been executed and results recorded; any open defect has a decision attached - fixed, or knowingly accepted |
| Environment confirmation | The change is moving into the correct environment (see Appendix H), and stakeholders know which environment "live" actually refers to |
| Rollback awareness | Someone has confirmed what happens if the launch needs to be reversed |
| Communication sent | The people affected by the change have been told what is changing and when, in plain language |
VI.
Launch Readiness as a Final Check
- A.This module is deliberately positioned after requirements (Module 4) and testing (Module 7) because launch readiness is really a final check that those two earlier stewardships were done well.
- B.A requirement that was never precisely documented cannot be verified against what was built; a test case that was never actually executed cannot honestly be marked complete on a readiness checklist.
- C.An OFA 1 who has built strong habits in Modules 4 and 7 will find this module's checklist mostly a matter of gathering evidence that already exists, rather than creating anything new - which is exactly the point.