Who does what, when, and how the programme actually meets.

Three named distinctions

The roles 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. A Process Owner makes decisions about how a process should run in future; an SME explains how it runs today. Programmes that conflate them end up with decisions made by people without the authority to make them, or with authority sitting with people who don't have the context to use it.

Programme Managers are not Project Managers

The Programme Manager runs the whole — strategic alignment, governance, benefits realisation, the Steering Committee. Project Managers run individual workstreams. Project Managers are not present in Pre-Programme or Selection because there are no workstreams yet to run; they join at Programme Setup & Mobilisation (S10) onward, per workstream. Staffing them earlier is one of the most common and most expensive structural errors in ERP delivery.

Benefit Owners are named at Value Definition (S2), not at the end

One Benefit Owner per business benefit, accountable through to Benefits Realisation & Review (S18) reporting. Naming them at Value Definition & Case for Change (S2) means they own the baseline measurements before any system change, and the benefit projections that go into the Funding Envelope and the Full Business Case are signed off by the people who will be accountable for delivering them. Naming them in S18, when the programme is closing, produces accountability that has had no time to build.

Client-side roles

By when they join

Full lifecycle

• Executive Sponsor. Single point of executive accountability. Chairs the Executive Sponsor Group. Owns the cutover Go/No-Go decision at the end of Cutover Planning (S15). Full lifecycle.
• Programme Manager. Owns the programme end-to-end — strategic alignment, governance, benefits realisation, Steering Committee secretariat. Full lifecycle, from Pre-Programme through Post-Programme.
• Business Architect. Owns the business architecture across the lifecycle — current-state analysis in Pre-Programme, business-design alignment through Setup & Design, benefits validation in Post-Programme. Full lifecycle. Scales with functional-area count — 1 on small programmes, 1–3 on medium (per major functional area), 1 per functional area on large (typically 4–6 BAs). Where multiple BAs exist, a Lead BA carries cross-domain Accountable duties; individual BAs are Accountable for domain-specific decisions.

Identified in Pre-Programme, active across the lifecycle

• Solution Architect (Client side). Vision & Strategy (S1) onward. Owns the Enterprise AS-IS Assessment Summary (signed off at Value Definition & Case for Change (S2)) plus four supporting diagrams: Estate-on-a-Page, Integration-on-a-Page, Capability Heatmap, Dependency Tree. Time-boxed: 4–6 weeks of dedicated effort during S1–S2, not slack capacity. The work feeds the Case for Change and anchors Solution Design at S12. Co-chairs the Design Authority with the SI Solution Architect from SI Selection (S9). Active through hypercare. AS-IS capability risk applies — see callout below.
• Benefit Owners. Named at Value Definition & Case for Change (S2) — one per business benefit. Active in Benefits Realisation & Review (S18) reporting; continue into BAU.
• Data Lead. Value Definition & Case for Change (S2) onward. Client-side coordinator of the Data workstream end-to-end. Owns the cross-domain rhythm of Data Hygiene during Pre-Programme and Selection — Data Owners own their domain, the Data Lead owns the workstream. Partners with the SI Data Migration Lead from Programme Setup & Mobilisation (S10) as the Client-side counterpart through cutover and post-go-live validation. Active through Hypercare & Stabilisation (S17).
• Data Owners. Named at Value Definition & Case for Change (S2) — one per master-data domain (customers, suppliers, products, employees, GL, etc.). Own data hygiene in their own domain; coordinated by the Data Lead. Partner with the SI Data Migration Lead from Discovery (S11) through cutover.
• Change Lead. Benefits & Continuous Alignment (S5) onward. Stakeholder analysis, communications strategy and adoption planning during Pre-Programme exit; ramps as the team grows; active through hypercare.
• Process Owners. Identified at Execution Enablement (S4) and Benefits & Continuous Alignment (S5); participate in Software Selection (S8) scripted demos (one named per process stream); formally embedded in workstreams from Programme Setup & Mobilisation (S10); active through hypercare.

Delivery roles (from Programme Setup & Mobilisation, S10)

• Project Manager(s). Per workstream, from Programme Setup & Mobilisation (S10) onward. Not present in Pre-Programme or Selection — too early, no workstreams yet.
• Training Lead. Programme Setup & Mobilisation (S10) through Deployment & Go-Live (S16). Owns the training strategy, materials and the train-the-trainer programme.
• Client Test Manager (sometimes called the Client Test Lead). Discovery (S11) through Hypercare & Stabilisation (S17). Owns the test strategy across SIT, UAT, BAT and NFT coordination, runs the testing programme, manages the defect process.
• Trainers (train-the-trainer cohort). Testing (S14) through Deployment & Go-Live (S16). Trained via train-the-trainer; cascade end-user training pre-go-live and during hypercare.

Cutover and post-go-live

• Cutover Lead. Testing (S14) through Deployment & Go-Live (S16). Owns the cutover runbook with the SI Cutover Lead counterpart. Co-owned because cutover crosses business and IT.
• Site Readiness Lead (optional — multi-site / multi-region / multi-brand programmes only). Testing (S14) through Hypercare & Stabilisation (S17), per site or per wave. Sits on site and pre-prepares the site for rollout: infrastructure readiness, Super User identification and training, liaison with site senior management, site tours for the programme team. The local face of the programme during cutover and hypercare for that site. Common in distributed estates — manufacturing sites, builders' merchants branches, retail regions, multi-brand rollouts. Single-site programmes don't need this role; Cutover Lead and Hypercare Lead cover its responsibilities.
• Hypercare Lead. Deployment & Go-Live (S16) through Hypercare & Stabilisation (S17). Often the Programme Manager extending; can be a dedicated role on larger programmes.
• Platform / Application Owner. Deployment & Go-Live (S16) onwards (BAU). Takes handover from the programme; owns the optimisation backlog and platform roadmap into Optimisation & Maturity (S19).

SI-side roles

Joining from Programme Setup & Mobilisation (S10) unless noted

SI roles join from Programme Setup & Mobilisation (S10) onward unless noted otherwise. The Method is written from the Client's point of view; SI roles are explicitly prefixed so sign-off chains stay unambiguous.

• SI Programme Director. Programme-level accountability on the SI side. Counterpart to the Client Programme Manager.
• SI Solution Architect. SI Selection (S9) onward — joins at SI Selection so the architecture conversation starts before the contract is signed. Co-chairs the Design Authority with the Client Solution Architect.
• SI Functional Leads. One per functional workstream (Finance, SCM, Sales, Service etc.). Lead build, support FAT/SAT/SIT/UAT, triage functional defects.
• SI Functional Consultants. Specialists per sub-process within a workstream — e.g. within a Finance workstream: AP, AR, Assets, GL, Treasury, Tax each with a named consultant, all reporting to the SI Finance Functional Lead. Scales with programme size: 0–1 per workstream on small, 1–2 on medium, multiple per workstream on large. The Functional Lead can credibly hold one workstream end-to-end on a small programme; on a 1,500-user programme they need named specialists.
• SI Technical Lead. Owns technical architecture, integration build, technical defect resolution. On large programmes often split into Integration Lead + Infrastructure Lead under a Technical Programme Lead.
• SI Data Migration Lead. Owns data migration design, build, dry runs and cutover. Partners with Client Data Owners.
• SI Test Lead. Runs SAT, supports SIT under the Client Test Manager. Distinct from the Client Test Manager — always qualify the prefix.
• SI Scrum Master. Sprint-level facilitation during Build & Test.
• SI Cutover Lead. Testing (S14) through Deployment & Go-Live (S16). Owns the technical cutover runbook with the Client Cutover Lead counterpart.

For deeper per-role detail — typical seniority, what each role does beyond the timing/scope, common failure modes — open Roles by Phase in the Command Centre. The catalogue above stays compact; the Command Centre is the single deep surface for role detail and stays in lockstep with the canonical reference.

How roles multiply by scale

The role catalogue names roles in their canonical singular form. In practice, several roles multiply with programme scale. A single Business Architect can credibly carry one functional area; they cannot credibly carry six. A single SI Functional Lead can hold one workstream end-to-end on a small programme; they cannot hold every named sub-process within Finance (AP, AR, Assets, GL, Treasury, Tax) on a 1,500-user programme.

Sizing isn't just headcount — it's who can hold a process / module / sub-process domain credibly under load. Three size bands:

When more than one of a role exists, name a Lead. Multiple Business Architects → Lead BA carries cross-domain Accountable duties on RACI; individual BAs are Accountable for domain-specific decisions. Same pattern for Lead Functional Consultant within a workstream Functional Lead's team, Lead SA where multiple module SAs sit, Lead Project Manager on the largest programmes where several PMs need coordination beyond what the Programme Manager carries directly.

Common mistake. SI bids on small-programme sizing with a "one Functional Consultant per workstream" model when the programme is actually medium-to-large. The named consultant becomes the bottleneck mid-build, change requests pile up to add specialists, and the Full Business Case at S12 no longer holds. Sizing the team honestly at Programme Setup & Mobilisation (S10) — and naming Leads where roles multiply — is part of the mobilisation deliverable, not a discovery later.

Senior stakeholders

Gate-focused, not on the team day-to-day

Senior stakeholders aren't on the programme team day-to-day, but their attendance at the relevant gate is non-negotiable. They make decisions the programme team cannot make on its own.

• CFO / Finance Lead. Funding Envelope at Gate 1; Full Business Case at Gate 2; benefits realisation review at Benefits Realisation & Review (S18).
• CIO / IT Director. Solution architecture decisions; NFT exit; integration with the wider IT estate.
• Procurement Lead. Active Stages 6–9 — RFI, software selection, SI selection, contracts.
• Legal / Commercial. Active at gates 6, 9, 12, and at SI contract exit.
• Risk & Compliance Lead. Active at every binding gate — Funding Envelope, Full Business Case, cutover Go/No-Go.

The methodology's hardest unstated assumption

Keystone assumes a capable Client Solution Architect can deliver the AS-IS Assessment Summary and its four supporting diagrams during Pre-Programme. In practice this assumption fails frequently. Most Client-side Solution Architects are good in their own platform domain but under-powered for cross-estate enterprise mapping, lack the political clout to extract data from peer domains, or have only slack capacity rather than the 4–6 weeks of dedicated effort the work needs.

The four AS-IS deliverables

Signed off at Value Definition & Case for Change (S2). Each is one page, exec-readable, complex enough to inspire belief but simple enough to read in five minutes:

• Estate-on-a-Page — single business-reference architecture stripped to layers a COO recognises: Customers → Channels → Operating processes → Master data → Platforms → Infrastructure.
• Integration-on-a-Page — interfaces between systems with traffic-volume and reliability annotations. The exec sees the spaghetti.
• Capability Heatmap — current capability per business function, RAG-coloured against target capability. The exec sees where the gaps are.
• Dependency Tree — what needs to be retired / replaced / kept; what depends on what.

These four feed into the Enterprise AS-IS Assessment Summary — exec-readable, ~10–15 pages, the artefact the Sponsor and senior team use to pressure-test the strategic alignment and back the Case for Change.

Trigger, escalation, owner

Trigger: Client SA hasn't delivered against the named milestones, or has delivered superficial work — bullets in a deck, no real depth. The trigger is evidence-based, not impression-based: the four deliverables either exist at the required quality by end of S2, or they don't.

Escalation path: if the trigger fires, the decision goes to the Head of Enterprise Architecture / CIO / COO (per the org's structure). Named in the Programme Charter at Execution Enablement (S4) as a defined risk-escalation route.

Risk owner: this is a skill, knowledge and experience risk that needs a named owner. Either the Sponsor, the Programme Manager, or the Head of EA themselves puts their neck on the line that the Client SA can carry the role. If they can't, the same person owns the call to bring in external help, scope down, or pause.

Response options when the trigger fires

In order of methodology preference:

1. Augment with external EA expertise during S1–S2. External EA does the heavy lifting; Client SA assists, inherits the artefacts, and continues from Design Governance & Sponsorship (S3) onwards. Budget separately as part of Pre-Programme spend. Works only if the talent market makes this realistic.
2. Scope down what the methodology assumes the SA delivers. Explicitly accept the AS-IS gap as a programme risk in the RAID register, with mitigations: heavier Discovery (S11), wider FBC variance buffer at S12, more contingency in build estimates.
3. Pause Pre-Programme until the EA capability question is resolved at the right org level. The right answer when the AS-IS gap is too wide to scope down and external help isn't available.

Why this matters commercially. Programmes that skip serious AS-IS work pay for it twice — at the Full Business Case (variance wider than the methodology pretends) and at Discovery + Build (surprise dependencies driving change requests at SI day rates). External EA augmentation in Pre-Programme is often cheaper than the change requests it prevents.

Governance bodies

Three formal bodies, with defined cadence

Three formal governance bodies run alongside the staged lifecycle. Each has a defined formation point, an active period, and a meeting cadence. Drift on cadence is one of the most reliable early signs that governance is breaking down.

Executive Sponsor Group. Chaired by the Executive Sponsor. Full programme leadership representation. Owns the binding decisions: Funding Envelope at Gate 1, Full Business Case at Gate 2 (with the Board), the cutover Go/No-Go (with the Sponsor making the call). Forms in week one because the governance has to exist before the programme has anything to govern; establishing it later is hard.

Steering Committee. Chaired by the Executive Sponsor. Programme Director, workstream Project Managers, Solution Architects (Client and SI), key business representatives. Reviews progress, risks, decisions needing escalation. Forms when the programme has enough work to review (Phase 3, Week 12) and runs monthly through go-live and Post-Programme. Transitions to BAU governance at Optimisation & Maturity (S19).

Design Authority. Co-chaired by the Client Solution Architect and the SI Solution Architect. Reviews and approves all functional design documents (FDDs), integration design, data migration design, security architecture. Forms at the end of SI Selection (S9) — once the SI is selected and the SI Solution Architect joins — and runs bi-weekly through hypercare. Approves the Design Sign-Off checkpoint within Solution Design & Full Business Case (S12), which precedes Board Gate 2.

Programme cadence

How the programme actually meets, week to week

The Method describes governance bodies and gates. The programme also has to meet, decide and change things week to week — that's the operational layer where most ERP programmes succeed or fail. The cadence is set up at Programme Setup & Mobilisation (S10) and runs through to Hypercare & Stabilisation (S17).

A note on "per workstream" — a workstream is a deliberately-scoped slice of programme delivery with its own Project Manager. Programmes structure them differently: by discipline (Functional, Data, Integration, Test, Cutover, Change), by module (D365 F&O, D365 CE, SAP FI), by business process (Order-to-Cash, Procure-to-Pay), or by business function (Finance, Supply Chain, Procurement). Hybrid is the norm. The structure is decided at S10 and reflected in the Programme Charter.

Agile ceremonies — Build only

Agile ceremonies run inside Build & Configuration (S13) only. Sprints typically last two to three weeks. The ceremony stack is the standard Scrum set:

• Sprint Planning at the start of each sprint
• Daily Stand-up (replaces or merges with the workstream stand-up)
• Sprint Review with Process Owner show-and-tell — FAT acceptance happens here
• Sprint Retrospective
• Backlog Refinement mid-sprint

Sprints stop at the end of Build & Configuration (S13). Testing (S14) reverts to waterfall — the testing pipeline (SAT → SIT → Pre-UAT → UAT → BAT, with NFT in parallel) is gate-driven, not iterable. The Deploy phase (S15–S17) is also waterfall — cutover plans cannot be iterable.

Change control

Four levels, decided by what's changing — not by size

Change control is set up at Programme Setup & Mobilisation (S10) and signed by both Client and SI as the Change Control Procedure, referenced in the SOW. Setting it up reactively at Build & Configuration (S13) when the first change request appears is a recurring failure: by then it's chaos, no audit trail, no log, and the Client / SI argue about what was always agreed.

The trigger for a Change Request form is "does it change a contracted deliverable, the SDD, scope, cost or timeline" — not size in days.

The flow in practice

Change is surfaced in sprint review, DevOps stand-up or Process Owner forum → triaged as defect (SI fixes under SOW), clarification (log decision) or change (raise CR) → CR drafted by SI Functional Lead with Process Owner co-sign and SI effort estimate → DA approves the design change → Steering approves if the cost or time impact is material → SDD updated, sprint backlog updated, build executes.

Common rule of thumb for triggering a CR

Any one of the following triggers a CR:

• SDD change
• More than five SI days of effort
• Any contracted-deliverable change
• Any cost, time, benefit or scope movement

Anything below all four is sprint-level discretion. The threshold is set in the Change Control Procedure authored at Programme Setup & Mobilisation (S10) and signed by both sides.

What does not need a CR

• Defect fixes — SI obligation under the SOW, not change
• Sprint-level configuration discretion within the agreed design
• Test data corrections
• Documentation updates
• Internal SI process tweaks

Recurring bad habits

To correct on sight

Nine things that go wrong with roles, governance and change control 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.

• Splitting the Executive Sponsor role across two or more people. Dilutes accountability and gives every named "sponsor" plausible deniability. The Sponsor is the single point of executive accountability for the programme — one person, named, full lifecycle. The Executive Sponsor Group is where the broader senior stakeholder set sits; multiplying the Sponsor itself is not a way to involve more people, it is a way to involve none of them properly.
• Naming Project Managers in Pre-Programme. Wastes resource and creates the wrong reporting structure for the work that actually needs doing. Project Managers from Programme Setup & Mobilisation (S10), per workstream, not earlier.
• Conflating Process Owners with SMEs. Either decisions get made by people without authority, or authority sits with people without context. Name them as separate roles, with separate accountabilities, from Execution Enablement (S4) onward.
• Naming Benefit Owners at the end of the programme. Produces accountability that has had no time to build. Value Definition & Case for Change (S2) is when Benefit Owners are named — they own the baselines, the projections and the post-go-live measurement. By Benefits Realisation & Review (S18) the relationship needs months, not weeks.
• Forming the Steering Committee before there is anything to steer. A Steering Committee that meets monthly during Pre-Programme is a Steering Committee that has fallen out of the habit by Solution Design & Full Business Case (S12). Form it in Phase 3, Week 12.
• Skipping the Design Authority because "the SI handles design." The Design Authority is the Client's mechanism for taking accountability for the solution being built. Without it, the Client has no formal sign-off on the design that will define the next decade of the platform. Co-chair it; don't outsource it.
• Drifting on governance cadence. Steering Committees that slip from monthly to "when needed" are programmes where the governance has stopped governing. Hold the cadence even when the agenda feels light — the agenda fills up faster than anyone expects.
• Setting up change control reactively at Build & Configuration (S13). By the time the first change request appears, the team is arguing about what was always agreed. The Change Control Procedure goes in at Programme Setup & Mobilisation (S10) and is signed by both Client and SI before build begins.
• Treating change control as a CR-form gatekeeper rather than a tiered process. Routing everything through a CR — including configuration discretion within the agreed SDD — slows build to a crawl and reduces engagement with the formal process when it actually matters. Use the four-level flow: most decisions are Level 1 or Level 2 and don't need a form; reserve CRs for Level 3 and Level 4.