A practical guide to control that enables delivery, not theatre that delays it. Standards describe what good looks like for public projects. Methods describe how you plan, escalate and work with agile teams. Keep those ideas separate so you do not bury a healthy team in process, or leave a high-risk project with no control at all.
MAP-01Control maps
MAP-01
Control maps & methods
Match method weight to risk and scale.
Civil Service + Universal
Project work mixes control methods, agile team practices and Civil Service standards. Confusing them creates either ceremony without control, or gates that freeze learning. Every framework below answers a different question. Use the lightest one that unlocks the next honest decision.
Maps you will actually use
Map
Answers
Shape
PRINCE2 Agile
How do stages and tolerances wrap Sprints?
Business case, stages, tolerances · iterative delivery
Project-shaped funding with stage gates: PRINCE2 Agile wrapper, Scrum or Kanban inside.
Multiple projects one outcome: MSP at programme level, do not pretend it is one big project.
Government delivery: map controls to GovS 002 shall clauses; push back on invented local bureaucracy.
Funding decisions: Green Book grammar, with honest Management Case capacity.
Team flow healthy: do not import SAFe ceremonies because a template pack exists.
If a control never changes a decision, stop performing it.
Project delivery roles run from Project Support through Project Manager to Senior / Programme facing roles. In government, the SRO owns overall success; you make control and escalation real. If baselines are fiction and RAG is watermelon, you do not have project management.
Project Support / Coordinator: learning plans, RAID hygiene and reporting craft.
Project Manager: accountable for one project's plan, controls and supplier interface.
Senior Project Manager: complex or high-risk projects, coaches other PMs.
Programme / Portfolio facing: coherence across projects, benefits and assurance.
What you stop and start doing as you grow
You stop doing
Chasing every team for duplicate status
Treating agile forecasts as a threat to control
Measuring your week by slides produced
You start doing
Sharing one RAID/RAG story with the Delivery Manager
Translating Sprint forecasts into stage tolerances
Measuring your week by decisions unlocked and risks surfaced early
Three questions to run every day
Is the baseline still true? Which tolerance is closest to breach? Does the SRO know before the board does?
If any answer is "no" for more than a week, that becomes the priority over the next steering pack.
Hold scope, schedule, cost and benefits baselines. Re-baseline consciously with SRO approval when reality moves. Translate Sprint forecasts into stage views without forcing story-point theatre upstairs.
Baseline hygiene
Baseline
Good looks like
Fail mode
Scope
Written line, Will-not list, change route
Silent creep absorbed into "the plan"
Schedule
Critical dependencies dated, not hope
Quiet sprint-by-sprint slip
Cost
Forecast refreshed as reality changes
Overrun discovered by finance first
Benefits
Owners beyond go-live
Benefits register as fiction
Tolerances that bite
Agree time, cost, scope, risk and benefit tolerances with the SRO in writing.
When a tolerance is forecast to breach, escalate with options, not a post-mortem.
Contingency is owned and visible, not hidden inside optimism.
Change requests show impact on all baselines, not only the asking stakeholder's wish.
Tolerances exist so the SRO hears amber early enough to choose, not red when choice is gone.
Every reporting layer either builds confidence that lets people leave you alone, or it becomes theatre that slows delivery without reducing risk. Aim relentlessly for the former. Share one RAID with the Delivery Manager.
Reporting rhythm: Daily async blockers (team) to Weekly project RAG to Monthly Project Board to stage gates / IPA-style assurance above the cycle.
RAID log discipline
Field
Good looks like
Risk
Future event with probability and impact, not a vague worry
Assumption
Something you would revisit the plan for if proven false
Issue
Already happened, has an owner and a target close date
Dependency
Named other party, named date, named consequence of slippage
Groom it weekly with delivery leads, not monthly the night before the board. A RAID log written the night before is a confession, not a management tool.
Honest RAG
RAG names the single biggest driver, not a shopping list of comfort words.
Thank people who report red early; watermelon culture is a project failure mode.
Align project RAG with team reality; disagree in private, speak with one voice in board.
Own the Management Case delivery plan and benefits realism. Bring honest capacity, dependency risk and optimism bias into Economic and Financial conversations before a date is locked.
Business case lifecycle
Strategic Outline Case: is this worth exploring at all?
Outline Business Case: which option, roughly what will it cost?
Full Business Case: the actual commitment, with delivery and benefits plan attached.
Each case still runs the five lenses: Strategic, Economic, Commercial, Financial, Management.
Challenge optimism bias
Use reference-class thinking where you can
Separate ambition from forecast
Show contingency as contingency
Benefits that outlive go-live
Named benefit owners outside the project team
Measures and review dates
Kill or reshape when evidence fails
If the Management Case ignores team capacity, the Economic Case is a story, not an appraisal.
The SRO owns overall success and critical decisions. Your job is to make those decisions timely and well framed. Never let them hear bad news first in a group setting. The information does not change between a team stand-up and a board update. The altitude, the framing and the ask do.
Audience calibration
Audience
Detail level
What they want
Delivery teams
High, dependency-specific
Cover from noise; clear asks
Delivery Manager / PO
Medium, shared RAID and capacity
One story, early warning
SRO / board
Low, outcome and decision
Recommendation and a clear ask
Suppliers
Precise, contractually anchored
Unambiguous scope and acceptance
SRO operating rules
Agree a fixed short cadence, weekly or fortnightly, protect it even in a quiet week.
Bring options with a recommendation, each with a trade-off.
Write the decision down and circulate it; shared memory is not a system of record.
Map power and interest: Manage Closely SRO and finance; Keep Satisfied high-power, low day-to-day interest.
Partner with the Delivery Manager so RACI for value versus delivery versus control is unambiguous.
Template · RAG narrative
Status: [RAG] because [the single biggest driver, not a list]
What changed since last report: [one or two lines]
What we are doing about it: [action, owner, date]
What we need from you: [specific ask, or "nothing, for visibility only"]
Template · Escalation / board decision
Situation: …
Impact on baselines: time / cost / scope / benefits · what breaks by when
Options: A / B / C with trade-offs
Recommendation: …
Decision needed by: … · Tolerance status: …
Words to drop
Drop
Use
"Hopefully", "should be fine"
"Confirmed by [date]"; "risk is X, mitigation is Y"
"We're basically done"
"[N] of [M] acceptance criteria met; remainder by [date]"
"It's complicated"
"Three things are driving this: …"
PRINCE2 Agile keeps business case, stages and tolerances while teams deliver iteratively. Your interface job is translation: Sprint forecasts into stage views, RAID shared, Definition of Done respected as a quality baseline.
Interface rules that prevent double reporting
Upstairs needs
Downstairs reality
Your translation
Stage end forecast
Sprint velocity and risks
Range plus assumptions, not fake certainty
Scope baseline
Backlog order changes
Change control when envelope moves
Status pack
Team board and RAID
One RAG story, not two dashboards
Assurance evidence
DoD, tests, decisions
Living trail, not night-before binders
Do not force story points into board packs if outcomes and dates with confidence ranges will do.
Protect discovery spikes inside stage tolerances; gates should not outlaw learning.
Agree with the PO what "flex" means: scope flex preferred over quality flex.
Suppliers need unambiguous scope, acceptance, dependencies and cadence. Commercial levers only work if the delivery record is written down while memories are fresh.
Supplier control basics
Structural
Statement of work linked to acceptance criteria
Dependency dates with consequences
Shared RAID items that cross the contract line
Cadence
Regular delivery reviews, not only invoice reviews
Early warning before milestone theatre
Decision log for scope interpretations
Reinstate contract review cadence when performance drifts; document the gap in writing.
Never rely on corridor agreements for acceptance.
Align internal teams so the supplier is not blamed for unclear requirements you own.
Commercial and delivery leads speak with one narrative to the SRO.
GovS 002 mandates how portfolios, programmes and projects are governed. MSP structures programmes. Green Book shapes funding grammar. GDS Service Standard still matters when the project delivers a public service.
GovS 002: map reporting and decision rights to shall clauses; push back on invented bureaucracy that is not required.
MSP: use when multiple projects serve one strategic outcome; do not run programme theatre on a single project.
Green Book: keep SOC/OBC/FBC honest as reality changes.
Service Standard / WCAG: quality floors for public-facing Increments sit inside Done, not outside the plan.
Assurance without the scramble
Decision log, RAID, baselines and benefits evidence stay living.
Lessons learned written while memories are fresh, not only at close-down.
Handover pack a stranger could operate from.
Invite challenge on optimism bias before IPA-style reviews, not during them.
Change control protects baselines. Inside an agreed envelope, the PO should reorder value without ceremony. When time, cost, scope or benefits baselines move, escalate with impact.
What needs formal change
Change
Route
Owner
Backlog reorder, same envelope
PO prioritisation
Product Owner
Clarify AC, same intent
Team + BA update
BA / PO
Scope or date inside tolerance
PM log + SRO note if material
Project Manager
Tolerance breach forecast
Exception / board decision
SRO
Business case refresh
Case gate process
SRO / finance
Template · Change request impact
Request: …
Impact: time · cost · scope · risk · benefits
Options: accept / defer / reject / alternative
Recommendation: …
Decision: … · Date: … · Baseline update: yes/no
Under pressure, the instinct is to add more reporting. Diagnose first. A fix for the wrong cause costs a stage.
Symptom
Likely cause
First move
Watermelon RAG (green outside, red inside)
Reporting culture punishes honesty
Publicly thank the next person who reports red early
Scope creep without date or cost moving
No written scope line, or weak change control
Write the scope line today; route every new ask through it
Optimism bias locked into the plan
Ambition treated as forecast; no contingency honesty
Reforecast against evidence; show contingency separately
Quiet schedule slippage
Hope-based estimates, or ignored velocity
Re-baseline against actuals; communicate once, early
Budget overrun becoming visible
Forecast not refreshed as reality changed
Reforecast now; bring options before finance flags it
Double status theatre with DM
Two RAID/RAG stories
Merge to one shared log and one board narrative this week