The method

Keystone is a structured methodology for delivering ERP and digital transformation programmes end-to-end. Twenty stages across six governance phases, from problem definition to long-run optimisation — typically eighteen to twenty-four months, with around eight to ten days of executive commitment across the full lifecycle.

It is opinionated about the things most methodologies blur — role distinctions, gate definitions, testing levels, adoption — and structured to make the work visible at the right level of detail at every point.

This page is the map. Each section below has a dedicated page with the detail.


The lifecycle: six phases, twenty stages

Six governance phases, each named for the question it answers.

  • Pre-Programme · Stages 0–5 · ~12 weeks. Should we do this, why, and on what evidence? Problem framing, vision, value definition, governance, execution enablement, benefits baselining.
  • Selection · Stages 6–9 · 17–24 weeks. What are we buying, from whom, at what cost? Funding envelope and benchmark costs, market engagement, software selection, SI selection.
  • Setup & Design · Stages 10–12 · 12–18 weeks. What exactly are we building, and is the business case still good? Programme mobilisation, discovery, solution design, Full Business Case.
  • Build & Test · Stages 13–14 · 14–24 weeks. Build it, test it, prove it works.
  • Deploy · Stages 15–17 · 8–14 weeks. Cutover planning, deployment and go-live, hypercare and stabilisation.
  • Post-Programme · Stages 18–19 · 12–26 weeks formal, then ongoing. Did we get what we paid for, and what's next? Benefits realisation and review, optimisation and maturity.

Read the lifecycle in detail →


Two real Board Gates, one Executive Go/No-Go, four business case checkpoints

The lifecycle has three kinds of decision point. Most methodologies blur them; Keystone names them.

  • Two Board Gates — binary, binding, board-level. Gate 1 at the end of Funding Envelope & Benchmark Costs (S6): proceed into market. Variance ±30–40%. Gate 2 at the end of Solution Design & Full Business Case (S12): commit to build. Variance ±10–15%. The final investment decision before build begins.
  • One cutover Go/No-Go — binary, binding, the Executive Sponsor's call. End of Cutover Planning (S15) / start of Deployment & Go-Live (S16). Cutover does not start without it.
  • Phase Checkpoints — forum reviews, not binding go/no-gos. Reviewed by the Steering Committee or Design Authority. Items not yet evidenced are formally accepted with rationale, never waved through.

The four business case checkpoints — at Value Definition & Case for Change (S2), Funding Envelope (S6), SI Selection (S9) and Full Business Case (S12) — sit alongside the gate structure, not on top of it. Benefits are established at S2; costs firm up across S6, S9 and S12. Don't commit to costs at S6 you can only justify at S12.

Read gates and the business case in detail →


Eight testing levels with explicit role distinctions

Most ERP methodologies have four or five test phases. Keystone has eight — Unit, FAT, Mini-BAT, SAT, SIT, UAT, BAT and NFT — with explicit role distinctions for who executes each and who signs it off.

Sequence: Unit → FAT → Mini-BAT → SAT → SIT → UAT → BAT, with NFT running in parallel with BAT and validated against the same functionality.

Each level has a different purpose, a different audience, and different exit criteria. UAT is executed by users — actual people who will use the system — not by Process Owners. BAT is unscripted business-readiness testing, signed off by Benefit Owners. NFT is its own level, not a footnote: performance, security, disaster recovery and batch failures are some of the worst go-live failures, and they don't surface in UAT.

Read the testing framework in detail →


Roles, named and distinguished

Keystone names role distinctions most methodologies blur.

  • Process Owners are not SMEs. Process Owners own the business outcome and sign off the work; SMEs know how the work is currently done. They are not interchangeable.
  • Programme Managers are not Project Managers. Programme Managers run the whole; Project Managers run workstreams from Programme Setup & Mobilisation (S10) onward. Project Managers are not present in Pre-Programme or Selection because there are no workstreams yet.
  • Benefit Owners are named at Value Definition & Case for Change (S2), not at the end. By Benefits Realisation & Review (S18) they are the people accountable for the benefits, and that accountability needs months to build, not weeks.
  • Three governance bodies, with defined active periods. Executive Sponsor Group from Phase 1 Week 1, full lifecycle. Steering Committee from Phase 3 Week 12, monthly through Design Governance & Sponsorship (S3) to S18. Design Authority from end of SI Selection (S9), bi-weekly through S9–S17.

Read the role catalogue and governance →


Adoption as a governed workstream

Adoption is treated as a work product with stage-gate criteria, not a soft-skills afterthought in the closing weeks. Stakeholder analysis, communications strategy, training planning, train-the-trainer cascades and reinforcement are sequenced across the lifecycle and reviewed formally.

The Change Lead is named from Benefits & Continuous Alignment (S5) onward; the Training Lead from Programme Setup & Mobilisation (S10) onward; train-the-trainer cascades through Testing (S14) into Deployment & Go-Live (S16); reinforcement runs across hypercare. Adoption is not the last 5% of the programme. It is a parallel track with its own measurable exit criteria.

Read the adoption workstream →


Pre-drafted artefacts, not blank pages

Keystone arrives at workshops with structured starting points — vision drafts, value definitions, governance terms of reference, RFI templates, design templates. The conversation is "is this draft right?", rather than "what should we do?".

The artefact library is openly downloadable, in editable formats. Adapt them, fork them, use them as inputs to your own workshops.

Read the artefacts page →


Delivery patterns

The methodology bends along two axes — how the work is sequenced (single-wave vs multi-wave) and how the work is delivered inside the stages (Hybrid vs Agile vs Waterfall). Both are explicit, and both have a default position.

Hybrid (Enough Design Up Front) is the default

Pure Agile is rare for ERP because finance close, master data, integration sequencing and Solution Design & Full Business Case (S12) firm pricing are not iterable. Pure Waterfall is dead because Process Owners need to see configuration in flight rather than at UAT.

Keystone's default is Hybrid (EDUF): Selection waterfall, Setup & Design EDUF, Build agile sprints inside Build & Configuration (S13), Test waterfall through Testing (S14), Deploy waterfall through the Deploy phase (S15–S17). EDUF means designing enough up front to lock the business case, integration patterns, data architecture and chart of accounts; deferring detail (workflow nuance, report layouts, screen variants) to Build sprints.

Single-wave or multi-wave

Most PLC-scale programmes are multi-wave. The methodology bends explicitly: Pre-Programme, Selection and Programme Setup & Mobilisation (S10) run once for the whole programme. Discovery (S11) surveys the whole estate (not Wave 1 only). Solution Design & Full Business Case (S12) locks the global template once, with Wave 1 firm at ±10–15% and Waves 2 onwards indicative with re-baseline gates between waves. Build & Configuration (S13) through Hypercare & Stabilisation (S17) then repeat per wave — Wave 1 full, subsequent waves abbreviated against the global template.

"Wave" can mean regions, brands, business units, functions (Finance → Logistics → CRM), or pilot-then-scale. The pattern is the same regardless of what defines the wave.

Read the lifecycle in detail →


Try the methodology on your own programme.

The Command Centre is the methodology turned into a tool. Open it now and run it against your own programme. No sign-up, no gate.

Open the Command Centre

Or talk through where you are. Book a 30-minute call →