Operational Readiness

A launch date is usually the date the software can be deployed, because that is the date the engineering plan produces. The business's date is when it can run the thing, and the gap between those two dates is where a large share of launch failures live.

The failures share a signature: they are invisible on launch day and inevitable from the start, because each downstream process has a lag. Returns surface two to three weeks after sales. Reconciliation breaks at the first month-end. Support load builds with the installed base. Nothing crosses a threshold on the dashboard, because the dashboard measures what the launch team built.

Why it matters

The architect is frequently the only person with visibility across the whole stream, and therefore the only one positioned to notice that a new product category has a 25% return rate against a catalogue average of 6%, or that its settlement file has a format the finance system has never seen.

The cost of the gap is paid in manual effort and goodwill: overtime in operations, manual reconciliation, refunds issued to end an argument. None of it appears in the engineering retrospective, which is one reason the same launch fails the same way twice.

Implementation patterns

• A readiness checklist owned by each receiving process, with a named person who says yes: returns, finance, support, tax, legal, partner operations. Ownership by name, not by department.
• Launch metrics that include the lagging processes from day one, visible while still empty: return rate against plan, unreconciled settlement value, average handling time.
• A pilot with real volume — one region, one week, a few hundred transactions — which exercises the human processes. A pilot sized to test the software tests only the software.
• Choose the date from the slowest receiving process, not the engineering estimate.
• Leave correction time inside the peak window. Launching the week before a seasonal peak removes every opportunity to fix what the first real customers reveal.
• Capacity-test the human process too: how many cases an hour can be handled, and what happens at twice that.

Industry example

Retail and marketplace businesses supply the clearest cases, because their peaks are public and their downstream processes are physical. The pattern is documented widely in the aftermath of seasonal trading incidents, where the software scaled and the operational processes did not, and it generalises to any launch where somebody downstream has to handle what the system produces: insurance claims, regulated onboarding, marketplace payouts.

Failure scenarios

• The one-month cliff, where reconciliation fails at the first month-end and finance cannot close the books.
• A returns process sized from the wrong baseline, overwhelmed two weeks after a successful launch.
• Support without material, where handling time doubles and the queue grows faster than agents can be trained.
• A partner or tax requirement discovered after launch, which can require a temporary withdrawal of the product.
• The readiness checklist as theatre, signed by departments rather than people, which produces the same outcome with a paper trail.

Trade-offs

Operational readiness gates cost calendar time and can delay a launch that is technically ready, which is politically expensive and occasionally wrong: a date can matter more than completeness, and a business may rationally choose to launch with manual workarounds. The difference between that and this failure is whether the workaround was chosen, staffed and time-boxed, or discovered.

When not to use it

For a launch with no downstream processes, such as an internal tool used by its own builders, or a change confined to one team's service, this is ceremony. The scope test is direct: name every process that receives something new because of this launch. If the list is empty, deploy and move on. If it has four entries, each needs an owner.

Interview question

Q: You are the architect on a new product category launching in six weeks, before the seasonal peak. Engineering says it will be ready. What do you do with your six weeks?

What a strong answer covers: listing the receiving processes and finding an owner for each · identifying which have a lag, so their failure will not appear on launch day · checking the economics that differ from the existing catalogue, such as return rate or settlement format · proposing a real-volume pilot before the peak rather than a load test · putting the lagging metrics on the launch dashboard from day one · and arguing for a launch date inside the peak window with correction time, or an explicit, staffed manual workaround if the date cannot move.

Quick check

Quiz: Why does a launch failure of this kind not show up on launch day? Because each receiving process has a built-in lag — returns windows, month-end close, support ramp — so the failure is created at launch and surfaces weeks later.

Flashcard: What is the scope test for operational readiness? — Name every process that receives something new because of this launch; each one needs a named owner who says yes.