Large corporate systems often tend to standardise project approaches. Sometimes this is justified and simplifies processes, but sometimes it is driven by mistrust and a desire for control. Outcomes depends on circumstances such as diversification of product and service portfolio, geographical spread, regulatory frameworks and availability of resources. PM²
Public administrations and international organizations face all of the aforementioned challenges and add some of their own, such as local support for initiatives, differing political interests, and corruption.
In such an environment, the introduction of a single project methodology (despite the benefits it can bring) is a very challenging task. On one hand, such a methodology needs to establish a solid hierarchy of decision-making and accountability. On the other hand, it has to recognise that we are living in the 21st century and that management of successful technology initiatives is practically the antithesis of hierarchy and reporting.
The European Commission became aware of these challenges almost twenty years ago and sponsored the development of a project methodology called PM² (PM square).
Evolution of the methodology
Waterfall phase
The development of PM² started in 2007 within the European Commission as an internal approach for IT project management. The reason was the need for a single, pragmatic and lightweight methodology adapted to the complex institutional environment of the EU. Which was not adequately covered at the time by either PRINCE2 or PMBOK. The first version of PM² was presented in 2008 and then piloted in selected European Commission projects in 2009, supported by in-house training.
Agile add-on
In 2014, the European Commission introduced Agile@EC (later PM²-Agile), which added agile principles to the existing PM² framework for managing technological development projects. It was only with this addition that PM² actually became suitable for managing IT projects – which is what it was intended to do from the start. In practice, at this point the operational PM² approach split into two branches:
- PM² for the management of traditional projects such as railways or bridges
- PM²-Agile for managing development projects, especially in IT
Given my predominant interest, I will focus on PM²-Agile in this article.
Open standard
A key moment in the history of PM²-Agile was in 2016, when the European Commission released the“PM² Guide – Open Edition” under an open licence. With this, PM²:
- was made freely accessible to the public,
- went beyond the narrow confines of the EU institutions,
- became useful for Member States, their public administrations, contractors and the private sector.
This initiative, known as Open PM², was formally extended in 2017, when the Commission started to actively promote the external use of the methodology.
PM² Alliance
In 2018, the PM² Guide v3.0 was released and the first Open PM² Conference was organised. In the same year, the PM² Alliance, an independent international community of practitioners supporting knowledge sharing, events and the dissemination of the methodology beyond the European Commission, was established. During this period, PM² received support from European programmes (ISA², later Digital Europe), consolidating its role as a European reference project standard.
What are PM² and PM²-Agile
PM² and PM²-Agile do not bring anything new to the waterfall and agile practices. They are just clear, concise descriptions of the PMP project approach for waterfall and the Scrum and Lean practices for agile.
A couple of examples from PM²/PM²-Agile:
- Waterfall is divided into initiation, planning, execution, closure and monitoring phases
- It uses established waterfall practices such as WBS, phase gates, project plan, RASCI matrices, risk plan, etc.
- Agile teams are structured similarly to Scrum teams, but some roles are named differently:
- Developer – Agile Team Member (ATeM)
- Scrum Master – Team Coordinator (TeCo)
- Product Owner – Product Owner (PrOw)
- Architect – Architecture Owner (ArOw)
- Agile teams iteratively develop prototypes and MVPs, estimate the size of work packages with planning poker, perform demos of product increments at the end of iterations, etc.
In addition, PM² adds an organisational superstructure for programme and portfolio management.
Why do I believe PM² is a useful methodology?
The real innovation that the approach brings to the project world is a core organisational structure that is common to both PM² and PM²-Agile.
In this structure, agile development practices such as Scrum are represented in the Project Core Team (PCT). Product Discovery practices, which support agile development and ensure that the product has business value, are practised at all three lower levels.
PM² integrates agile practices into the traditional hierarchical organisation of government bodies. Although not ideal, in my opinion it is the underlying PM² organisational structure that positions the approach as the best candidate for introducing agile processes into public administration projects. At first glance, the structure may seem complex, but it is much simpler than, for example, SAFe, which is its corporate competitor.
The roles represented in PM² are:
PM² positions itself as a flexible project framework that adapts to organisational needs. In my opinion, at least for small and medium-sized IT development projects, several of the roles described above will often be combined into a single role.
- On the client’s side, the responsibilities of the Project Owner, Business Manager and Product Owner will probably be merged into one for the sake of rationality.
- On the contractor’s side, the responsibilities of the roles of Solution Provider (i.e. the person, not the organisation) and Project Manager will be combined. In the extreme case, this person will also take on the role of Scrum Master.
The reality of PM² adoption
Outside the European Institutions, in the public administrations of the Member States, PM² is not yet as widespread as the European Commission would like it to be. Poland is the furthest along this path, followed by Greece with individual initiatives.
As a consequence of encouraging the use of the PM²-Agile approach, certain Member States have succeeded in including the specifics of the Agile project approach in the public procurement legislation. Examples are incremental funding and assessing the success of initiatives based on KPIs of generated business value rather than the amount of realised solution functionalities. The suitability of Member States’ legislations for “innovation procurement” is described in the European Commission’s 2024 report, which ranks Slovenia 18th.
Conclusion
PM²-Agile’s unique structure makes it a good basis for managing complex IT development initiatives in public sector. It contains all the elements that make agile approaches effective on both the pure development and product side.
At a time when Europe is re-establishing its sovereignty, a unified project approach is a desirable tool to optimise much-needed innovation and development initiatives.
