Delivery and Programme Management

Executive summary

AI programmes fail in predictable ways when treated as “just another app”: ambiguous scope, parallel security tracks discovered late, model quality debated without gates, and benefits claimed before operate-ready controls exist. Delivery and programme management for AI Solution Engineers means running governed agility—plans with critical paths, RAID registers that surface dependencies before they bite, agile ceremonies adapted for probabilistic components, and quality gates that block production when eval, security or adoption criteria fail. You must connect discovery → design → prototype → case → build → launch → operate with explicit decision forums, not slide decks. This topic teaches you to produce delivery roadmaps, RAID logs, gate checklists and steering rhythms that survive partner review, audit and the reality that your “done” includes monitoring, rollback and human operating procedures—not only shipped code.

When to use this page

• When kicking off a pilot or scale programme and no single integrated plan exists—only vendor timelines.
• When security, legal or model risk reviews appear “surprisingly” on the critical path two weeks before launch.
• When the team runs sprints but steering cannot answer: gate date, top dependency, or who owns red RAID items.
• When agile ceremonies discuss story points but not eval pass rates, corpus readiness or adoption prerequisites.
• When merging AI workstreams (data, platform, UX, change) without a dependency map.
• When the client asks for hybrid delivery (waterfall gates + agile build)—you need a coherent model.
• Before monthly steering or partner review—pack must show critical path, RAID and gate evidence.
• Pair with Delivery Guide for release patterns, environments and operate handover.

Executive view

Ask for critical path, top three dependencies, and next quality gate—not sprint velocity alone. Demand RAID with owners and dates; red items without owner are programme fiction.

Decision lens: What explicitly blocks production this month, and what is the cost of deferring that gate?

Technical view

Translate engineering backlog into programme language: eval thresholds, corpus milestones, integration cutovers and feature flags are gate criteria—not “done” when merged to main.

Maintain RAID linkage from Jira/ADO tickets; escalation when blockers exceed agreed SLA.

Why this matters

Traditional IT delivery assumes deterministic scope: requirements stable, defects measurable against spec, “done” means deployed. AI delivery adds probabilistic components, evolving corpora, parallel risk tracks (DPIA, model risk, red team), and adoption dependencies that can nullify technical success. Without programme discipline, teams ship a copilot that passes demo but fails CISO gate, or passes gate but dies in operate because no runbook owner exists.

Real cost example: A European bank’s customer-service AI pilot ran 14 two-week sprints with high velocity. Steering saw green RAG on “build.” No integrated RAID linked security review (queued 11 weeks), corpus licensing (4 vendors unresolved), or contact-centre training (6 weeks lead). Planned launch September slipped to February; £280k burn with no production benefit; sponsor credibility damaged. Re-plan with critical path and three explicit gates recovered 12 weeks on the replanned path—not by working harder, but by sequencing dependencies and de-scoping non-blocking UX polish until post-launch.

AI Solution Engineers sit at the intersection of build truth and decision forums. You do not replace a programme manager—but you must produce plans, registers and gate evidence that make AI risks visible early. Delivery management is how consulting intent becomes operational reality.

This topic pairs with Delivery Guide, MLOps, LLMOps and Observability, AI Evaluation and Quality Assurance, Change Management and Adoption, and Stakeholder Management.

Learn

Lifecycle stages — qualify to operate

Map work to explicit stages; each stage ends with a decision or gate, not a calendar page turn.

Stage	Purpose	Typical exit artefact
Qualify	Funded problem, sponsor, risk appetite	Charter, business case sketch
Discover	Task analysis, data/corpus assessment	Discovery report, stakeholder map
Design	Architecture, eval plan, operating model	Solution outline, gate 0 approval
Prototype	Technical feasibility, spike	Prototype demo, kill/continue
Case	Pilot with metrics	Pilot report vs hurdles
Build	Hardening, integration, controls	Release candidate, gate evidence
Launch	Controlled rollout, training	Launch checklist complete
Operate	SLOs, incident, continuous eval	Handover to BAU owner

Anti-pattern: Calling everything “agile” and skipping case/operate—then wondering why production breaks.

Agile for AI — what changes in Scrum/Kanban

Scrum and Kanban still work; definition of done and backlog refinement must expand.

AI-specific Definition of Done (example):

• Feature behind flag with rollback tested
• Eval suite run; no regression beyond threshold
• Prompt/model version tagged in release notes
• UX trust patterns (citations, HITL) implemented per checklist
• Logging/metrics emitted (latency, abstention, errors)
• Runbook section updated
• Security/privacy review if data path changed

Sprint planning additions:

Standard agile topic	AI delivery addition
User stories	Include failure modes and refuse paths
Acceptance criteria	Eval metric thresholds, not only UI
Dependencies	Corpus refresh, embedding jobs, GPU quota
Demo	Show bad answers and refuses—not only happy path
Retro	Prompt incidents, override rates, report queue

Kanban for AI ops: Separate lanes for model/prompt changes, corpus updates, infra, incidents—WIP limits on prompt changes to prevent thrash.

Hybrid delivery — gates + iterations

Enterprises often require stage gates (PMO, investment committee) with agile execution between gates. Hybrid model:

Rules:

• Gates are decision meetings with pre-read 48h minimum
• Iteration blocks have fixed timeboxes; scope flexes, date does not (within block)
• Gate packs reuse same RAID IDs—no duplicate risk lists
• “Agile” does not bypass CISO; parallel risk track from week 1

Plans and roadmaps — critical path, not wallpaper Gantt

A roadmap communicates sequence, dependencies and decisions—not 200 tasks.

Roadmap layers:

1. Milestone layer — gates, launches, regulatory dates (max 12 items per quarter view)
2. Workstream layer — build, data, security, change, integration
3. Critical path — longest dependent chain; highlight in red on steering slide
4. Buffer — explicit contingency on risk track and adoption, not hidden padding

Critical path example (insurance RAG scale):

UX polish not on critical path—schedule post-launch if buffer consumed.

Planning horizons:

Horizon	Detail	Audience
6-week	Sprint-level; RAID weekly	Team
Quarter	Gates, dependencies	Steering
Annual	Funding waves, platform bets	Portfolio

RAID — risks, assumptions, issues, dependencies

RAID is the programme nervous system. Weak RAID = surprises in steering.

Register types:

Type	Definition	Example
Risk	Future event; probability × impact	Model drift undetected in prod
Assumption	Believed true; validate or convert	60% adoption by month 3
Issue	Already happening	Vendor API quota exhausted
Dependency	External deliverable required	Identity team SSO by 15 Aug

Also maintain: Decision log, Action log, Benefits tracker—linked to same IDs where possible (R-014 relates to D-007).

RAID quality rules:

• Every item has owner name, not team name
• Review date and RAG status
• Impact quantified where possible (£, days, regulatory)
• Dependencies name deliverable + date, not “IT support”
• Top 5 items on steering page 1

RAID entry template:

ID: D-023 | Dependency | AMBER
Title: SSO integration for copilot embed
Owner: Priya Shah (Identity)
Need by: 2026-09-15 (blocks launch)
Deliverable: SAML app registered + DLP policy
Impact if slip: Launch +3 weeks; £90k benefit delay
Mitigation: Interim VPN-only pilot (CISO conditional)
Escalation: L2 if no progress by 2026-08-01

Dependencies — mapping across workstreams

AI programmes depend on non-AI teams more than typical apps:

Dependency class	Common owner	Typical slip cause
Identity / SSO	IAM	App registration queue
Data / corpus	Legal, records	Licensing, PII redaction
Integration	ERP/CRM team	API rate limits, sandbox
Security	CISO office	Architecture board cadence
Infrastructure	Cloud platform	Quota, region approval
Change / training	HR/L&D	Curriculum lead time
Model risk	Risk function	Validation sample size

Dependency map artefact: Matrix of workstreams × weeks with “hard” vs “soft” dependencies; hard = on critical path.

Governance boards — steering, design authority, risk

Clarify forums or decisions get re-litigated every sprint.

Forum	Cadence	Decides	Inputs
Steering committee	Monthly	Funding, scope, launch go/no-go	RAID, benefits, gates
Programme working group	Weekly	Backlog priority, blockers	Sprint demo, RAID deltas
Architecture / design authority	Bi-weekly or gate-based	Patterns, exceptions	ADRs, integration
AI risk / model risk	Gate-based	Validation, drift policy	Eval reports
Change board	Fortnightly	Training, comms, role impact	Adoption metrics

Steering pack minimum (see topic 28): BLUF, decisions needed, critical path, top 5 RAID, gate calendar, financials vs plan.

Quality gates — blocking production

Gates are binary where possible—ambiguous “mostly ready” causes incidents.

Example gate stack for RAG production:

Gate	Criteria (sample)	Decide role
G0 — Charter	Sponsor, buyer, problem metric	Sponsor
G1 — Design	Architecture + DPIA started + eval plan	Architecture board
G2 — Pilot exit	Eval pass; pilot hurdles; UX trust checklist	Steering
G3 — Pre-prod	Pen test; load test; runbook; on-call	CISO + ops
G4 — Launch	Training complete; three yeses (business, user, risk)	Steering
G5 — Operate	SLO met 30 days; incident process live	Service owner

Eval gate example: Retrieval precision ≥0.82 on golden set; abstention rate 8–15%; harmful output rate <0.1% on red-team set.

Capacity, change control and benefits tracking

Capacity: AI teams underestimate corpus curation, eval maintenance, and prompt incident load. Plan 20–30% capacity for quality loop post-launch.

Change control: Prompt/model changes are releases—version, eval diff, rollback plan. Emergency change process for harmful output patterns.

Benefits tracking: Link to adoption metrics (topic 26)—benefit case invalid if adoption < hurdle.

Benefit claim	Delivery evidence required
Handle time −20%	Baseline + pilot n + adoption %
Cost avoid £500k	FTE model assumptions documented
Error reduction	Before/after QA sample size stated

RAID + agile tooling integration

Avoid RAID in Excel that diverges from Jira:

• RAID IDs in ticket descriptions
• Blockers >5 days auto-flag for programme lead
• Weekly export to steering snapshot—same IDs
• Decisions logged within 48h with link to RAID closure

Frameworks and methods

8D-aligned delivery mapping

Connect programme stages to 8D Framework dimensions—steering expects this language on major programmes.

8D dimension	Delivery artefact
Discover	Problem statement, corpus assessment
Design	Architecture, eval plan, RAID v1
Develop	Sprint backlog, CI/CD, feature flags
Deploy	Release notes, gate evidence
Data	Corpus pipeline, refresh SLA
Decisions	Decision log, steering minutes
Depend	Integration cutover plan
Deliver value	Benefits tracker, adoption dashboard

Stage-gate × agile hybrid (SAFe-inspired light)

For large programmes without full SAFe overhead:

1. Portfolio gate — fund phase
2. Programme increment (8–12 weeks) — multiple sprints
3. System demo — end of increment; steering input
4. Inspect & adapt — adjust roadmap, RAID, benefits

Critical path method (CPM) simplified

1. List all tasks with duration estimates
2. Draw dependencies (finish-to-start minimum)
3. Identify longest path—mark critical
4. Float on non-critical tasks—defer UX polish here first
5. Recompute weekly when RAID issues slip

RAG status definitions (programme level)

Status	Rule
Green	On plan; no red RAID; next gate on track
Amber	Slip <2 weeks OR amber RAID without mitigation
Red	Gate miss OR critical path blocked OR sponsor disengaged

One red RAID on critical path → programme amber minimum.

Three horizons planning (McKinsey-style adapted)

Horizon	Focus
H1 (0–6 mo)	Pilot/build/launch—detailed RAID
H2 (6–18 mo)	Scale waves, platform—milestone roadmap
H3 (18+ mo)	Capability, CoE—directional only

Steering decides H1; portfolio decides H2 funding.

Programme initiation checklist (30 items compressed to 10 themes)

1. Charter signed (sponsor, buyer, scope out)
2. RAID live with owners
3. Critical path v1 published
4. Gate calendar agreed
5. RACI/RAPID for launch (topic 27)
6. Eval plan with thresholds
7. Security track started (not ticket filed—meeting held)
8. Change/training owner named
9. Benefits baseline captured
10. Steering cadence scheduled with pre-read SLA

Sprint ceremony playbook for AI programmes

Ceremony	AI-specific agenda item	Timebox
Backlog refinement	Eval debt, corpus stories, prompt incidents	30 min
Planning	Capacity for eval runs and security reviews	45 min
Daily standup	Blockers on data/legal/security tracks	15 min
Review/demo	Show refuse path + metric dashboard	30 min
Retro	Override/report rates, RAID closure rate	45 min

Demo discipline: Every sprint review includes one failure mode—teams that only demo sunshine lose steering trust.

Integrated master schedule (IMS) lite

Combine workstreams in one view for steering—not five separate Gantts.

Shaded overlap shows parallel work; triangles are immutable gate dates unless steering moves them with impact statement.

Financial tracking vs delivery

Programme financials should mirror RAID:

Line	Source	Steering question
Actual spend vs plan	Finance / PMO	Burn rate sustainable?
Forecast at complete	PM + leads	Need change request?
Benefit realisation	Benefits owner	Adoption on track?
Contingency consumed	RAID mitigations	Scope cut needed?

AI programmes often under-run build and over-run corpus/security—reforecast monthly, not at gate only.

Partner review pack (delivery lens)

Before client signature on large programmes, partners ask:

1. Critical path credible? (not vendor template)
2. RAID top 5 owned? (names, not “client”)
3. Margin sensitivity if security adds 12 weeks?
4. Operate handover in scope? (not TBD)
5. Kill criteria if pilot fails metrics?

Prepare 3-bullet answers in pursuit handover (topic 29).

Post-incident programme replan

When harmful AI output or major outage occurs mid-programme:

1. 48-hour stabilisation (rollback, comms)
2. RAID issue + risk entries with regulatory flag if needed
3. Re-gate eval and UX trust checklist before resume
4. Steering BLUF: continue / pause / kill with dates
5. Update critical path—never “back to green” without evidence

Document in decision log; link to incident report ID.

Real-world scenarios

Scenario A — Retail bank contact centre: security on critical path

Context: UK retail bank; GenAI copilot for 12,000 agents; planned pilot launch Week 12; build team green.

RAID miss: Security architecture review not on plan until Week 10—queue 8 weeks. CISO requires private tenant; public SaaS path dead.

Intervention:

• Rebuilt plan with critical path starting security Week 0
• Gate G1 moved before sprint 3 build spend
• De-scoped animated UX to post-launch (−120 dev hours)
• Parallel track: DPIA with DPO weekly

Outcome:

• Pilot launch Week 19 (7-week slip vs original, 4 weeks better than if security discovered Week 10 only)
• Private tenant cost £420k/year accepted in steering with ROI still positive
• Zero “surprise” CISO veto at launch gate

Numbers: Projected benefit £720k/year handle time; programme spend £1.1m year one; payback 22 months at 55% adoption.

Scenario B — Pharma medical affairs: hybrid gates with agile content sprints

Context: Top-10 pharma; 800 field medical staff; AI-assisted response drafting with MLR control. 18-day MLR cycle baseline.

Delivery model:

• Gate 0: MLR Decide role on template library scope
• 6-week increment: agile sprints on snippet assembly only
• Gate 1: Pilot in 2 countries after 500 output audit sample
• RAID: Veeva integration dependency (10 weeks); medical writer capacity

Issue (I-007): Vendor promised API; integration slipped 3 weeks.

Response: Re-sequenced manual export/import workaround for pilot only—accepted technical debt with RAID R-011 for prod.

Outcome:

• Pilot MLR cycle 11 days (−39%)
• Gate 1 passed; scale to 6 countries over 2 increments
• No autonomous send—HITL gate enforced in delivery DoD

Scenario C — Public sector housing: dependency on union consultation

Context: Housing association; repairs scheduling assist; 1,400 field staff; cabinet funding £340k; fixed fiscal year.

Critical dependencies:

• Union consultation 6 weeks minimum
• Mobile app release train monthly
• Corpora from legacy PDFs OCR quality 72%

Programme choices:

• Started union track Week 0 parallel to OCR pipeline
• Gate: union neutral statement before beta
• Deferred “optimisation v2” to H2

Outcome:

• Beta on time in fiscal year
• First-visit fix +7 points in pilot region
• RAID D-004 OCR vendor swapped—2-week slip absorbed by float on training

Scenario D — Energy retailer: CoE standard vs BU delivery conflict

Context: Energy retailer; field agent offline assist; group AI CoE mandates platform; BU signed niche vendor POC.

Delivery governance failure: POC contract bypassed architecture board—CoE threatened funding freeze on £2.4m BU backlog.

Recovery programme:

• Emergency steering; RAPID: Group CTO Decide on patterns
• Delivery replan: 8-week spike on approved edge-cache pattern
• RAID R-022 vendor scope limited to eval not prod
• Single integrated roadmap published to both CoE and BU

Outcome:

• Avoided duplicate production stacks
• Visit rework 22% → 14% failed first visit in pilot (−8 points)
• Partner margin protected by phase-0 discovery SOW separated

Scenario E — NHS primary care: operate gate saves programme

Context: ICS; 62 practices; appointment triage assist; launch declared “done” at code complete.

Operate failure: No runbook; on-call paged vendor not client; eval manual; drift undetected 11 weeks.

Recovery:

• Operate gate G5 enforced before re-launch to wider ICS
• Named service owner; weekly eval cron; incident playbooks
• RAID R-031 model drift; owner model risk

Outcome:

• Repeat incident zero over 6 months
• Steering approved £220k operate budget (previously “BAU absorbs”)
• Programme credibility restored with CQC-ready documentation

Numbers: First failed launch cost £180k sunk; operate fix £220k—cheaper than second reputational incident.

Practice exercises

Primary exercise — 6-week pilot plan with gates and RAID (60 minutes)

Brief: HR policy RAG for 4,000 employees; pilot cohort 600; CISO requires SSO + DLP; L&D needs 3 weeks for e-learning; target pilot start Week 7.

Tasks:

1. Draw milestone roadmap (6 weeks pre-pilot + 6 weeks pilot) with 3 gates.
2. Identify critical path (minimum 6 chained items).
3. Write 5 RAID entries (mix of R/A/I/D) with owners, dates, impact.
4. Define steering pack outline for Gate 2 (pilot launch).
5. List Definition of Done for one sprint including AI-specific items.

Acceptance criteria:

• At least one dependency on non-AI team with named owner
• Gate criteria measurable (not “security happy”)
• Critical path differs from “all tasks in parallel”
• Contingency named (what drops if slip 2 weeks)

Stretch exercise — Programme recovery replan (half day)

Brief: Month 4 of 9-month programme; security gate red; adoption 34% vs 70% target; vendor change request £180k; sponsor disengaged.

Tasks:

1. Forensic RAID: top 10 items with root cause (process vs external).
2. Rebuilt critical path to launch in +8 weeks max—scope trade-offs explicit.
3. Gate calendar revision with eval thresholds restated.
4. Steering extraordinary session agenda: decisions needed (continue/pivot/stop).
5. Benefits tracker revision with adoption sensitivity.
6. RACI for recovery actions (link topic 27).

Acceptance criteria:

• Stop/continue recommendation with kill criteria
• Sponsor re-engagement actions with dates
• No double-counting benefits if scope cut
• Partner-reviewable margin/scope note (3 bullets)

Questions you should be able to answer

1. What is on the critical path this month, and what is float on UX polish?
2. Which quality gate blocks production, and who is the Decide role?
3. Who owns the top three RAID items, and when were they last reviewed?
4. What assumptions in the plan convert to risks if false?
5. How do sprint demos connect to gate evidence?
6. What is the Definition of Done for a prompt change vs a UI change?
7. Where are security, DPIA and model risk on the timeline—not “later”?
8. What dependencies sit with identity, legal, data teams—and need by dates?
9. How does the roadmap show discover → operate without jargon-only labels?
10. What benefits metrics prove value—and what adoption hurdle breaks the case?
11. How is change control managed for model/prompt releases?
12. What happens in operate: on-call, runbook, eval cadence?
13. What is the cost of a 4-week gate slip in £ or benefit delay?
14. Which forum decides architecture exceptions vs steering scope?
15. If you must cut scope to hold a regulatory date, what drops first?

Monthly programme operating rhythm

Week	Programme lead	Workstream leads	Steering prep
1	RAID review; critical path update	Sprint plan; dependency ping	Draft decisions list
2	Gate evidence collection	Demo + eval report	Financials vs plan
3	Escalation L2/L3 if needed	Integration/security status	Pre-read draft 48h SLA
4	Decision log publish	Retro actions to RAID	Pack issued; meeting held

Standing rule: If pre-read not issued 48 hours before steering, default decision is defer—prevents first-read ambushes.

AI-specific RAID library (seed items)

Copy and adapt on programme start:

ID type	Title	Typical owner
R	Model drift undetected in production	Model risk
R	Corpus stale vs policy published	Corpus curator
R	Adoption below benefits hurdle	Change lead
D	SSO/DLP not ready for embed	Identity
D	Legal corpus licensing unsigned	Legal
I	Vendor API quota exhausted	Platform lead
A	60% adoption in 90 days	Benefits owner
A	Security decision by date X	CISO delegate

Review library each gate—close or re-open with evidence.

Quality gate evidence pack (G2 pilot exit example)

Minimum exhibits in shared folder (numbered for steering):

1. Eval summary vs thresholds (Fact)
2. UX trust checklist score (topic 23)
3. Security conditional approval letter or full sign-off
4. Adoption dashboard week 8 snapshot
5. RAID top 10 with RAG
6. Updated critical path to scale
7. Benefits tracker vs baseline
8. Decision memo recommend continue/stop/pivot

Missing exhibit → gate fail not “conditional pass.”

Dependency negotiation scripts

Use when dependency owner misses date:

Situation	Script
SSO slip 2 weeks	“Launch moves from 15 Sep to 6 Oct—£90k Q3 benefit at risk. Options: interim VPN-only pilot (CISO condition) or descope wave 1 to 200 users with manual login.”
Corpus legal unsigned	“Build continues on sample corpus; production gate blocked. Recommend steering Decide: accept sample-only pilot or pause build spend after sprint 4.”
Training not ready	“Launch without training → adoption risk red. Recommend date move or launch read-only mode without customer send.”

Scripts attach to escalation memos (topic 28 BLUF format).

Benefits and adoption linkage in programme plan

Programme plan must show benefit realisation track parallel to build:

If change track slips, move launch gate—do not launch and hope training catches up.

Programme status narrative — weekly email template

Programme leads send one email to steering delegates between monthly meetings:

Subject: [Programme] Week 12 — AMBER — decision needed on SSO date

BLUF: Launch at risk +3 weeks unless Identity deliver SAML by 5 Sep (D-023).

Progress: Build 85%; eval RC pass; UX trust score 14/16.
Critical path: SSO → embed UAT → launch.
Top RAID: D-023 SSO (owner Priya); R-014 adoption plan (amber).
Gate: G3 pre-prod 22 Sep — needs CISO sign-off by 15 Sep.
Ask: Sponsor call Identity LT this week — reply yes/no by Thu.

Keeps steering delegates aligned—reduces monthly meeting surprise.

Agile for AI anti-patterns catalogue

Anti-pattern	Symptom	Fix
Prompt thrash	Daily prompt changes without eval	WIP limit; eval diff required
Corpus surprise	New docs break retrieval	Corpus change log; regression eval
Demo-driven sprint goals	Stories optimise demo path	User story tied to workflow metric
Risk ticket filed	Security “involved” but not scheduled	Parallel track with dates
Infinite pilot	No kill criteria	Steering date with stop rule
Ops afterthought	No on-call in backlog	Operate stories in last increment before launch

Use in retros—teams recognise themselves without blame framing.

Gate decision record template

Gate: G2 Pilot Exit | Date: 2026-08-15 | Decide: Steering (COO chair)

Decision: CONTINUE to scale wave 1 — conditions below.

Evidence reviewed: Eval summary #E-2026-08; UX checklist 14/16; Adoption 58% wk8 (hurdle 55%); RAID top 5.

Conditions:
1. CISO full sign-off (not conditional) by 2026-09-01 — owner: Security lead
2. Corpus licensing D-014 closed by 2026-08-30 — owner: Legal

Dissent: CFO noted payback sensitivity at 50% adoption — sensitivity in appendix B.

Next gate: G3 Pre-prod 2026-09-22.

Store with programme ID—audit and handover depend on this.

RACI for programme artefacts (who maintains what)

Artefact	Programme mgr	ASE	Tech lead	Change lead	Sponsor
RAID log	A/R	C	C	C	I
Critical path	R	C	C	C	I
Gate evidence	C	R	R	C	A
Steering pack	R	C	C	C	C
Decision log	R	C	I	I	I
Benefits tracker	C	C	I	C	A

Exactly one A per row; programme manager coordinates, sponsor owns benefits acceptance.

Discovery-to-operate checklist (single page)

Stage	Complete when
Qualify	Charter + baseline metric captured
Discover	Stakeholder map + corpus assessment
Design	G0/G1 passed; eval plan approved
Prototype	Kill/continue documented
Case	Pilot hurdles met or stop
Build	RC passes eval + security conditions
Launch	Three yeses (business, user, risk)
Operate	Service owner + SLO + eval cadence live

Programme red if any stage marked complete without evidence artefact in shared folder.

Steering decision types — vocabulary for packs

Use precise decision verbs so minutes are enforceable:

Verb	Meaning	Example
Approve	Authorise spend or scope	Approve £890k scale
Choose	Select option A/B/C	Choose private tenant path
Defer	Revisit with date	Defer wave 2 to 15 Nov
Kill	Stop programme or phase	Stop PoC; no pilot
Accept risk	Proceed with documented residual	Accept latency risk with mitigation owner

Avoid “aligned” or “noted”—not decisions.

Negative cases — when delivery management fails

Velocity theatre

Symptom: Green sprints; no gates; “done” means merged code.

Impact: Launch blocked; steering surprise; burn with no benefit.

Fix: Gate-linked DoD; demo includes eval and risk status.

RAID as archaeology

Symptom: RAID updated after steering; items without owners; duplicate risk lists in decks.

Impact: Same blockers for months; accountability diffused.

Fix: Weekly RAID review; IDs in tickets; top 5 on steering page 1.

Security last

Symptom: Security engagement starts at “pre-launch”; pen test week before go-live.

Impact: Multi-month slip; emergency spend; trust loss.

Fix: Parallel risk track from Week 0; G1 before heavy build.

Integration fantasy

Symptom: “Assume API works”; sandbox never tested; SSO “later.”

Impact: Pilot trapped in standalone URL; adoption fails.

Fix: Dependency map with hard dates; integration spike in sprint 1.

Benefits without baseline

Symptom: Roadmap shows launch date; no baseline metric captured.

Impact: Cannot prove value; funding cut at scale gate.

Fix: Baseline in qualify/discover; benefits tracker from day 1.

Operate orphan

Symptom: Launch celebrated; no service owner; runbook draft; eval manual.

Impact: Incidents chaotic; drift undetected; programme blamed.

Fix: Operate gate G5; handover checklist; capacity for eval maintenance.

Agile without steering literacy

Symptom: Steering hears story points; not decisions, RAID, or critical path.

Impact: Executives disengage; shadow PMO creates parallel plan.

Fix: Translate agile to gates and milestones; same RAID in both views.

Output

Expected outputs for this topic:

• Delivery roadmap — milestones, workstreams, critical path highlighted
• RAID log — owned items with RAG, dates, quantified impact
• Quality gate checklist — criteria per gate with evidence links
• Gate calendar — Decide roles and pre-read deadlines
• Sprint/release Definition of Done — AI-specific extensions
• Steering pack template — BLUF, decisions, RAID top 5, path, financials
• Operate handover checklist — on-call, runbook, eval cadence, benefits owner

Practice checklist

• I can draw critical path for a fictional 12-week AI pilot without vendor slides
• I completed the 6-week plan exercise with 3 gates and 5 RAID entries
• I defined AI-specific Definition of Done items for at least one sprint
• I linked delivery stages to gate decisions and Decide roles
• I know which forum owns architecture vs launch go/no-go
• I opened Delivery Guide for release and operate patterns
• I paired plan with change/adoption owners (topic 26) on dependencies

Related playbook content

• Delivery Guide — release trains, environments, operate handover
• Architecture Guide — design authority and ADRs
• Consulting and client engagement — engagement setup and steering standards
• MLOps, LLMOps and Observability — release and monitoring
• AI Evaluation and Quality Assurance — gate metrics
• Change Management and Adoption — training dependencies
• Stakeholder Management — forums and RACI
• Communication and Executive Articulation — steering packs
• Project Management — PMBOK® Fifth Edition study map
• How to use this Learning Map
• 8D Framework

Key takeaways

• AI delivery is governed agility: iterations inside gates, not iterations instead of gates.
• Critical path and RAID expose security, data and adoption dependencies early—velocity alone lies.
• Definition of Done must include eval, logging, UX trust and runbook—not only merged code.
• Hybrid models work when gate packs and sprint backlogs share the same RAID IDs and truth.
• Operate is a delivery stage with owners, SLOs and continuous eval—not a launch party.
• Steering needs decisions, critical path and top RAID—not story points.

What to do next

1. Complete the 6-week pilot plan primary exercise.
2. Audit your current programme: is security on the critical path from Week 0?
3. Continue with Change Management and Adoption.
4. Deepen release patterns in Delivery Guide.
5. Open the interactive playbook for programme templates.