Project Handbook in PM²: the project’s operational reference
Twenty-sixth article in the “Learning PM² Through a Project” series
A project can have a clear Charter and still work in a confused way: roles are not updated, plans are scattered, logs are hard to find, each person follows different rules and decisions lack a reference point.
The PM² Project Handbook is the operational container that brings together the information needed to manage the project consistently. It is not a document written to be archived: it must be accessible, maintained and tailored to actual project complexity.
Charter, Handbook and Work Plan: three different levels
| Artefact | Question it answers |
|---|---|
| Project Charter | What is the project, why does it exist, who governs it and what are its initial limits? |
| Project Handbook | How will the project be organised and managed day to day? |
| Project Work Plan | Which work will be done, with which estimates, dependencies and dates? |
The Handbook does not replace the other two. It connects them: it starts from the Charter mandate, incorporates or refers to plans, and makes the Work Plan usable through roles, processes, logs and operating rules.
What the Project Handbook contains
PM² structures it as a collection of elements that the PM tailors to the project. Not everything must always be present or have the same detail level.
| Section | Typical content |
|---|---|
| Roles and responsibilities | Project organisation, governance, RAM/RASCI and delegations. |
| Project Management Plans | Plans for requirements, changes, risks, issues, quality and communication. |
| Project-Specific Plans | Acceptance, transition, business implementation and outsourcing plans, where relevant. |
| Domain-Specific Artefacts | Technical, security, data-protection, UX, procurement or other applicable artefacts. |
| Other references | Project Work Plan, Stakeholder Matrix, logs, repository, tools, conventions and decisions. |
The Handbook may be a structured document with annexes, a collaborative space with linked pages or a set of versioned artefacts. What matters is an authoritative source, an understandable structure and current references.
The tailoring principle
PM² is intentionally adaptable. Tailoring does not mean removing everything that looks like documentation; it means retaining only what adds value to project control, without losing essential governance and traceability.
| Situation | Reasonable tailoring |
|---|---|
| Small internal project, stable team | Lightweight Handbook, with short sections and essential logs in one space. |
| Project with many stakeholders and an external supplier | More detailed plans and responsibilities, formalised communication and acceptance rules. |
| High-risk or regulated project | Greater evidence for quality, security, decisions, audit trail and controls. |
It is not tailoring to say: “we do not have time for the Risk Log”. If risk exists, the project needs a proportionate way to manage it. Tailoring chooses form and depth; it does not deny the need.
A useful Handbook is action-oriented
Every section should help someone decide or work better. A simple check is:
| Content | Usefulness check |
|---|---|
| Roles | Does a person know who decides, who performs and who to escalate to? |
| Risk plan | Is it clear where to record a risk, who owns it and how to monitor it? |
| Change plan | Is it clear how to propose, assess and approve a change? |
| Communication | Does every stakeholder know which information they receive and where to find the official source? |
| Quality / acceptance | Are criteria, evidence and responsibilities known before delivery? |
If the answer is no, adding pages does not solve it: content must become more operational or take a different form.
Governance and responsibilities in the Handbook
The Handbook is the natural place to make RAM/RASCI usable. An organisation chart is not enough: material activities should make clear who is Responsible, Accountable, Support, Consulted and Informed.
| Activity | Example Handbook clarification |
|---|---|
| Approve a material change | Who prepares the analysis, who decides, who is consulted and informed. |
| Accept a deliverable | Criteria, verifier, acceptor and exception handling. |
| Manage a critical issue | Owner, escalation threshold, channel and competent authority. |
| Prepare go-live | Responsibilities for technical transition, training, support and readiness decision. |
This prevents both “everyone is responsible” and “nobody has authority”.
The Annotatio case: a lightweight but complete Handbook
For Smart Bookings, the Handbook does not need to become a hundred-page manual. It can have a practical structure:
| Section | Content |
|---|---|
| Overview | Link to Charter, objective, initial scope, main milestones and official repository. |
| Roles | PO, SP, BM, PM, technical team, pilot managers and RAM for key decisions. |
| Work Plan | Link to the plan with activities, dependencies, owners and dates. |
| Essential plans | Lightweight rules for requirements, change, risk, issue, quality and communication. |
| Acceptance and transition | Waiting-list criteria, tests, go-live checklist, support and notification fallback. |
| Logs | Links to Risk, Issue, Change and Decision Logs with owner and status. |
| Technical documentation | API, push configuration, roles, operating instructions and runbook. |
The purpose is not to duplicate information. It is to let a person joining the project quickly understand how work is done, which decisions matter and where the reliable source is.
Versioning and maintenance
A static Handbook quickly becomes dangerous because it gives a false sense of control. The PM should define at least:
- where the official version resides;
- who may modify main sections;
- when changes need review or approval;
- how updated plans and logs are linked;
- which version was approved at RfE and which subsequent updates are material.
Not every update needs a committee. Updating a contact or operating date may be routine; changing roles, tolerances or the acceptance process may need a controlled decision.
Do not confuse these
| Statement | Correction |
|---|---|
| “The Handbook is an additional document alongside plans.” | It is the container or access point connecting plans, roles, logs and rules. |
| “Tailoring means reducing documentation to the minimum.” | It means calibrating artefacts to value and risk while retaining control and traceability. |
| “If we have Jira or Teams, we do not need a Handbook.” | Tools do not replace structure, rules and an authoritative source. |
| “The Handbook is completed in Planning and never changes.” | Keep it alive as roles, plans, governance or operating conditions change. |
Three questions to anchor it
- Where would a new member find official rules for managing risks, changes and issues?
- Which content deserves a dedicated section because its risk or impact is high?
- Which artefact can be simplified without losing an essential decision, responsibility or evidence?
Flashcards
Q: What is the Project Handbook for?
A: To collect and connect roles, plans, logs, artefacts and operating rules needed to manage the project consistently.
Q: What is the difference between Handbook and Work Plan?
A: The Handbook explains how the project is organised and managed; the Work Plan details work, estimates, schedule and dependencies.
Q: What does tailoring mean in PM²?
A: Adapting artefact form and depth to project complexity and risk without eliminating needed control.
Exam-style question
A PM decides not to prepare a Project Handbook because all activities are tracked in a ticketing tool. After a few weeks, the team does not know which acceptance-criteria version is valid, who approves changes or where decisions are recorded.
What is the correct assessment?
Answer: the ticketing tool may contain information, but does not replace a coherent operational reference. The Project Handbook should make structure, roles, plans, official sources and links to logs and artefacts explicit, in a form proportionate to the project.
Source
The Project Handbook, Project Management Plans, Project-Specific Plans and tailoring are covered in the European Commission’s PM² Methodology Guide 3.1.
Next: Project Work Plan, moving from mandate and rules to actual, estimated and sequenced work.