"Which methodology should we use" is almost always the wrong question. In organisations of any size there is rarely a pure PRINCE2 or pure Agile environment. There is a board that wants to see something, a controller who wants to see something, and a team that works a particular way. Choosing a methodology means satisfying those three demands.
What the three frameworks actually govern
They are not competitors solving the same problem. They govern different layers.
| PRINCE2 | PMBOK / PMP | Agile (Scrum, Kanban) | |
|---|---|---|---|
| Type | Process method | Knowledge framework | Team working method |
| Answers | Who decides when | What must I control | How do we deliver incrementally |
| Scope | Fixed up front, changed via change control | Fixed up front, baselined | Evolving, prioritised backlog |
| Steering | Project Board, tolerances, exception | Baselines and variance analysis | Product Owner, sprint review |
| Reporting | Highlight Report per period | Performance report vs baseline | Burndown, increment demo |
| Phase gate | Stage Boundary with formal authorisation | Phase end with acceptance | Sprint or release boundary |
| Risk | RAID register with owners and responses | Risk register, quantitative where useful | Impediments and risk-adjusted backlog |
| Strong at | Accountability, shared mandate | Completeness, contract work | Uncertainty, fast feedback |
| Weak at | Agility when scope shifts | Heavy on small projects | Accountability to a board |
The four questions that settle it
1. Is the scope fixed, or discovered as you go?
This is the dividing line that matters most. A grid connection at twelve sites is known work: you know what has to happen, the uncertainty sits in lead times and suppliers. That is predictable work and suits a staged approach with a baseline.
A new customer portal where nobody knows which features will be used is not. There, every detailed scope you fix up front is a guess you will have to correct expensively through change control.
The practical test: can you write an acceptance criterion for the end result today that you believe will still be right in a year? Yes means predictable. No means you must work incrementally and treat scope as the variable.
2. Who has to account for this, and to whom?
Public tenders, subsidised programmes, projects under an auditor or regulator: there the question is not whether you account for things but how. PRINCE2 was designed for exactly this. Its mandatory products — Business Case, Project Brief, Highlight Report, Exception Report, End Stage Report — are precisely the artefacts an auditor asks for.
If there is no external accountability and you report only to an internal manager, that documentation load is overkill. Take the tolerances and the escalation rule, and leave the rest.
3. Is there a contract with an external supplier?
Contract work pulls towards PMBOK. Baselines for scope, time and cost are what you need to substantiate a claim or a variation discussion. Without a recorded baseline, "that was not agreed" is an opinion.
If you have a fixed-price contract and an evolving scope, you have a structural problem no methodology solves. Name it as a risk in the charter rather than hoping it works out.
4. What does the organisation already do?
The underrated criterion. A methodology that differs from what the rest of the organisation does costs you an explanation at every gate. If the PMO expects Highlight Reports, deliver Highlight Reports — even if your team works in sprints.
What hybrid looks like in practice
The most common working combination looks like this.
Above the team sits a governance layer with PRINCE2 characteristics: a Project Board with executive, senior user and senior supplier; tolerances on time, cost and scope; stage boundaries where the board re-authorises; an Exception Report when a tolerance is about to break.
Inside a stage the team works Agile: a prioritised backlog, sprints or a Kanban flow, a demo at the end of each iteration, and a Product Owner who decides ordering within the stage scope.
The join sits in two places. First, a PRINCE2 stage maps to a block of three to six sprints, and the stage boundary coincides with a release. Second, the stage's scope tolerance defines how far the Product Owner may shift things without going back to the board.
The charter then records which decisions sit with the board, which sit with the Product Owner, and where the line is. That is the one sentence in the document that really counts.
Note: "hybrid" is often a euphemism for "we did not decide". The difference is whether you have written down which element comes from which framework and why. If that is not in the document, it is not a hybrid approach — it is an undocumented one.
What goes in the charter
Whatever you choose, these five things belong in the document explicitly:
- The chosen approach, with one paragraph justifying why it fits this project.
- The decision structure: who authorises, who accepts, who escalates.
- Tolerances as numbers, and what happens on a threatened breach.
- The reporting cadence and format, matched to what the recipient already expects.
- How scope changes are handled: formal change control, backlog reprioritisation, or both at different levels.
Those five points prevent the most common mid-project governance argument: the moment it turns out the project manager assumed room the board never granted.