Two real gates. One Sponsor's call. Everything else is a checkpoint.

Three tiers

The three kinds of decision point, named and distinguished

The lifecycle has three kinds of decision point, deliberately not interchangeable.

• Tier A — Board Gate. Two only. Binding. Binary go/no-go. The Board approves or refuses; the programme cannot continue without sign-off.
• Tier B — The Executive Sponsor's cutover Go/No-Go. One only. Binding decision, but the Executive Sponsor's call rather than the Board's. Cutover does not start without it.
• Tier C — Phase Checkpoint. Several. Forum reviews, not binding go/no-gos. Confirm exit and entry criteria before the next phase begins. Items not yet evidenced are formally accepted with rationale, never waved through.

Plus one event marker — Go-Live, within Deployment & Go-Live (S16). Not a gate. The system goes live; hypercare begins.

Board Gate 1

End of Stage 6 · Funding Envelope

Decision: approve the funding envelope and proceed into market.
Variance at this point: ±30–40%.
Evidence required: benchmark costs developed against the Value Definition & Case for Change (S2) benefits side; comparable-programme reference data; sponsor-signed problem statement; vision aligned to organisational strategy; named Benefit Owners and Data Owners.

The variance at Funding Envelope (S6) is wide deliberately. Benchmarks aren't pricing — they are envelope-sizing. Treating Gate 1 as a final number is the most reliably expensive mistake in ERP delivery, because the Board commits to a figure that hasn't yet been pressure-tested against a vendor or a Solution Design.

If Gate 1 fails, the programme stops here. A different conversation begins — usually about the problem statement, the strategic alignment, or whether the timing is right. None of that is wasted work. Most of it is reusable when the conditions improve.

If Gate 1 passes, the programme is real. Selection begins.

Board Gate 2

End of Stage 12 · Full Business Case

Decision: commit to build. Final investment decision before any configuration work starts.
Variance at this point: ±10–15%.
Evidence required: Solution Design Document signed off by Design Authority; integration design; data migration design; firm or capped SI build & test pricing; refined benefits projections against the Solution Design; refined Benefits & Continuous Alignment (S5) measurement framework; named Client Test Manager.

Gate 2 is the most consequential decision point in the entire lifecycle. Everything before it has been preparation; everything after it is execution. Reversing the decision after Solution Design & Full Business Case (S12) is expensive in cash, time and political capital.

Two failure patterns matter here. First, treating Gate 2 as a soft milestone — letting it pass on the assumption that the Funding Envelope (S6) already authorised the build. It didn't. S6 authorised the envelope. S12 authorises the commitment. Different decisions, different evidence, different variance. Second, slipping the Full Business Case until after build has started, on the grounds that "we'll firm it up as we go." Build has unrecoverable spend. The Full Business Case must be confirmed before build begins, not during it.

If Gate 2 passes, build begins. If it fails, the programme returns to design, descopes, or pauses. None of those are failures of the methodology — they are exactly the kinds of decisions Solution Design & Full Business Case (S12) exists to enable.

Multi-wave note

For multi-wave programmes, Gate 2 covers all waves with two pricing positions: Wave 1 firm at ±10–15%, Waves 2 onwards indicative, plus explicit per-wave re-baseline gates as each subsequent wave firms up. The Board commits to Wave 1 firm; Waves 2 onwards return for re-baselining as actual scope and learnings emerge.

The failure mode here is acute: programmes that present Solution Design & Full Business Case (S12) as "the business case for the whole programme" without distinguishing Wave 1 firm from Waves 2 onwards indicative end up at Wave 3 with creeping costs that no-one re-papered to the Board. Lock the Wave 1 number, document the Waves 2 onwards range, and commit to the per-wave re-baseline cadence at Gate 2 itself.

Vendor service tier in the Full Business Case

Cloud deployments carry a third commercial line: the platform vendor's service tier. The Full Business Case at Solution Design & Full Business Case (S12) must factor that cost. Paid tiers — Microsoft Premier / Unified Support, SAP Enterprise Support, Oracle Premier — are firm line items. Free accelerated tiers like Microsoft FastTrack for Dynamics 365 must be qualified for and locked in at Programme Setup & Mobilisation (S10) to be exercised; surfacing the tier question at Gate 2 is too late to negotiate either eligibility or price.

Executive Go/No-Go

End of Stage 15 · The Executive Sponsor's cutover Go/No-Go

Decision: proceed with cutover.
Decision-maker: Executive Sponsor.
Evidence required: all test-level exit criteria met; Dry Run 2 completed at full volume with reconciliation; cutover runbook rehearsed; NFT exit certificate; Hypercare Lead in place; communications cascade ready.

The cutover Go/No-Go sits between Cutover Planning (S15) and Deployment & Go-Live (S16) because cutover is operationally unforgiving. Once data starts migrating to production, the cost of pulling back rises by the hour. The Executive Sponsor takes the call because the decision is fundamentally a judgement on operational readiness — and the Sponsor is the person accountable to the Board for that readiness.

Two reasons it isn't a Board Gate. First, the Board has already committed to build at Solution Design & Full Business Case (S12); cutover readiness is the operational consequence of that commitment, not a fresh investment decision. Second, the cutover Go/No-Go sometimes needs to happen quickly — within a working day — and the Board's cadence doesn't support that. The Sponsor is the right level of authority and the right speed of decision.

Phase Checkpoints

Forum reviews, not binding go/no-gos

Reviewed by the relevant body — Steering Committee, Design Authority, or both — at the point in the lifecycle they appear. The standard checkpoints are:

The discipline at each checkpoint is the same: items not yet evidenced are formally accepted with rationale, never waved through. The distinction matters. Waving through means the team agrees not to argue about it; formal acceptance means the gap is documented, owned, and tracked. The first is silent risk. The second is governed risk.

Business case maturity

Four checkpoints across the lifecycle

The business case is built across four checkpoints, not one. By the time the Board commits to build at Solution Design & Full Business Case (S12), the numbers have been refined four times — and refused if they wouldn't hold.

The Value Definition & Case for Change (S2) benefits work is the foundation everything else rests on. If benefits aren't quantified and baselined before Selection starts, Full Business Case (S12) has nothing to discount the SI's price against. The case for change becomes "we believe this will be valuable" — which is not a case for change at PLC scale.

The Funding Envelope (S6) envelope is wide on purpose; the SI Selection (S9) ROM narrows it; the Full Business Case (S12) firms it. Compressing this into a single business case at S12 — which is what most ERP methodologies do in practice — means the Board commits to costs that haven't been pressure-tested at the right intervals.

Where delay concentrates

The SoW transitions, not the technical work

The four business case checkpoints govern the numbers. The SoW transitions govern the commercial commitment — and across thirty-plus programmes those transitions are the most reliable concentration of delay and risk in the entire lifecycle. Second only, in some programmes, to testing itself.

Two SoW transitions matter most:

• Post-design SoW sign-off — at the end of Solution Design & Full Business Case (S12), alongside Board Gate 2. The SI converts the Solution Design and indicative pricing into a firm Build, Test, Deploy and Hypercare SoW. The move from indicative to firm exposes the cost gap between what was envelope-sized at Funding Envelope (S6), RFI-priced at Software Selection (S8), ROM-priced at SI Selection (S9), and what the SI can actually price now design is signed off. Programmes that haven't agreed the commercial framework in advance end up litigating it during this transition, which is where weeks slip into months.
• Build & Test SoW negotiation — running into and through Build & Configuration (S13). Even when the post-design SoW is firmed at Gate 2, the ramp into Build often surfaces re-scoping, change requests, dependency clarification and resource model changes that have to be re-papered. The negotiation around those changes is where decisions stall while the build team is already on the bench.

Both transitions can be planned for. Both are made worse by leaving the commercial framework to be negotiated in real time during the technical conversation. The Keystone position: SoW pricing positions and re-baseline triggers are agreed during Discovery (S11), with the multi-SoW commercial pattern (MSA Schedule plus SOW 1, 2 and 3) made explicit and signed before S12 closes. The post-design SoW conversation then becomes a confirmation, not a negotiation. The pre-drafted SoW Suite artefact set on the Pre-drafted artefacts page exists for exactly this reason — so the Client walks into the post-design conversation with the commercial structure already drafted, not waiting for the SI to bring it.

Recurring bad habits

To correct on sight

Six things that go wrong across ERP programmes, again and again. Each one feels reasonable when the decision is made; each one costs more than was saved. Correct on sight when you see them in your own programme.

• Calling Market Engagement & RFI (S7), SI Selection (S9), Discovery (S11) or Build & Configuration (S13) a "gate." They are checkpoints. The two real Board Gates are Funding Envelope (S6) and Solution Design & Full Business Case (S12). Inflating the count means the Board pays attention to things that don't warrant it and stops paying attention to the two that do.
• Renumbering gates per phase. "Setup & Design Gate 1/2/3" mapping to Programme Setup & Mobilisation (S10), Discovery (S11) and Solution Design & Full Business Case (S12) is a common deck pattern that drifts in. The canonical numbering is Gate 1 = S6, Gate 2 = S12, the Sponsor's cutover Go/No-Go = pre-Deployment & Go-Live (S16). Anything else is a checkpoint.
• Treating Solution Design & Full Business Case (S12) as a soft milestone. It is the second binding Board Gate and the final investment decision before build begins. Programmes that drift through S12 because Funding Envelope (S6) already approved the envelope are the same programmes that come back to the Board at Testing (S14) with a number that no longer matches the S6 figure.
• Treating the Go-Live decision as a Board Gate. It is the Executive Sponsor's binary cutover Go/No-Go, not a Board decision. The Board doesn't have the cadence to make a cutover-readiness call. The Sponsor does.
• Slipping the Full Business Case past Solution Design & Full Business Case (S12). "We'll firm it up as we go" is a polite way of saying "we'll commit to costs we can't yet justify." Build has unrecoverable spend. The case must be confirmed before build begins, not during it.
• Allowing Process Owners to run UAT. The Client Test Manager controls UAT. Users execute the scripts. Process Owners contribute and support — co-authoring scripts at Pre-UAT, validating coverage, supporting users, signing off acceptance per workstream — but they don't run the testing programme and they don't execute scripts themselves. When that line gets crossed, UAT produces paper acceptance with no operational signal, and the programme passes UAT but fails at go-live. Mentioned here because it is the user-side mirror of gate-inflation: the same governance failure in a different costume.