PM²: The Project Methodology Europe Uses (and Most Teams Ignore)

The methodology sitting in plain sight

Most project managers in Europe have heard of PM². A smaller number have actually read the guide. An even smaller number have used it on a real project. That gap is a problem, because PM² was designed specifically for the kind of work that public administrations and EU-funded projects do every day — multi-stakeholder governance, fixed budgets, procurement constraints, accountability to citizens — and it handles those conditions better than frameworks built for commercial software teams.

I came to PM² from the opposite direction: years of Accenture waterfall delivery, then agile product work at startups, then back into structured programme management for large digital transformation programmes. When I first read the PM² guide properly, I recognised a lot of the patterns I had learned the hard way. The framework had just named them and put them in a logical order.

This article is not a summary of the guide — you can download that for free from the European Commission's Open PM² website. It is a practical account of what PM² looks like when you actually apply it, where it helps, and where you have to supplement it.

What PM² actually is (and is not)

PM² is a project management methodology developed by the European Commission's Centre of Excellence in Project Management (CoEPM²). It covers the full project lifecycle: Initiating, Planning, Executing, Closing, and a cross-cutting Monitor and Control phase that runs throughout. It defines roles, artefacts, governance structures, and a set of mindsets it calls the PM² Mindset — things like stakeholder focus, results orientation, and ethics.

What it is not is a heavyweight compliance exercise. One of its core principles is right-sizing. You are explicitly expected to tailor the artefacts and processes to the size and complexity of your project. A small internal digitisation project does not need the same governance apparatus as a cross-border infrastructure programme. The guide gives you a catalogue; you choose what you need.

It also has an agile extension, PM²-Agile, which integrates Scrum and Kanban practices into the PM² governance structure. I will come back to that, because it is more useful than it sounds.

The governance model is where PM² earns its keep

The single thing PM² does better than most frameworks I have worked with is governance clarity. It defines four core roles with genuine separation of concerns:

• Project Owner (PO): the business side, accountable for the outcome and the business case. Not the project manager. Not IT.
• Solution Provider (SP): the delivery side, accountable for producing the outputs. In a vendor engagement, this is often the supplier's lead.
• Project Manager (PM): accountable for the plan, the risks, the budget, and the day-to-day coordination between all parties.
• Business Manager (BM): the operational owner on the business side, who will actually live with the delivered system and manage the transition.

Above these sits the Project Steering Committee, which includes the Project Owner and Solution Provider at senior level and makes decisions that are outside the Project Manager's authority — scope changes, budget overruns, strategic pivots.

This structure sounds obvious on paper. In practice, most troubled projects I have seen were troubled because these roles were blurred. The IT department was acting as Project Owner and Solution Provider simultaneously, with no independent business voice. Or the Project Manager was making strategic decisions that should have gone to a Steering Committee that never actually met. PM² forces you to name who is accountable for what before you start, and that discipline alone prevents a category of problems that kill projects in the execution phase.

On a digital transformation programme I worked on spanning fifteen countries, the governance clarity was the thing that made coordination possible. We had national project managers in each country, a central programme office, multiple vendors, and a sponsoring executive layer. Without a shared model for who escalates what to whom, and what decisions require which level of sign-off, the programme would have collapsed under its own weight. PM² gave us the shared vocabulary.

The artefacts that actually matter in practice

PM² defines a full set of project artefacts — from the Project Initiation Request through to the Project Closure Report. In a right-sized implementation, you will not produce all of them. In my experience, the ones that pay for themselves every time are these:

1. Project Charter: the single document that defines scope, objectives, assumptions, constraints, and the governance structure. If you can get all stakeholders to sign a well-written Project Charter, you have done most of the hard work of alignment before a line of code is written. Arguments that happen later — about whether something is in scope, who has authority to approve a change — are usually arguments that should have been resolved in the Charter.
2. Risk Log: not a bureaucratic list produced once and filed. A living log that the Project Manager reviews with the team regularly and escalates to the Steering Committee when risks cross defined thresholds. PM² is explicit that risk management is continuous, not a phase.
3. Issue Log: separate from risks. Issues are problems that have already materialised. Keeping them distinct forces you to track what you are actually managing versus what you are still trying to prevent.
4. Change Log: every approved change to scope, schedule, or budget, with the decision trail. In public sector projects this is not optional — you will need to demonstrate to auditors how the project evolved and who authorised each change.
5. Project Status Report: a regular, structured communication to the Steering Committee. PM² gives you a template. Use it, or a version of it, and send it on a fixed cadence. The discipline of writing a status report forces you to know the actual state of your project, which is harder than it sounds.

The artefacts I tend to scale back on smaller projects are the detailed Transition Plans and the elaborate Business Implementation Plans — not because they are unimportant, but because on a small project the Project Manager and Business Manager can handle that coordination directly without a formal document for every step.

PM²-Agile: the combination that makes sense for digital services

When I first looked at PM²-Agile, I expected a clumsy bolt-on — waterfall governance with a Scrum ceremony stapled to it. It is actually more coherent than that.

The core insight of PM²-Agile is that governance and delivery can operate at different cadences. The PM² governance layer — Steering Committee decisions, formal change control, budget and risk reporting — runs at a slower rhythm appropriate to institutional accountability. Inside that governance frame, the delivery team runs sprints, maintains a product backlog, holds retrospectives, and ships incrementally.

This is not a compromise. It is an accurate description of how good digital public service delivery actually works. A government department cannot abandon budget accountability and formal change control — it has legal obligations and public money at stake. But it also cannot afford to define every requirement upfront and deliver a monolithic system eighteen months later. PM²-Agile gives you the structure to do both: accountable at the governance level, adaptive at the delivery level.

The practical integration points are: the Project Charter defines the outcome and the overall envelope, not a detailed feature list; the backlog is the living expression of scope within that envelope; sprint reviews serve as the delivery-level progress signal; and formal change requests go to the Steering Committee only when the sprint team needs to move outside the agreed envelope. Most sprint-level decisions stay at the team level, which is where they belong.

The honest limitations

PM² is not perfect. A few things to be aware of:

The documentation can feel heavy for genuinely small projects. Right-sizing helps, but it requires judgment, and junior project managers often err on the side of producing every artefact because they are not confident enough to decide which ones to skip. A good PM² coach or a more experienced PM on the team makes a significant difference here.

The methodology is also relatively silent on product management as a discipline. It covers project delivery well — outputs, governance, change control — but it does not deeply address how you discover what to build, how you validate with users, or how you measure outcomes after go-live. For digital public services, you need to layer product management practices on top of PM², or use PM²-Agile in a way that genuinely integrates user research and outcome measurement into the delivery cycle. That integration is not automatic.

Finally, PM² assumes a relatively stable institutional context. It works well when you have a clear Project Owner with genuine authority and a Steering Committee that meets and makes decisions. In organisations where governance is dysfunctional — where the Project Owner is nominal, the Steering Committee never convenes, or budget authority is unclear — PM² will surface those problems but cannot fix them. No methodology can substitute for organisational will.

Where to start if you want to use it

The PM² guide and all supporting artefact templates are available free of charge on the Open PM² portal. There is also a community of practice, training providers, and a certification path if you want formal recognition.

My practical recommendation: read the guide once end to end to understand the logic, then pick your next project and apply only the governance structure and the five artefacts I listed above. Do not try to implement everything at once. Get comfortable with the Charter, the logs, and the status report rhythm. Once those are habits, the rest of the framework becomes easier to layer in where it adds value.

PM² is not exciting. It does not promise to transform your organisation or unlock AI-powered delivery. What it does is give public sector project managers a coherent, right-sized, openly available framework designed for the actual constraints they work under. That is more valuable than it sounds, and it is sitting there waiting to be used.