By the time you reach this stage, the analysis is (mostly) done. What determines success now is process: how you socialize the case, how hard it gets challenged before the meeting, and whether the final version is clean and consistent. This chapter shows you how to pre-wire stakeholders, run red-team reviews, do a last QA pass, choreograph the approval path, and walk into the decision meeting with no surprises.
21.1 Pre-Wiring Strategy and Stakeholder Reviews
Pre-wiring is simply this: you make sure no one sees the case for the first time in the approval meeting. You already used stakeholder mapping in earlier chapters; now you operationalize it.
What pre-wiring is (and isn’t)
It is:
- Early, focused conversations with decision-relevant stakeholders.
- A way to surface objections, fix gaps, and build sponsorship.
- A test of whether your story lands for each audience.
It is not:
- Side-door decision-making that bypasses governance.
- Lobbying for a pet solution with no intent to adjust.
- A substitute for transparent documentation.
Who to pre-wire
At minimum:
- Your sponsor and direct boss.
- Finance partner / CFO staff.
- Risk/Compliance (plus Security/Privacy where relevant).
- Architecture/IT (for tech or data cases).
- Any function whose P&L, capacity, or risk is materially affected.
- The “economic buyer” and the person who actually runs the meeting (e.g., ExCo or Board secretary).
What to aim for in each session
Go in with a clear purpose:
- With finance: validate baselines, drivers, modeling logic, and accounting treatment.
- With risk/compliance/security: validate risk taxonomy, residual risk, control design.
- With architecture/IT: stress-test feasibility, integration, and technical debt implications.
- With operations / line leaders: test practicality of implementation and benefit ownership.
- With the sponsor/economic buyer: test the overall story, ask, and conditions they’d support.
In each pre-wire, you want to leave with:
- Clear “must fixes” (non-negotiable changes).
- Clear “nice to have” suggestions.
- A read on their likely stance (supportive / neutral / skeptical) and why.
How much to show
- Early: show outlines, draft economics, and high-level options; don’t waste time polishing slides.
- Mid-way: show near-final economics, key exhibits, and risk/implementation summary.
- Late: show full draft of the decision pack; invite only “fact/logic” comments, not structural re-writes.
Timebox pre-wires; 30–60 minutes is usually enough if you’re sharp and focused.
21.2 Red-Team and Challenge Sessions
A red-team review is where you invite smart people to try to break your case. It is uncomfortable and absolutely essential for big decisions.
What a good red-team review looks like
- Independent: reviewers were not deeply involved in building the case.
- Empowered: they are explicitly asked to challenge assumptions, structure, and logic.
- Bounded: they focus on the case quality, not on re-doing the project from scratch.
Typical red-team members:
- Senior finance controller or FP&A lead.
- Peer sponsor or BU head who has run similar initiatives.
- Senior architect or technical leader (for tech/platform cases).
- Risk or internal audit (for risk-heavy or regulated areas).
How to brief a red team
Give them:
- The draft executive summary.
- The options and economics section.
- The risk & implementation sections.
- A short note listing your own known weak spots (this builds trust and focuses time).
Ask them explicitly:
- “What would make you not approve this?”
- “Where are we most likely to be wrong?”
- “What is missing for this to be board-grade / investor-grade / regulator-grade?”
How to run the session
- 60–90 minutes, focused on discussion rather than presentation.
- Start with a 5-minute recap of the decision and recommendation, then go straight to Q&A and challenge.
- Capture issues live in a visible list (e.g., “Assumption X too aggressive”, “No downside case for Y”, “Vendor risk underplayed”).
Afterwards, categorize feedback:
- Must fix before submission.
- Address explicitly in the pack (e.g., more caveats, scenario).
- Park for later (e.g., long-term architecture simplification ideas).
Crucially: close the loop. Share how you responded to red-team input; this builds credibility and future support.
21.3 Final QA: Numbers, Logic, and Consistency
Final QA is about making sure the whole case “hangs together” as one coherent artifact. This is where many otherwise strong cases stumble.
Think of three lenses:
- Numbers – math, references, and cross-document consistency.
- Logic – does each conclusion follow from evidence? Are trade-offs explicit?
- Coherence – language, labels, and structure align everywhere.
Numbers QA – minimum standards
- Model integrity
- No broken formulas or #REF errors.
- Inputs separated from calculations; no hard-coded numbers buried in formulas.
- Cash flows reconcile to totals; NPV/IRR/payback calculations tested with simple edge cases (e.g., zero benefits).
- Cross-pack consistency
- Same NPV, IRR, payback, total costs, total benefits in:
- Executive summary
- Economics section
- Key exhibits
- Any Board or investor variant packs
- Same discount rate and horizon mentioned everywhere.
- Economics per option and per scenario consistent across all references.
- Same NPV, IRR, payback, total costs, total benefits in:
Logic QA – sanity and balance
- Are the evaluation criteria for options clearly stated before scoring?
- Does the recommended option actually score best on those criteria, or is there a clear rationale if not?
- Are sensitivities and downside scenarios clearly addressed in the recommendation section, not just buried in an appendix?
- Are risks treated with symmetry: big upside accompanied by clear big downside, not just linear optimism?
Coherence QA – labelling and narrative
- Option names, initiative names, KPI labels, and risk names are identical across:
- Text
- Charts and tables
- Appendices and model
- Dates and timelines agree across:
- Roadmap
- Cost model
- Benefits ramp
- Funding schedule
- Terminology is consistent (e.g., “digital onboarding platform” vs “customer portal” vs “DX 2.0”). Pick one term and stick with it.
A helpful technique: ask someone not on the core team to read the executive summary plus one or two key sections and simply list every inconsistency or thing that doesn’t add up. Fix all of them.
21.4 Step-by-Step Approval Process Guide
This is the practical choreography from “we think the case is ready” to “decision taken and documented.” Adjust the timings to your reality, but keep the sequence.
Step 1 – Map the formal path
Write down:
- Which bodies must review and in what order (e.g., Architecture Council → Risk Committee → ExCo → Board).
- Which ones are advisory vs approving.
- Deadlines for materials for each forum (e.g., “Board pre-read T-7 days”).
Build this into a simple table or timeline and share with the sponsor and PMO.
Step 2 – Lock the “decision version” of content
Pick a version (e.g., v1.0) that will go to the first formal approval body. This version includes:
- Executive summary.
- Full core deck or memo.
- Economics, risk, and implementation sections.
- Key appendices and assurance notes.
From this point on:
- Any material change increments the version (v1.1, v1.2…).
- You maintain a short change log: what changed and why.
Step 3 – Complete pre-wires and assurance sign-offs
Before the first formal forum:
- Confirm finance, risk/compliance, security/privacy, and architecture have reviewed the near-final version (or the elements relevant to them).
- Obtain short written assurance notes (even if they are just emails summarized into an appendix).
- Resolve must-fix comments; for disagreements you can’t resolve, document them explicitly (“Finance prefers conservative adoption assumptions; management case differs as follows…”).
Step 4 – Submit to the first decision forum
Follow the house rules:
- Respect page limits and submission cut-offs.
- Include a cover note stating:
- Decision requested.
- Options considered.
- Recommended option and rationale.
- Any conditions already agreed with assurance functions.
Coordinate with the meeting secretary:
- Confirm slot length, position on the agenda, and focus (inform, discuss, decide).
- Ask how materials will be distributed; verify the correct files and versions.
Step 5 – Run the meeting for a decision, not a show-and-tell
On the day:
- Sponsor opens with a crisp 2–3 minute pitch: decision, rationale, economics, and top risks.
- Case lead walks through only the critical exhibits (options grid, economics bridge, risk summary, roadmap & gates).
- Finance and Risk/Compliance each have a brief moment for reassurance or flagged concerns.
- Majority of the time is Q&A and discussion; you don’t need to “cover every slide.”
Your job is to:
- Answer questions crisply with references to data/model as needed.
- Note conditions, actions, and follow-ups in real time.
- Clarify the exact decision being made before the chair moves on.
Step 6 – Document the decision and conditions
Immediately after:
- Summarize outcomes in a short decision note or email:
- Approved / Declined / Re-work & return.
- Funding envelope and any tranches approved.
- Conditions (e.g., additional control X, revised scenario Y, return at Gate 1 with pilot results).
- Named owners for key follow-ups and due dates.
- Ensure the meeting minutes (if formal) capture these points.
- Update the case pack (if needed) with a “Decision & Conditions” page for future reference.
Step 7 – Cascade to subsequent forums if needed
If your path includes multiple layers (ExCo then Board, etc.):
- Incorporate any ExCo conditions or refinements into the Board variant of the pack.
- Preserve core numbers and logic; don’t spin a different story.
- Re-run a light QA step for consistency.
Step 8 – Transition from “case” to “program”
Once the final approval is granted:
- Hand off key artifacts to the program/initiative team: roadmap, benefits register, risk register, KPIs, governance schedule.
- Confirm the first 90-day plan and governance cadence are in calendars.
- Store the approved case and decision notes where they will be easy to find for audits and post-implementation reviews.
At this point, the business case has done its job; the implementation and benefits realization machinery takes over.
21.5 Submission & Q&A Checklist
Use this right before you hit “send” on the pack and before you walk into the room.
Submission readiness
- The decision and ask are clearly stated in the executive summary and cover note.
- The correct decision body and date are identified; submission deadlines are met.
- Version number and date are updated on all core files (deck, memo, model).
- Finance, Risk/Compliance, Architecture/IT, and Legal/Security (as relevant) have reviewed and are not sitting on major unresolved objections.
Pack integrity
- Executive summary is consistent with body and appendices (no mismatched numbers or labels).
- Options, economics, and risk sections all refer to the same option names, horizons, and metrics.
- All cross-references to appendices are correct; those appendices exist and are up to date.
- No obviously extraneous or outdated slides/sections remain from earlier drafts.
Numbers and model
- NPV, IRR, payback, total costs, and total benefits in the pack match the decision-version model.
- Sensitivities and scenarios in the pack correspond to real model runs (not “illustrative only” unless clearly marked).
- Any rounding differences are minimal and not confusing; where necessary, you note whether numbers are shown in whole units, thousands, or millions.
Risks, controls, and conditions
- Top risks and residual risk are clearly presented and consistent with the risk register.
- Key dependencies are visible (not just buried in an appendix).
- Any conditions proposed by finance, risk, security, or legal are summarized in the recommendation (“approve subject to…”).
Storyline and structure
- The pack tells a coherent story if read in this order: Executive Summary → Problem/Why now → Options → Economics → Risks → Implementation → Ask.
- Titles are message-oriented, not labels (e.g., “Option B maximizes NPV with controlled risk” vs “Option B”).
- You can explain the entire case in 3–5 minutes using only the executive summary and 3–4 key exhibits.
Q&A preparedness
- You and the sponsor can answer, without hesitation:
- “What happens if we don’t do this? What breaks or is foregone?”
- “Why this option and not the cheaper/slower/faster alternative?”
- “Which 2–3 assumptions matter most and what if they are wrong?”
- “How does this interact with other major initiatives or constraints?”
- “What would make you pause or stop this after approval?”
You should also have ready, ideally in a short Q&A back-up pack:
- A breakdown of costs and benefits by major driver.
- Downside/stress scenario economics.
- A one-page architecture or process view (for tech/ops cases).
- A condensed risk and controls summary.
After the meeting
- A short decision note or summary is drafted within 24 hours and aligned with the sponsor.
- Conditions and follow-ups are tracked with owners and due dates.
- The approved case is archived in an accessible location with a clear label and version.
If you can walk down this checklist with honest “yes” answers, you’ll enter the approval process with the two things that matter most: no surprises for decision-makers, and no unpleasant surprises for you.
