PM² and OpenProject are a natural match: one is the European Commission’s free and open methodology for project management, the other an open source project management software. This article shows how the two come together, worked through on a showcase project. The OpenProject configurations shown throughout the article illustrate one possible way of implementing PM² in practice.
PM² is the official project management methodology of the European Commission, resources and artefacts are open and free to use. It is designed as a light and easy-to-implement framework, which project teams can tailor to their specific needs. OpenProject itself offers a PM² Project Management Methodology Guide and a detailed guide to implementing PM² in OpenProject.
Remarque
PMflex is an extension of PM², developed and maintained by the Federal Office of Administration (BVA), and targeting German federal authorities and other public-sector bodies. PMflex methodology can also be used in OpenProject.
In this article, we follow the fictional Project Manager Zhara as she carries out her project using PM² in OpenProject. In our scenario, she works for the city administration of Beaumont, a mid-sized town in France, where she is launching a municipal open data portal to make the city’s data openly and freely accessible to the public. We assume that the city administration is also using OpenProject for other projects and that the organization is already fully set up in the application. The necessary preparations for working with PM² have also already been put in place.
To show what working with PM² in OpenProject looks like, we follow Zhara as she works on her project through all phases of PM², from the Project Initiation Request to the Project-end Report.
Quick navigation
Conseil
We recommend familiarizing yourself with PM² beforehand, as this article is not an introduction to PM² but rather explains the execution of PM² methods in OpenProject.
Initiating Phase
The open data portal has long been a priority for the Beaumont city administration. It has been mentioned in many discussions, but now the city is finally set to implement it in a structured way. Cyril Dupont is the head of the Digitalization and IT Department in the Beaumont city administration and serves as the Project Owner. At the Initiating Meeting, he meets with Catherine Johnson, who came up with the original idea for the project and therefore acts as the Initiator. After this meeting, Cyril has enough information to complete the Project Initiation Request. In doing so, he creates a new project in OpenProject based on the template for a PM² project and fills out the user-friendly wizard that guides him through all the predefined questions. The Project Initiation Request then appears directly in the project as a work package, so that Cyril can finalize it and submit it through the formal approval processes.
He also formally launches the Initiating Phase (which begins with the submission of the Project Initiation Request) by updating the data in the project’s predefined project life cycle and adding everyone responsible for the next steps, each in their respective role. Thanks to the formalized roles that exist in every PM² project, Cyril can easily replace the placeholder users — with their corresponding roles and permissions from the PM² template — with actual users from his OpenProject instance, for example, the Project Manager becomes Zhara Khan, and the Solution Provider becomes Malik Al-Saud, who is the Tech Lead of the external IT service provider. This way, permissions are assigned correctly from the start, without anyone having to configure them manually.
Screenshot: Project Initiation Request Wizard, already filled with data.
The other two artifacts that must be created during the Initiating Phase are the Business Case and the Project Charter. These, too, are created as custom work packages that have already been defined in the template. Zhara, who is responsible for the Project Charter, simply needs to fill in the pre-written descriptions, and the document is generated automatically. Since all artifacts are permanently stored in OpenProject as work packages, there is a single source of truth, responsibilities are assigned from the start, and changes are easily traceable in the Activity tab of the respective work packages.
Screenshot: Work package table including all artifacts from the initiating phase with visible status, assignee, and project phase.
To pass through the RfP (Ready for Planning) Gate, all artifacts must be approved by the appropriate person or group. Following the approval processes defined by the PM² methodology, the Beaumont city administration maps the required approvals using custom fields. The Activity tab makes it easy to keep track of who has approved what and when. Once all necessary artifacts have been approved, Zhara can proceed to the Planning Phase. The project life cycle in OpenProject shows the corresponding phase and gate dates and automatically keeps the schedule of subsequent phases consistent when dates change.
By the end of the Initiating Phase, the project already has a strong foundation with clear permissions, responsibilities, and traceable artifacts. Starting from a predefined PM² project template saves setup time and provides a consistent structure from the outset.
Planning Phase
The Planning Phase is an artifact-heavy phase. During this stage, the project is “brought to life”; work packages are created, linked, and scheduled. It is especially important now for Zhara, who is primarily responsible for many aspects of the project, to maintain an overview.
The Planning Kick-off Meeting is the first meeting of the phase. Zhara is responsible for planning and conducting it, and she uses the administration’s predefined meeting templates. Meeting templates contain a ready-made agenda for a type of meeting — which she only needs to slightly customize for her project — as well as attached documents for record-keeping.
Screenshot: Agenda draft of the Planning Kick-off Meeting in OpenProject’s Meetings Module
The Project Handbook is one of the project’s most important artifacts: it summarizes the objectives, documents the selected approach for achieving them, and records various processes, rules, and policies. Since the document must be kept up to date at all times and also serves as a frequently used reference during the Executing Phase, Zhara decides to create only a task for it as a work package. She structures the document itself as hierarchical pages in OpenProject’s wiki module. There, she can also tag users, track changes, link work packages, and much more. This turns the Project Handbook into an actively used reference that is maintained right where the work takes place.
Conseil
OpenProject lets you lock wiki pages. This allows the Project Manager to easily prevent the Project Handbook from being edited accidentally or without authorization.
Screenshot: Subpage “Project Processes” in the Project Handbook in the OpenProject Wiki module with links to various resources.
Additionally, Zhara is responsible for the following artifacts: the Project Stakeholder Matrix, the Outsourcing Plan, the Deliverables Acceptance Plan, and the Transition Plan. The Business Implementation Plan is also created in the Planning Phase, but the Business Manager is responsible for it. As before, each artifact is again a work package, with automatic document generation, approval processes, and attributes already defined. As the project begins to fill with work packages, Zhara decides to add a filtered view of work packages, just for the artifacts she is currently working on.
Screenshot: Filtered work package view with only artifacts for the planning phase visible. The “Project Handbook” is open in a side panel to show the link to the wiki module.
Remarque
This is just one possible way to work with PM² in OpenProject, and does not cover all of OpenProject’s features that can be used during the course of a project. With a tool as customizable as OpenProject, there is often more than one way to reach a given solution. Also, for other requirements and processes PM² may have to be implemented differently.
However, the most important part of the planning process is still missing: the work itself. The Project Work Plan defines all the tasks necessary to achieve the project goals. For Zhara as a Project Manager, the Project Work Plan consists of two parts: on the one hand, the document-like artifact, and on the other hand, the tasks, deliverables, milestones, and assignments in OpenProject itself. In collaboration with the Project Core Team, Zhara begins to break down the workload into manageable tasks, defines milestones, and schedules them using bulk edits to update many at once. Particularly important are Gantt charts, which allow Zhara and her team to view the tasks on a timeline, estimate the workload, and monitor interdependencies.
Screenshot: High-Level Project Timeline Gantt Chart with tasks, milestones, and phases. Successor and predecessor relations are visualized.
Another important part of the Project Work Plan is estimating resources, such as working hours and budget. Rather than calculating these values manually, Zhara activates the “display sums” option for work package tables and gets a clear overview of the totals for work hours and costs, which she can filter further. As defined in the artifacts, Zhara adds the budgets allocated to her, in the Budget module, and itemizes the individual costs. This lays the foundation for later allocating time or units precisely to a specific work package, which makes later reporting precise.
Screenshot: The “Internal Team & PM” budget in the Budgets module, showing planned and actual costs. The labor costs breakdown by work package is further down the page, beyond this view.
For the next step, Zhara uses the Resource Management module of OpenProject to assign the tasks to specific people, based on their availability and skills. Since the project is being carried out in collaboration with an IT service provider, she uses the staffing for roles filled by the provider. This allows her to specify the skills a person needs, and the IT service provider can then assign an appropriate person.
Screenshot: Resource Planner for the Executing Phase, with tasks allocated to team members across a daily timeline.
Zhara communicates closely with her team, stakeholders, and managers during this phase. New ideas keep coming up in many meetings — to collect, categorize, and, if necessary, act on them, there are several logs in PM². These logs, namely the Change Log, Risk Log, Issue Log, and Decision Log, are implemented in OpenProject as filtered work package tables with specific work package types like “Change”, “Risk”, “Issue”, and “Decision”. This lets each type of information surface where it naturally belongs. For example, during a meeting with her manager, the question of dataset licensing arises: Who is allowed to use the datasets, for what purposes and which data may be subject to special restrictions? In the image below, Zhara creates a new work package of type “Risk” directly from the agenda item in the meeting. She can then quickly retrieve it in the Risk Log, and the work package’s “Meetings” tab also shows which meeting it was created from. This allows Zhara to easily figure out what the risk was about, even if the conversation took place a few days ago. As it is a work package, she can also assign someone to tackle the risk.
Screenshot: The Risk Log as a filtered work package table, with one risk opened on its “Meetings” tab showing the meeting it originated from.
Once all artifacts have been created and approved, and the work itself has been broken down into various types of work packages and assigned, and by passing the RfE (Ready for Executing) Gate and proceed to the next phase. During the Planning Phase, it becomes clear how the plan and the work evolve together, because the team organizes every aspect of the project in one place. Tasks, milestones, documents, budgets, and time tracking all live in the same system, so relations and interdependencies stay easy to monitor and nothing has to be kept in sync across separate tools. It provides structure without constraint: a reliable framework that still leaves room for each person’s way of working. By the end of this phase, planning and working remain closely linked, so the team can actually rely on the plan throughout execution rather than constantly updating it to match reality.
Executing Phase
For Zhara, the Executing Phase primarily consists of coordination, monitoring and controlling, and quality management. As her team, together with the external IT service provider, starts to build and fill Beaumont’s new open data portal, she faces a lot of meetings and coordination work. During this phase OpenProject supports her by bringing the relevant information together in one place and mapping her processes onto its structure. The first event of this phase is the Executing Kick-off Meeting. Zhara once again uses a meeting template to set it up.
To ensure that both her own team and the IT service provider have all the information they need for their work, Zhara needs a practical system for information distribution, which she has already outlined in the Communications Management Plan. Among other things, this plan calls for a number of regularly scheduled meetings. For Zhara, these are easy to implement in OpenProject: she can use templates, set flexible recurring meetings and link work packages directly.
But of course, not everything in project work always goes according to plan. When Zhara receives the first design drafts for the future portal, she notices some issues with accessibility. As everyone is working with the same work packages, but she wants to discuss the issue with her own team before responding to the external designer, she uses OpenProject’s internal comments. This allows her to write messages that are visible only to her own team, while avoiding the need to open a separate channel. This way, she can get input from her team right away, before responding.
In addition to project coordination, Zhara’s main responsibilities during the Executing Phase include monitoring and controlling. Zhara is responsible for keeping track of project activities and therefore of a wide variety of parameters: How much money has been spent? How many work packages were completed, and by whom? How much work was done, and on what? OpenProject brings these questions together in one place.
One thing Zhara does almost every day as soon as she starts work is a baseline comparison. This feature allows her to see at a glance what has changed in her work packages, for example, how much work time has been logged or whether assignments or statuses have changed. Zhara performs this baseline comparison for different views of her work packages, such as her logs, the list of deliverables, or filtered views based on her assigned team members.
Screenshot: A baseline comparison on the deliverables view, highlighting what has changed since the previous day, such as updated statuses, titles, and assignees.
But Zhara wants to find out not only what has happened in the last few days, but also where her project stands now. For this, the project home page — which every project has — is useful. It includes a dashboard and an overview. For these pages, OpenProject offers a variety of customizable widgets that display a wide range of project parameters in real time. This allows Zhara to see these parameters at a glance which is useful for her decision-making, and then share this information with other stakeholders. Let’s take a closer look at the widgets.
On the dashboard, Zhara configures the two widgets presented below. The “Processing of Risks” widget monitors the status of the project’s risks. It is implemented as a work package graph widget filtered by work packages of type “Risk”. As a second component, she configures a widget that shows the project’s progress in terms of its deliverables. Since each deliverable includes all the tasks necessary for its completion, the effort is also totaled across the corresponding underlying tasks. A view of deliverable progress therefore gives a concise picture of the project’s overall progress.
Screenshot: Two dashboard widgets, the “Processing of Risks” graph and a view of the deliverables’ progress.
Conseil
The dashboard and overview pages are highly customizable and can therefore provide answers to many questions. The examples here provide just a short overview of what is possible with widgets in OpenProject. For more information, please refer to our documentation about project widgets.
The Budgets widgets, which are equally important for Zhara, can only be found on the overview page. The data is automatically displayed as shown below and the widgets provide Zhara with a quick overview of how her project is performing financially and where it currently stands, but they only show real-time data. For historical analyses, Zhara must rely on reporting.
Screenshot: The budget widgets on the project overview page, showing planned and actual costs, a breakdown by cost type, and actual costs by month.
Reporting is the other part of controlling and monitoring the project and means that Zhara has to prepare detailed project updates for supervisors and stakeholders. Here, project data not only helps her stay informed and prepared, but also gives others the background they need for important project decisions. Reporting can be a complicated and labor-intensive task. At the same time, it must be carried out accurately and reliably, even during project coordination. In OpenProject the “Budgets” and “Time and Costs” modules work together with time tracking features to keep the effort low, as long as the preparation is done thoroughly.
As specified in the PM² methodology, Zhara should create the following reports:
- Project Status Report
- Project Progress Report
- Contractor Status Report
- Custom or Ad Hoc Reports
All of these were defined and prepared in the Project Handbook, or more specifically in the Communications Management Plan. One custom report Zhara decides to create is one displaying the labor costs of the initiating phase. The data can be exported in various formats, making it easy to create clear, informative charts.
Screenshot: A cost report in the Time and costs module, grouped by user and work package, showing the logged labor hours for the Initiating Phase artifacts.
The third major pillar for Zhara during the Executing Phase is quality management. All the measures taken are predefined in the Quality Management Plan, which is created in the Planning Phase.
For Zhara, quality assurance means there is a “Quality Review” work package type, which can be added as a child of deliverables and is used for all quality assurance tasks. Imagine the deliverable “Publication-Ready Datasets: Finance”, which includes a work package of type “Quality Review” with the title “GDPR compliance review”. The latter can easily be assigned to Beaumont’s data protection officer, who can attach their report or checklist directly to the work package. This ensures that all necessary information is in one easily accessible place, which also facilitates quality control when the individual deliverables are compared against the Deliverables Acceptance Plan.
For Zhara’s new open data portal, quality control is also very important. No one benefits from a well-curated portal that is, however, unusable. Because she knows this, Zhara sets up a test launch followed by a dedicated “test launch recap phase”. In this phase, the open data portal is used by a limited audience, and any problems that arise can be resolved in time. OpenProject makes it possible for Zhara to build a custom workflow for this: the phase includes work packages of type “Test”, which have specific statuses. A custom Kanban board makes it easy to see which status each one is in. If a test fails, Zhara or the relevant team member creates a related work package of type “Issue”, which then automatically appears in the Issue Log and can be assigned and handled from there.
Screenshot: A custom Kanban board for the test phase, with “Test” work packages sorted into the columns New, In testing, Test failed, and Passed.
The Executing Phase is usually the longest phase of the project, and it is normally completed when all deliverables are complete. An important aspect of this control process is the Phase Exit Review Checklist, which guides the assessment, alongside a review of the phase’s specific goals carried out by the Project Manager. As soon as these requirements are met, the Project Steering Committee is responsible for authorizing the Project Manager to move the project through the RfC (Ready for Closing) Gate to the next and final phase.
In the Executing Phase, having everything on a single platform has paid off the most. Because meetings, artifacts, time tracking, and reporting are part of the same system, the same data serves both inward and outward transparency. Since that data is available in real time, Zhara keeps a clear overview even in the busiest phase of the project. OpenProject’s features also make it possible to always view project components in context and, for example, track a work package through meetings, logged time, or baseline comparisons to get the full picture. As a result, the team can always trace why something was created or done a certain way, instead of having to reconstruct it later — saving time that would otherwise go into information transfer.
Closing Phase
In the Closing Phase, the project is nearing completion, and most of the work has been done. Still, this is a key time for retaining the knowledge gained within the organization and integrating the project into its structures. The phase starts with the Project-End Review Meeting. This meeting serves as the basis for the Project-End Report, which, as with all other PM² artifacts, is created as a separate work package type. The Lessons Learned and Post-Project Recommendations, which are mainly discussed and documented in this phase, are highly project-specific and can lead to a range of actions, ranging from project expansion to early termination (for example, if deliverables cannot be met).
Although there were some hurdles, the project went very well for Zhara. But what matters most to her is what will happen to the portal after the project ends. Technical maintenance is handled by the external IT provider, but the data should also be updated annually. That is why she is advocating for making this maintenance part of a team’s ongoing responsibilities. To ensure that none of this information is lost, while still marking the project as completed, the city administration decides to archive the project. This way, the project can be closed cleanly, while ensuring resources are preserved for the long term and knowledge stays in the organization in an accessible way.
Additional: Implementing PM²-Agile
OpenProject supports not only classic but also agile project management. The PM²-Agile extension can be implemented as well. You can learn more about OpenProject’s features for agile work on our website, and about current development priorities in our blog post “News from the Product Desk: The future of agile reporting in OpenProject”.
Conclusion
We followed Zhara through all four PM² phases: from the Project Initiation Request, through the Planning Phase, into day-to-day coordination and monitoring, and finally to the Project-End Report. In every step, PM² defines the methodology and OpenProject provides the place where that methodology actually gets done.
But what makes this combination so effective is not just the well-thought-out methods of PM² or the customizable, feature-rich environment of OpenProject — it is the shared project management principles such as single source of truth and the pursuit of transparency that bring the two together. That fit is no coincidence. PM² is the European Commission’s free and open methodology, and OpenProject is open source project management software. Both put visibility and collaboration at their core, both can be adopted and adapted to a team’s own needs without vendor lock-in. This open nature makes them a strong choice for organizations that value digital sovereignty.
Zhara’s open data portal is just a fictional example, and just one possible way to work with PM² in OpenProject. The best way to see how it feels in practice is to try it out yourself. In our free trial, set up a PM² project from the template and explore the modules. If you’re interested in the general direction OpenProject is heading, we recommend taking a look at our roadmap.
