LEANPRO / PRACTICAL WORKBENCH / 02
Go-live decision.
Make the decision traceable. Make the conditions explicit.
Sponsors, decision forums and delivery teams preparing a consequential operating or systems release.
A decision brief linking readiness evidence, material exceptions, recovery options and accountable conditions.
00 / SET THE BOUNDARY
Your working brief.
Start with a real decision and a defined scope. Work through the six sections with the people who operate the process and the people accountable for accepting change.
Prepare a first draft, then challenge it in a working session. Put references to evidence in the registers, assign accountable reviewers, and turn the gaps into actions. Review the generated decision brief before sharing it. The tool organises evidence; it does not certify readiness or make a decision for you.
Your entries stay in this tab unless you choose to save in this browser or download a copy. Nothing entered here is submitted to Leanpro. Avoid unnecessary personal, sensitive or confidential details. A downloaded HTML copy includes your entries and the complete tool, so you can reopen it offline.
01 / WORKING SESSION
Set the decision boundary.
Who is deciding what, by when, and on which evidence?
Work through it
- State the release scope, operating consequences and decision deadline. Identify the accountable authority and required consultees.
- Agree decision criteria, evidence cut-off and how material changes after the meeting will be escalated.
Challenge the assumption
- Is the forum authorised to accept the risks being presented?
- What change would require the decision to be revisited?
Worked example — illustrative, not a client case
An illustrative release decision covers a defined service group only. Adding a second group after the meeting triggers a new readiness review rather than being treated as a minor scheduling change.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Decision / scope | Authority / consultees | Evidence cut-off | Reopen trigger | Owner | × |
|---|---|---|---|---|---|
| Release boundary | |||||
| Decision forum | |||||
| Post-decision changes |
OUTPUT STANDARDAn explicit decision boundary and authority that participants understand.
Watch for: Holding a status meeting and calling its silence an approval.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
02 / WORKING SESSION
Assemble the evidence set.
Which operating claims are supported by accepted evidence?
Work through it
- For every criterion, link source evidence, test conditions, date and an accountable acceptance owner.
- Record contradictory or incomplete evidence. Summarise the consequence of missing evidence rather than assigning an optimistic colour.
Challenge the assumption
- Was this evidence produced under representative operating conditions?
- What changed since the evidence was accepted?
Worked example — illustrative, not a client case
A passed integration test predates a material configuration change. Its relevance is reassessed and the affected scenario is retested before the decision pack relies on it.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Criterion / journey | Source / evidence date | Acceptance owner | Gap / contradiction | Decision implication | × |
|---|---|---|---|---|---|
| Critical transactions | |||||
| Migration / reconciliation | |||||
| People and support |
OUTPUT STANDARDA small, traceable evidence index with clear gaps and current acceptance.
Watch for: Using percentage-complete dashboards as operating evidence.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
03 / WORKING SESSION
Expose material exceptions.
What is unresolved, and what consequence would acceptance create?
Work through it
- Separate blocking issues, conditional acceptance and follow-up work. State consequences, affected users and uncertainty.
- For every proposed workaround, record the owner, capacity, duration, control implications and exit evidence.
Challenge the assumption
- Is the workaround usable at expected volume?
- Who has authority to accept the residual exposure?
Worked example — illustrative, not a client case
A manual workaround can handle ten cases in rehearsal but expected demand is hundreds. The decision considers actual capacity and service impact instead of accepting “workaround available” at face value.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Exception / impact | Proposed treatment | Workaround / capacity | Acceptance authority | Exit evidence / date | × |
|---|---|---|---|---|---|
| Critical defect | |||||
| Temporary process | |||||
| Deferred operating scope |
OUTPUT STANDARDExceptions expressed as decisions with consequences and owned treatments.
Watch for: Closing an issue in the tracker while leaving its operating consequence unresolved.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
04 / WORKING SESSION
Test cutover and recovery.
Can the move be executed and, where feasible, recovered?
Work through it
- Rehearse the sequence, prerequisites, completion checks and decision points. Include communications to service users and support teams.
- Identify recovery limitations, data implications and the last viable recovery point. Confirm specialists own technical recovery validation.
Challenge the assumption
- What if the sequence overruns the business window?
- Which recovery steps are irreversible or unproven?
Worked example — illustrative, not a client case
The rehearsal identifies a point after which rollback would require reconciliation of new transactions. The forum receives that limitation explicitly and agrees who controls the decision window.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Cutover / recovery step | Dependency / timing | Owner / deputy | Stop or recovery point | Evidence / limitation | × |
|---|---|---|---|---|---|
| Final preparation | |||||
| Release decision | |||||
| Recovery / contingency |
OUTPUT STANDARDA rehearsed and bounded recovery approach with visible limitations.
Watch for: Treating “we can roll back” as evidence without a timed rehearsal.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
05 / WORKING SESSION
Record the decision and conditions.
Can somebody reconstruct why the decision was taken?
Work through it
- Record the decision, rationale, evidence considered, dissent or unresolved uncertainty and decision makers.
- Give each condition an owner, due date, evidence requirement and escalation if not met. Distinguish conditions before release from post-release actions.
Challenge the assumption
- Does each condition have a measurable closure test?
- Who confirms a pre-release condition has actually been satisfied?
Worked example — illustrative, not a client case
The forum authorises a limited release only after two access controls are evidenced. The pack records who verifies each condition before execution rather than treating approval as unconditional.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Decision / condition | Rationale / evidence | Accountable authority | Closure requirement / due | Escalation | × |
|---|---|---|---|---|---|
| Proceed / defer decision | |||||
| Pre-release condition | |||||
| Post-release action |
OUTPUT STANDARDA decision record with testable conditions and explicit acceptance authority.
Watch for: Writing “approved with actions” without defining which actions must precede release.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
06 / WORKING SESSION
Define stabilisation and exit.
What proves the operating service can take ownership?
Work through it
- Plan hypercare around the cycles and service conditions that matter. Agree incident priorities, support cover and decision routes.
- Define exit criteria and a receiving owner for residual work. Review performance, known issues and workarounds before reducing support.
Challenge the assumption
- What must be observed beyond the first quiet day?
- Who owns a known issue after the project team exits?
Worked example — illustrative, not a client case
A service meets its early demand but has not yet processed a peak cycle. Support exit is staged around that evidence, with residual issues accepted by the operational owner.
Use the starter rows or add your own. Evidence references can identify your internal records without copying confidential content into this file.
| Operating milestone | Support / owner | Exit criterion | Residual commitment | Acceptance evidence | × |
|---|---|---|---|---|---|
| First service cycle | |||||
| Peak demand / reporting | |||||
| Business-as-usual handover |
OUTPUT STANDARDAn evidence-based support exit and accepted residual ownership.
Watch for: Ending hypercare because the planned calendar date has arrived.
Record the review, not just the activity.
“Accepted” requires a named reviewer, date and evidence. “Not applicable” needs the same accountability and a rationale. This is a working record, not independent assurance.
07 / INTERACTIVE WORKBENCH
Decision conditions register.
Record blockers, conditions and follow-up actions separately. The tool highlights open commitments; it never issues a go-live recommendation or replaces the accountable decision forum.
Use the action log below for each commitment. Choose “Blocker” only where an accountable decision has made it a blocking condition. Record closure evidence and an owner before marking it complete. The decision brief highlights open blockers and overdue commitments alongside the section reviews.
08 / TURN GAPS INTO COMMITMENTS
An action needs an owner.
Describe an observable closure outcome. Record the owner and due date, and add an evidence reference when closing it. A completed action without owner and evidence remains unresolved in the decision brief.
| Action / closure outcome | Accountable owner | Due date | Priority | Status | Closure evidence | × |
|---|
09 / BRING THIS TO THE DECISION
Your decision brief.
These counts describe your records, not a readiness score. An accepted section can still contain conditions; review the evidence and the action log before any decision.