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. Cross-pillar in dual-pillar 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). Cross-pillar in dual-pillar 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. Cross-pillar in dual-pillar 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. Cross-pillar in dual-pillar 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). Cross-pillar in dual-pillar 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.

Architecture roles (from Discovery, S11)

• Integration Lead. Dual-pillar mandatory Discovery (S11) through Hypercare & Stabilisation (S17). Reports to Solution Architect. Translates the Estate-on-a-Page and Integration-on-a-Page (Solution Architect's Pre-Programme work) into programme-level integration requirements at S11; owns the integration architecture decisions at Solution Design & Full Business Case (S12) recorded as Architecture Decision Records; owns integration build and test from Build & Configuration (S13) through hypercare. Co-chairs an Integration Working Group with the SI Technical Lead during S11–S14 where integration footprint is substantial. Sizing: single-pillar small absorbs into SI Technical Lead; single-pillar medium+ named separately; all dual-pillar named separately. Common mistake: staffing the role from Build & Configuration (S13) when integration build starts, then discovering at S13 that the architecture wasn't designed for the integrations actually needed.
• Data Architect. Dual-pillar mandatory Discovery (S11) through Hypercare & Stabilisation (S17). Reports to Solution Architect. Owns the data model, integration data flows, master data ownership decisions and reference data design. Master data ownership is recorded as an Architecture Decision Record at Solution Design & Full Business Case (S12) — which means it has to be decided during S11–S12, not after. Partners with the Data Lead (workstream coordination) and Data Owners (per-domain hygiene); distinct from both. Sizing: all programme sizes. Small can be carried by the Solution Architect with named risk; medium+ named separately. Common mistake: assuming the Solution Architect carries it, finding at Solution Design (S12) that master data ownership was never properly decided and the SDD is signed off with a hole in it.

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 timing and scope, common failure modes, plus the thirteen named testing roles with reports-to and sign-off authority — open 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 Project Managers 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. Runs financial due diligence during S7–S9 as part of selection criteria, not as a separate post-selection exercise. Negotiates Master Services Agreement (MSA) terms during S9 alongside SOW 1 (Discovery). Signs off MSA and SOW 1 before Programme Setup & Mobilisation (S10) entry.
• Legal / Commercial. Active at gates 6, 9, 12, and at SI contract exit. Reviews the SI’s standard MSA during S9 and negotiates terms before Programme Setup & Mobilisation (S10) entry. Financial and insurance due diligence runs during S7–S9 alongside Procurement as part of the selection criteria, not after the SI is chosen.
• 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 sign-off at Gate 1, Full Business Case sign-off at Gate 2 (with the Board), and the cutover Go/No-Go endorsement — the Sponsor makes the binary call; the ESG is the forum that endorses it. 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. Owns design integrity, deviation approvals, and P2-with-workaround sign-off at go-live (with the relevant Process Owner). 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.

Reporting discipline — every reporter distils, not dumps

Programme reporting only works if every contributor understands they are part of a chain. Each reporting team member is responsible for summarising information at the right level of abstraction for the recipient, surfacing risks with named mitigations rather than just risk names, and flagging issues with proposed actions rather than just symptoms.

Sending a Programme Manager forty pages of detail and expecting them to extract the SteerCo-grade signal is not reporting — it is delegation of work the reporter should have done before sending. The Programme Manager's role is to integrate cross-workstream signal, not to remediate individual workstream reporting.

The discipline runs upward along the reporting chain. Each level distils what comes from below; each level surfaces what the level above needs to know:

• Workstream leads → Project Managers — summary of completed work, blockers with named owners, RAID items with mitigations
• Project Managers → Programme Manager — workstream status with material movement only; cross-workstream dependencies highlighted; commercial, scope or timeline implications named
• Programme Manager → Steering Committee — exception-based, decisions-requested, executive-level summary with the underlying detail available on request
• Programme Manager → Executive Sponsor Group — three-to-five page brief at each phase gate; the working artefacts referenced, not embedded

Sponsors who insist on every workstream's raw data passing through to Steering Committee create governance bodies that drown in detail and cannot decide. The reporting standards on the Weekly Programme Status Report, Monthly Programme Report and the governance pack templates carry the operational specifics; the principle here is what holds them together.

Practical team management

Running the team, week to week, on the long programmes

The method describes who joins when and what they own. This section is about how the team actually runs — the practical management discipline that holds momentum across an 18–24 month programme. It applies whether the programme is single-wave, multi-wave, single-pillar or dual-pillar.

How to structure workstream teams

Each workstream has a named Project Manager (from Programme Setup & Mobilisation, S10) plus the SI Functional Lead, Functional Consultants per sub-process, Process Owners on the Client side, and Test Analysts. The structure looks like a small cross-functional team. It is. Keep the workstream small enough that the Project Manager can hold every name in their head — if they can’t, the workstream needs a Lead under them, or it needs splitting.

Communication rhythms beyond formal cadence

The Steering Committee, Design Authority and Executive Sponsor Group are the formal cadence. The programme also runs on informal rhythms that aren’t in any methodology diagram: the Programme Manager’s daily fifteen with the SI Programme Director; the weekly 1:1 between Programme Manager and each workstream lead; the Friday Programme Manager / Business Architect catch-up to spot drift before Monday’s reporting. These are where the real signal travels. Skipping them because the formal forum is sufficient is the most common reason late-stage surprises feel like surprises.

Managing underperformance

People underperform on programmes for three reasons in roughly equal proportions: wrong role for the person, wrong support around them, wrong moment in their career. The Programme Manager’s job is to diagnose which and act — not to manage round it. If a workstream lead can’t hold their workstream, name it in the weekly 1:1, agree a four-week recovery plan with specific deliverables, and if the plan doesn’t land, move them. Programmes that carry an underperforming workstream lead into Build & Configuration (S13) reliably miss the test exit at S14.

The same applies on the SI side, with one nuance: the contractual route runs through the SI Programme Director, not direct to the consultant. The Client says “this person is not landing” to the SI Programme Director; the SI Programme Director either fixes the gap or replaces the person. The replacement clause in the MSA is what makes this conversation work — which is why the MSA is signed at S9, not negotiated under stress at S13.

Keeping momentum across waves

On multi-wave programmes the second wave is harder to keep moving than the first. Wave 1 has launch energy; Wave 2 starts with the team tired and Wave 1 hypercare still pulling people back. Plan momentum deliberately: name a Wave 2 Lead before Wave 1 hypercare entry; re-baseline scope explicitly rather than letting Wave 2 inherit Wave 1’s assumptions; refresh the team where the people who delivered Wave 1 are visibly fatigued. Programmes that don’t do this end up with Wave 2 running 30–50% slower than Wave 1, which the business case never anticipated.

Distributed and remote teams

Most ERP programmes today are distributed by default. The discipline: workshops happen on camera with one screen shared, never two; written summary within 24 hours per the post-workshop traceability rule; a weekly all-hands at a time that works for the principal time zones, not at headquarters convenience. Distributed works on cadence and write-up discipline. It collapses on improvisation.

Team fatigue and burnout

ERP programmes run hot. The team that goes live is rarely the team that started Discovery. Watch for: the workstream lead who stops asking questions in Design Authority; the test analyst who stops logging defects in detail; the Process Owner who quietly delegates the UAT script writing to someone less senior. None of these are individual failings — they’re signals the system is asking too much.

The political go-live date is the most reliable cause of programme fatigue. A date set before design without slack absorbs every problem into the team’s evenings and weekends, then absorbs every team member’s reliability into the date. Move the date if it can be moved; protect the team if it can’t. The programme that goes live exhausted has nothing left for hypercare.

The Programme Manager — workstream lead relationship

This is the most load-bearing relationship on the programme. The Programme Manager doesn’t run the workstream — that’s the workstream lead’s job. The Programme Manager runs the boundary: cross-workstream dependencies, escalations to Steering, blockers the workstream lead can’t move on their own. The 1:1 cadence is weekly. The 1:1 content is: what’s slipping, what do you need from me, what’s coming next. Not a status review — the report is the status review. The 1:1 is the conversation that produces the next report.

Onboarding mid-programme

People join long programmes mid-flight — replacing leavers, scaling for Build & Configuration (S13), backfilling Wave 2. Mid-programme onboarding done badly produces noisy quarters. Done well: a one-page programme orientation (timeline, gates, current stage, current risks), a named buddy for the first month, attendance at one of every governance forum in the first two weeks, an explicit handover from the person being replaced (not just a Slack message). Two days of structured onboarding saves six weeks of low-productivity flailing.

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

Ten 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. Standing up a SteerCo in Pre-Programme is a common mistake — there is no programme to steer yet, and 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.
• Reporting as data transmission, not summarisation. Workstream leads who treat "send a status update" as a transmission task — pages of detail forwarded upward, with the assumption that someone above will distil it. Result: SteerCo packs become Programme Manager firefighting in the 24 hours before the meeting; signal degrades; senior attention gets pulled to the wrong things. Each reporter must own the summarisation before sending, and the Programme Manager's job is to integrate cross-workstream signal, not to remediate individual workstream reporting.