18. Rollout Sequence: Triage Then System

Friday, 11:12 a.m., customer presentation already on the projector, someone still writing "full rollout — week one" on the shared doc.

The program is already behind, with unresolved blockers accumulating every cycle.

Someone proposes a full OS rollout with new templates, role changes, and weekly governance meetings starting immediately.

That sequence usually collapses adoption before controls stabilize.

Start with triage, not broad transformation

When a program is unstable, first objective is to stop bleed rate:

• unresolved decision pileup,
• truth-state contradictions,
• late risk discovery,
• blocked dependencies with no owner.

Do not launch 20 controls at once.

Install the minimum loop that restores decision quality.

Triage phase (first 2-4 weeks)

Timebox triage and keep it narrow.

Four controls stabilize a distressed program. Install them in this order — the later ones depend on the earlier ones being readable:

1. ownership map for top active decisions,
2. one-page truth on fixed cadence,
3. risk register with named owners and triggers,
4. gate output discipline (decision / owner / date / artifact delta).

If these four controls stay stable for two cycles, leaders can shift from firefighting to planned execution.

Entry/exit criteria

Define what "triage done" means before starting — not after. Four criteria: the decision backlog is below the threshold you declared on day one, the one-page and source records have aligned for two consecutive cycles, the escalation path has a functioning response SLA, and there are no unresolved "which value is live" conflicts on critical threads.

Without those criteria predeclared, triage becomes permanent emergency mode.

System phase (after triage)

Once stable, layer deeper controls:

• requirement lifecycle rigor,
• technical evidence loops,
• supplier capability discipline,
• training and cadence for durability.

Sequence matters: stabilize triage controls before layering system controls.

System controls without triage stability feel like overhead — teams comply on paper and work around them in practice.

Common rollout mistakes

• launching policy before proving value on one thread (no documented evidence package from a first-thread pilot in the rollout log),
• adding templates without owner behavior change (template completion rate rising while decision closure time unchanged),
• measuring activity count instead of decision quality (rollout metric is document count or meeting attendance, not closure rate or surprise rate),
• ignoring local context and forcing one-size sequence (single triage plan applied identically across programs with different distress patterns).

Each mistake lowers trust in the OS.

Adoption metric that matters

Template completion is not adoption. The metrics that distinguish real adoption from compliance theater are all timestamp deltas or count deltas in the decision record — not whether the template exists:

• decision closure time (timestamp delta between decision logged and decision closed in the decision log),
• decision carry rate (count of open decisions still unresolved at the start of the following review cycle),
• late surprise rate (count of risk register additions made after the last gate without prior flagging),
• one-page/record mismatch rate (comparison of one-page status to source record at weekly cadence),
• reopen rate on closed decisions (count of items returned to open status in the decision log),
• PM status request frequency between reviews (a sustained drop signals that cadence artifacts are trusted).

If these are improving, adoption is real.

Six programs, one rollout, eight weeks. Template completion hit 90% across all six by week six.

Decision closure time was unchanged. One program had started filling in the prior week's templates retroactively — not to improve the record, but to show the completion number. Another held weekly governance meetings with no decisions recorded. The rollout had produced activity, not adoption.

The effort stopped. Two programs — the ones with the worst unresolved decision backlogs — received the four-control minimum with predeclared exit criteria. No additional templates. No governance overhead. Four weeks later, both met the criteria.

The next two programs were not told to adopt. They asked. The first two were visible proof — review meetings shorter, decision backlogs shrinking, leads no longer chasing status. That visibility did more than any mandate.

Field test: name one program control from this OS that your organization installed in the last 90 days. Does it have a named DRI, a controlled record, and at least one decision that traced through it? If not, it was installed in form but not in practice — and the next program will not use it either.

Six weeks after your next rollout, check one control you installed. Is it still running because the cadence forces it, or because one person keeps remembering to? If it is the person, you have installed a habit with a single point of failure — and the first lead change will take it out.