A framework is just a named way of working. Pick the lightest one that answers the question you have today. Each card below says what it is, when to use it, how a Project Manager might apply it, what goes wrong, and where to read more.
Cards start folded. Expand one at a time. The open card fills the width and the rest move below.
Project + agile
PRINCE2 Agile
Keeps PRINCE2 control (stages, tolerances, business case) while teams deliver iteratively.
When to use it
Project-shaped funding with stage gates
Need clear tolerances for time, cost and scope
Agile teams inside a governed project wrapper
Example for a Project Manager
Own the delivery interface: map Sprint forecasts into stage tolerances, keep RAID shared with the Delivery Manager, and protect discovery inside the envelope.
Things that go wrong
Double reporting: project dashboard and agile board that disagree
Stage gates that freeze learning mid-discovery
Story-point theatre in board packs
Civil Service standard
GovS 002 Project Delivery
Mandated functional standard for portfolios, programmes and projects. Shall and should language.
When to use it
Government project or programme delivery
Need mandatory governance clauses clear to assurance
Aligning PMO, SRO and delivery teams on control expectations
Example for a Project Manager
Map your reporting rhythm and decision rights to GovS 002 shall clauses. Push back on invented local bureaucracy that is not required, and insist on what is.
Things that go wrong
Gold-plating beyond the standard
Ignoring shall clauses until IPA assurance arrives
Programme
MSP (Managing Successful Programmes)
Programme framework with 7 principles, 7 themes and 7 processes for outcome-led change across multiple projects.
When to use it
Multiple related projects serve one strategic outcome
Benefits realisation spans years and organisations
Need programme-level governance above project methods
Example for a Project Manager
Escalate to MSP when you are truly in a programme. Hold tranches, benefits and cross-project dependencies; do not run programme theatre on a single project.
Things that go wrong
Treating the programme as a big project with more slides
Benefits registers that nobody owns after go-live
Business case
Green Book / Five Case Model
HMT appraisal guidance and the Strategic, Economic, Commercial, Financial and Management cases.
When to use it
Seeking or refreshing public funding
Comparing options with economic and strategic rationale
SOC to OBC to FBC lifecycle
Example for a Project Manager
Own Management Case realism: capacity, dependencies, optimism bias and benefits owners. Refresh the case when reality moves, not only at gates.
Things that go wrong
Business case as fiction written once
Management Case that ignores team capacity
Benefits with no owner after go-live
Team methodology
Scrum
Lightweight agile framework with a usable Increment each Sprint. The PM wraps stages around team cadence rather than micromanaging tickets.
When to use it
Stable team with a clear backlog owner
Need planning, review and retro cadence
Value emerges through thin vertical slices
Example for a Project Manager
Consume Sprint forecasts and risks into stage views. Attend Review for evidence, not to turn Daily Scrum into status theatre for the PM.
Things that go wrong
Demanding duplicate status outside team boards
Treating Sprint Goal changes as free scope
Ignoring Definition of Done in project quality baselines
Team methodology
Kanban
Visualise work, limit WIP and manage flow. Strong fit for operational or interrupt-driven workstreams inside a project.
When to use it
Unscheduled operational demand
Flow metrics matter more than fixed Sprint commitments
Need visibility of aging WIP and blockers
Example for a Project Manager
Report cycle time and blocked age into project RAG when a workstream runs Kanban. Set expectations with the SRO that flow metrics replace fake date precision.
Things that go wrong
Board without WIP limits
Ignoring blocked age until everything is red
Forcing Sprint theatre onto a flow team
Prioritisation
MoSCoW
Must, Should, Could, Will not for a fixed timebox. Forces scope honesty under a deadline.
When to use it
Fixed deadline with negotiable scope
Stakeholder workshops that need a shared scope line
Statutory or regulatory dates
Example for a Project Manager
Facilitate scope talks with capacity on the table. Keep a named arbiter (PO or SRO) and a visible Will-not list that feeds the scope baseline.
Things that go wrong
Everything becomes Must
Will-not list disappears after the workshop
No capacity check, so Must is fantasy
Prioritisation
WSJF
Cost of delay divided by job size for a defensible order when several asks compete for the same capacity.
When to use it
Competing asks for shared capacity across the project
Sponsors need transparent ranking inputs
Programme-level trade-offs affect your plan
Example for a Project Manager
Facilitate cost-of-delay workshops when directorates fight for the same delivery capacity. Refuse to rank without named assumptions written down.
Things that go wrong
Garbage-in cost of delay
Political scoring with no challenge
Scores never revisited when reality changes
Civil Service standard
GDS Service Standard
Fourteen points on meeting user needs, providing a good service, and using the right technology.
When to use it
Project delivers a UK public service
Service assessment preparation
Need a shared quality bar across product, design and delivery
Example for a Project Manager
Put Service Standard and accessibility evidence into project quality baselines and stage exit criteria so assessment is not a scramble at the end.
Things that go wrong
Treating assessment as paperwork only
Leaving accessibility and performance outside the plan
Control practice
RAID management
Disciplined Risks, Assumptions, Issues and Dependencies with owners, dates and consequences, groomed as a living tool.
When to use it
Any non-trivial project
Multiple suppliers or organisational seams
Assurance expects evidence of control
Example for a Project Manager
Groom weekly with delivery leads. Write dependencies with named consequence of slippage. Share one log with the Delivery Manager.
Things that go wrong
Night-before board updates
Vague worries without probability or impact
Separate PM and DM RAID that disagree
Decision rights
RACI / DACI
Role clarity models so Responsible, Accountable, Consulted, Informed (or Driver, Approver, Contributors, Informed) are unambiguous.
When to use it
Cross-team or supplier seams
Unclear who decides on scope or risk
Escalations bounce between roles
Example for a Project Manager
Publish RACI for value (PO), delivery health (DM), and control/baselines (PM). Use DACI for major decisions so Approver is never implied.
Things that go wrong
RACI that lives only in a slide
Multiple Accountables for the same decision
Consulting everyone until nothing moves
Change
ADKAR
Individual change journey: Awareness, Desire, Knowledge, Ability, Reinforcement. Useful when project outcomes depend on adoption.
When to use it
Staff or citizen behaviour must change for benefits
Training alone is not moving adoption
Resistance shows up as quiet non-compliance
Example for a Project Manager
Partner with Change Management. Diagnose which ADKAR stage is stuck before adding more go-live communications. Plan Reinforcement after exit.
Things that go wrong
Training before Desire exists
No Reinforcement, so old habits return
Treating ADKAR as a comms plan only
Scaling
SAFe (selective)
Enterprise scaling with Agile Release Trains and PI Planning. Heavyweight by design; adopt pieces only when synchronisation is the hard problem.
When to use it
Many teams must synchronise on a shared cadence
Organisation already committed to an ART model
Portfolio visibility across dozens of teams is required
Example for a Project Manager
If sponsors push SAFe, show the scale/formality trade-off. Only adopt PI Planning and coordination pieces you need; do not import every layer because the chart looks complete.
Things that go wrong
Installing SAFe as ceremony without fixing team-level flow
Role inflation that creates more hand-offs
Estimating
Reference class forecasting
Use outcomes from similar past projects to challenge inside-view optimism when setting dates and costs.
When to use it
Large novel programmes with thin precedent in the room
Business case dates look ambitious
Optimism bias keeps surviving challenge
Example for a Project Manager
Bring comparable project outcomes into OBC/FBC conversations. Separate ambition from forecast and show contingency explicitly to the SRO.
Things that go wrong
Cherry-picking flattering comparators
Ignoring unique constraints that worsen the forecast
Using reference class once, then reverting to hope