A practical guide for people who help teams deliver. Standards describe what “good” looks like. Methods describe how a team works day to day. Keep those two ideas separate so you do not bury a team in process, or leave a big programme with no control at all.
MAP-01Frameworks & Methodologies
MAP-01
Frameworks & Methodologies
Know which map you're reading before you navigate with it.
Civil Service + Universal
Every framework below answers a different question. Standards tell you what "good" looks like and are largely non-negotiable in government. Methodologies tell you how a team moves day to day and are chosen, not mandated. Mixing the two up is the fastest way to over-govern a team or under-govern a portfolio.
Civil Service standards you are assessed against
Standard
Governs
Shape
Government Digital and Data (DDaT) Profession Capability Framework
What "good" looks like at each career level for your role
9 skills · 4 delivery manager levels, Associate through Head of Agile Delivery Management
GDS Service Standard
Whether a service is fit to launch and stay live
14 points in 3 groups: meeting user needs, providing a good service, using the right technology
GovS 002: Project Delivery
How portfolios, programmes and projects are governed, mandated by the Infrastructure and Projects Authority
Currently v2.1 · uses "shall" for mandatory and "should" for advisory clauses
Managing Successful Programmes (MSP), 5th edition
How a programme (not a single project) is structured and governed
7 principles · 7 themes · 7 processes
HMT Green Book & Five Case Model
The grammar of a business case that unlocks funding
Team scale to enterprise scale, light touch to heavyweight:
Kanban, Scrum, Lean, DevOps / CI-CD culture, Double Diamond / Design Thinking sit toward team scale and lighter ceremony.
PRINCE2 Agile and SAFe sit further toward enterprise synchronisation and heavier formality.
Structured Waterfall / PMBOK-style control sits at the heavyweight enterprise end when stage gates dominate.
Use this as a conversation tool, not gospel: when a sponsor asks "why aren't we doing SAFe", the map lets you show them what they're actually asking for.
How to choose in practice
Single, stable team, clear backlog owner: Scrum.
Continuous flow of unscheduled work, e.g. an operational or support-heavy team: Kanban.
Several teams delivering one programme outcome in government: MSP for the programme, PRINCE2 Agile or Scrum inside each workstream.
Multiple products competing for the same platform capacity: add lightweight WSJF prioritisation on top of whichever team method you already run.
Regulatory, safety-critical, or fixed-date statutory deadline: keep the agile team mechanics, but govern the whole with GovS 002 gates, not vibes.
The DDaT framework defines four delivery manager levels. "Lead Delivery Manager" is an organisational title. Most departments place it across the Senior Delivery Manager band stepping into Head of (Agile) Delivery Management territory: still hands-on with the hardest problem, but now also accountable for the shape of delivery across several teams, and for growing other delivery managers underneath you.
DDaT delivery manager accountability ladder
Associate Delivery Manager (EO / HEO): learning the craft on a contained slice.
Delivery Manager (HEO / SEO): accountable for team performance.
Senior Delivery Manager (G7): complex or high-risk work, coaches other DMs. Lead territory starts here.
Head of (Agile) Delivery Management (G6): owns the profession. Lead often sits across steps three and four.
What actually changes moving into Lead
You stop doing
Being the sole point of escalation for one team's day to day blockers
Treating each programme as a self-contained unit of delivery
Measuring your week by your own output
You start doing
Coaching other delivery managers through their hardest weeks
Holding the coherence of the plan across teams that don't talk to each other daily
Measuring your week by whether capability is growing behind you
The three questions to run every day
Are we solving the right problem? Are we moving at a sustainable pace? Is capability growing behind us?
If the honest answer to any of these is "no" for more than a week, that becomes the priority over anything on the plan.
Teams don't go slowly because people are lazy. They go slowly because decisions are queued, approvals are theatre, or nobody has been explicit about what "good enough to ship" means this sprint. Your job is to remove the queue, not to ask people to hurry up.
The pace dial: reckless pace burns quality and trust; ceremony-bound pace buries outcomes in process; the sweet spot is right pace with enough governance to buy trust cheaply.
Everything drifts into "must have" without a hard arbiter
WSJF (Weighted Shortest Job First)
Several competing programme asks, need a defensible order
Garbage in, garbage out: cost of delay estimates need real rigour
RICE (Reach, Impact, Confidence, Effort)
Product-style backlog with many small items
Confidence scores get inflated under pressure to justify a favourite
Now / Next / Later
Communicating a roadmap upward without over-promising dates
Senior stakeholders will still try to pin "Next" to a date, hold the line
Minimum viable governance
Ask of every recurring approval: what decision does this actually change if it's skipped this once?
Replace status meetings with async RAG plus a 15-minute exception-only call.
Use pre-mortems before a big commitment, not retros after a big failure.
Give every open decision an owner and a default: if nobody decides by [date], [default] happens.
For cross-team calls, use a DACI or RAPID role split so "who actually decides" is never ambiguous.
The basic unit is the team. If stand-ups are status theatre and retros produce no changed behaviour, no amount of programme-level strategy will save the delivery.
Ceremony cadence: purpose and red flags
Ceremony
Real purpose
Red flag it's broken
Stand-up
Surface blockers, re-sync on the plan
It's a status report to you, not a conversation between the team
Refinement
Shared understanding of what "done" means before work starts
Estimates happen with no discussion of edge cases
Planning
Team commits to a realistic slice, not a wish list
Capacity is never actually checked against the plan
Review / showcase
Real feedback from real users or stakeholders
Only internal team members attend
Retro
One concrete change carried into next sprint
Same three complaints every fortnight, nothing changes
Servant leadership, in practice
Remove one named blocker for the team every single week, and say out loud that you did it.
Protect focus time: no meetings should land inside a team's agreed core delivery hours by default.
Shield the team from noise upward, translate downward, never the reverse.
Model the standard you want: if you want honest RAG reporting, be the first to report red.
Team health check dimensions
Delivering value: do we believe in what we're building?
Easy to release: is shipping routine or an event?
Process fit: does our way of working fit how we actually work?
Learning: are we getting better at our craft?
Mission clarity: do we know why this matters?
Support: do we get help when we ask?
As a delivery manager you rarely have line authority over the people whose cooperation you need most: architects, other departments, suppliers, finance business partners. Influence is the actual currency of the job.
Power / interest grid: Monitor (low power, low interest) · Keep Informed (low power, high interest) · Keep Satisfied (high power, low interest) · Manage Closely (high power, high interest: SRO, finance business partner).
Influence currencies, in order of durability
Evidence: data and a track record of accurate forecasting. Slowest to build, hardest to argue with.
Narrative: a clear, honest story of where things are and why. Most senior stakeholders decide on story, then check the numbers.
Relationship: the trust balance you've built before you needed it.
Reciprocity: having helped someone else's priority land, without keeping score visibly.
Formal escalation: the last resort. Effective exactly because you don't overuse it.
Managing your SRO
Agree a fixed short cadence, weekly or fortnightly, protect it even in a quiet week.
Bring options with a recommendation, never bring a problem with nothing behind it.
Never let them be surprised by bad news in a group setting, tell them first, privately.
Write the decision down and circulate it, don't rely on shared memory of what was agreed.
Cross-government and cross-directorate delivery runs through people who don't report to you and don't report to your SRO either: enabling functions, oversight bodies, suppliers, other departments' delivery teams.
Map the seams around your team: sponsoring department, peer delivery teams, supplier or vendor, oversight / PMO, end-user community, enabling functions. Delivery fails at the seams more often than inside the team.
The toolkit for the seams
Structural tools
Cross-boundary RACI, published, not just in your head
A working agreement or light-touch MOU for any recurring dependency
A shared definition of done across teams that hand work to each other
Cultural tools
Attend the other team's stand-up occasionally, don't just summon them to yours
Name shared success, not just shared risk, in updates
Give credit outward generously, it's cheap and it compounds
Language: "one team" vs "them and us"
Drop this
Use this
"We're waiting on [team] again"
"[Team] and we are working through a shared dependency"
"That's not our problem"
"That sits with [team], here's how we can help them unblock it"
"They didn't tell us"
"We need a better shared signal for this, here's what I'll set up"
The information doesn't change between a stand-up and a board update. The altitude, the framing and the ask do.
Audience calibration
Audience
Detail level
What they actually want
Your team
High, specific, technical where relevant
Clarity and cover from noise above
Peer delivery managers
Medium, dependency-focused
Early warning, not surprises
SRO / exec board
Low, outcome and decision-focused
A recommendation and a clear ask, not the journey to get there
Suppliers
Precise, contractually anchored
Unambiguous scope and acceptance criteria
Template · RAG narrative
Status: [RAG] because [the single biggest driver, not a list]
What changed since last report: [one or two lines]
What we're doing about it: [action, owner, date]
What we need from you: [specific ask, or "nothing, for visibility only"]
Template · Escalation email
Situation: [what's happening, in one line]
Impact: [what breaks, by when, if unresolved]
Options: [two or three, each with a trade-off]
Recommendation: [your view, stated plainly]
Decision needed by: [date and who]
Words to drop, words to use
Drop
Use
"Hopefully", "should be fine"
"Confirmed by [date]", "the risk is X, the mitigation is Y"
"We're basically done"
"[N] of [M] acceptance criteria met, remainder land by [date]"
"It's complicated"
"Three things are driving this: ..."
Leading transformation means the team, and the delivery managers around you, can hold the standard when you're not in the room. That's a route with a dip in the middle, not a straight climb. Plan for the dip.
Kotter's eight steps map over an emotional valley: urgency and coalition, then the valley of despair through resistance, then empower and quick wins, then consolidate and anchor. The ADKAR strip runs in parallel as the individual's journey (Awareness, Desire, Knowledge, Ability, Reinforcement). They rarely land in perfect sync. That is normal, not failure.
Coaching ladder: match your style to their readiness
Stage
Their state
Your move
Directing
New to the task
Be specific and close, check in often
Coaching
Some competence, low confidence
Explain the why, invite their view before you give yours
Supporting
Competent, variable confidence
Ask questions rather than give answers, be available not present
Delegating
Competent and confident
Hand over the outcome, step back, review lightly
Signals someone's ready for more
They surface risks before you ask, not after you notice.
They disagree with you and can defend why.
Their updates need no editing before they go up the chain.
The team goes to them first, not to you, for a decision in their space.
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.
Reporting rhythm: Daily async (blockers only) to Weekly team RAG to programme to Monthly Programme Board to Quarterly Gateway / IPA assurance above the cycle.
RAID log discipline
Field
Good looks like
Risk
Written as a future event with a probability and impact, not a vague worry
Assumption
Something you'd need to 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 the team, not monthly before the board meeting. A RAID log written the night before a board is a confession, not a management tool.
Business case lifecycle (Green Book, Five Case Model)
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 a delivery and benefits plan attached
Each case still runs the same five lenses: Strategic, Economic, Commercial, Financial, Management.
Ambiguity about what "finished" means is one of the most common causes of slipped dates that were never actually agreed in the first place.
Definition of done, team level
Meets the acceptance criteria agreed at refinement, not renegotiated after the fact.
Tested to the level the team agreed, not "tested" in the abstract.
Documented enough that someone outside the team could operate or hand it over.
Peer reviewed or equivalent quality gate passed.
Civil Service specific standards
WCAG 2.2 AA accessibility as a floor, not an aspiration, for anything public-facing.
GOV.UK Design System components used by default rather than reinvented.
Data handled in line with the department's data protection and information governance rules.
Sits inside the wider Government Functional Standards suite: GovS 001, GovS 002, GovS 005 all cross-refer to each other.
What must outlive the programme
A decision log: not minutes, just the decisions and why.
A lessons-learned note written while memories are fresh, not at close-down.
A handover pack a stranger could pick up and operate from.
Under pressure, the instinct is to jump to a fix. Diagnose first, even if it takes twenty minutes. A fix for the wrong cause costs far more than that.
Symptom
Likely cause
First move
Scope keeps growing without the date moving
No one owns saying no, or "in scope" was never written down
Write the scope line today, route every new ask through it explicitly
RAG says green, reality says red ("watermelon")
Reporting culture punishes honesty
Publicly thank the next person who reports red early
Two stakeholders want incompatible things
No single owner for the trade-off decision
Name the decision owner today, in writing
Timeline slipping quietly, sprint by sprint
Estimates were hope, not evidence, or scope crept unnoticed
Re-baseline against actual velocity, communicate the new date once, early
Budget overrun becoming visible
Forecast wasn't reforecast as reality changed
Reforecast now, bring options to your SRO before finance flags it
Low morale, quiet standups
Work feels pointless, or pace is unsustainable
Ask one on one, act on what you hear visibly
Requirements keep changing after work starts
Discovery was rushed or skipped
Timebox a fast discovery spike before the next slice
Blocked on an external dependency
No escalation SLA with that team
Escalate today with a date attached
Resistance to a new way of working
People were told, not involved
Bring informal influencers in as co-designers
Supplier underperforming
Ambiguous acceptance criteria or lapsed cadence
Reinstate contract review cadence, document the gap in writing
The one-minute checklist, for when everything is on fire
Name the single biggest risk out loud, to yourself, in one sentence.
Check: is this a scope problem, a people problem, or a dependency problem? (See GV-03.)
Identify the one decision that unblocks the most, and who owns it.
Tell your SRO before they hear it from someone else.
Protect the team from the noise while you sort it.
Glossary anchors
DDaT: Government Digital and Data Profession Capability Framework