Planning in PM²: Turning Approval into an Executable Plan
Tenth article in the “Learning PM² Through a Project” series
After the RfP Gate, the project has a justification and a high-level definition. It is not yet ready to commit resources intensively: it must clarify how it will be delivered, controlled and introduced into the business.
That is the purpose of Planning.
Planning answers: “Do we know who must do what, when, with which resources, risks, controls and acceptance criteria?”
From Charter to Operational Plan
The Project Charter defines the project at high level. During Planning, that definition becomes concrete enough to support informed commitment to delivery.
| In Initiating | In Planning |
|---|---|
| Preliminary roadmap | Detailed schedule and milestones |
| Estimated budget | Planned budget and baseline |
| High-level scope | Work packages, activities, deliverables and dependencies |
| Initial governance | Operating arrangements, roles and decision thresholds |
| Main risks | Logs, analysis, owners and planned responses |
Planning is not merely “writing documents”. It makes the intended route to project objectives verifiable.
The Two Central Artefacts
| Artefact | Question it answers |
|---|---|
| Project Handbook | How will the project be managed? |
| Project Work Plan | What work will we do, when, and with which resources? |
Project Handbook: How the Project Will Be Managed
The Project Handbook describes the management approach. It is the shared reference for governance, responsibilities, processes, communication and tailoring.
It may clarify:
- PM² organisation and roles;
- responsibilities and RAM/RASCI;
- PSC composition and operation;
- decisions, escalation and approval arrangements;
- reporting and meeting cadence;
- risk, issue and change management;
- quality and acceptance management;
- stakeholders and communications;
- tools, repositories and documentation conventions;
- PM² tailoring;
- connection with Agile approaches, where adopted.
For Smart Bookings, the Handbook may establish monthly PSC meetings, approval thresholds for changes, Jira as the operational tool, weekly Risk Log review, and short delivery iterations for the PCT.
The Handbook is not a theoretical manual. It explains how this particular project will be governed.
Project Work Plan: The Delivery Plan
The Project Work Plan (PWP) documents detailed work packages, activities, deliverables, schedule, resources and budget. It is the main reference against which progress and deviations are monitored.
A useful PWP connects:
- expected deliverables;
- work packages and activities;
- sequence and dependencies;
- estimates and resource assignment;
- milestones and dates;
- budget;
- responsibilities;
- completion criteria;
- links to risks, transition and Business Implementation.
For Smart Bookings, the PWP may contain work packages for analysis, UX, backend, web app, mobile app, notifications, testing, pilot and release. Each should have recognisable results, clear dependencies and assigned responsibility.
A PWP is not simply a task list. A task list can help the team, but the PWP preserves the project view: deliverables, budget, milestones, dependencies and baselines. An Agile tool may support it as long as information required for governance remains visible.
Baseline: The Reference for Control
A baseline is an approved version of a plan that becomes the reference for monitoring actual performance.
Without a baseline, it is not possible to state rigorously that the project is late, over budget or out of scope: only that the plan keeps changing.
Baselines normally cover:
- scope and deliverables;
- schedule and milestones;
- budget and resources;
- quality and acceptance criteria.
Updating an operational plan because an activity is complete is not always a baseline change. A significant change to scope, time, cost or quality should be assessed and approved through the defined governance.
A baseline does not prevent change; it makes change explicit, measurable and decidable.
Project Logs: Operational Memory and Transparency
During Planning, the main logs are set up or completed. They are not passive archives; they are live Monitor & Control tools.
| Log | Purpose |
|---|---|
| Risk Log | Threats, opportunities, assessments, owners and responses |
| Issue Log | Problems that have already materialised and actions to resolve them |
| Change Log | Change requests, impacts and decisions |
| Decision Log | Decisions, rationale and follow-up actions |
| Stakeholder Log | Stakeholders, influence, expectations and engagement strategy |
| Lessons Log | Lessons captured during the project |
For Smart Bookings, the risk that notifications are unreliable on all devices belongs in the Risk Log; a defect already observed during the pilot belongs in the Issue Log. The difference matters: a risk may happen, while an issue has happened.
Planning Transition and Business Implementation
A project is not fully planned if it considers only technical construction. Planning must also prepare:
- integration and transition to operations;
- training and communications;
- updated processes and procedures;
- initial user support;
- adoption measurement;
- actions needed to realise benefits.
The Transition Plan coordinates handover of the solution to operations and support. The Business Implementation Plan organises activities that enable the business to adopt the solution and gain benefits.
For Annotatio, releasing software without instructions for gyms and customers, a waiting-list procedure or initial support would be incomplete delivery.
Quality and Acceptance Must Be Planned Early
A frequent mistake is to leave acceptance criteria until Executing. During Planning, the project should establish:
- which deliverables require acceptance;
- who checks and approves them;
- which criteria must be met;
- which evidence is required;
- how non-conformities and rework will be handled.
Acceptance is not a matter of intuition. It compares the deliverable against agreed criteria.
The RfE Gate: Ready for Executing
The Ready for Executing Gate checks that the project is prepared enough to commit resources to delivery.
Essential questions include:
- are the Project Handbook and Project Work Plan sufficiently mature?
- are scope, schedule, budget and main quality criteria baselined?
- are roles, responsibilities and decision thresholds clear?
- are main risks, dependencies and assumptions being managed?
- are transition, Business Implementation and acceptance planned?
- are the required resources and capacity truly available?
- have the PSC and competent governance bodies approved the transition?
RfE does not guarantee that the project will encounter no problems. It confirms that it is ready to manage them with a plan, governance and control reference.
Practical Case: The Plan Appears Ready but Is Not
The PCT has estimated development and testing, but nobody has defined gym training, release approval, change-request handling or post-pilot product support.
The project is not ready for RfE. The technical plan may be sound, but essential governance, acceptance, transition and adoption elements are missing.
Planning is complete only when delivery and business implementation are planned together.
Do Not Confuse
| Pair | Difference |
|---|---|
| Project Handbook and Project Work Plan | The Handbook defines how the project is managed; the Work Plan defines the work to do. |
| Operational plan and baseline | The plan evolves; the baseline is its approved version used for control. |
| Risk Log and Issue Log | A risk may happen; an issue has already happened. |
| Transition Plan and Business Implementation Plan | The first addresses handover and operational integration; the second addresses adoption and business benefits. |
| RfE and informal development start | RfE formally authorises Executing with adequate plans and controls. |
Test What You Remember
- What is the difference between the Project Handbook and Project Work Plan?
- Why is a baseline necessary?
- Where is a problem that has already materialised recorded?
- What does the Business Implementation Plan plan?
- What does RfE authorise?
Answers
- The Handbook defines management approach and governance; the Work Plan details delivery.
- To compare actual status with the approved plan and manage changes explicitly.
- In the Issue Log.
- Adoption activities and benefits realisation.
- Entry into the Executing Phase.
Flashcards
Q: Which artefact defines the management approach?
A: Project Handbook.
Q: Which artefact details work packages, activities, schedule and budget?
A: Project Work Plan.
Q: What is a baseline?
A: An approved plan version used as a control reference.
Q: Where is a change request recorded?
A: In the Change Log.
Q: Which Gate concludes Planning?
A: RfE – Ready for Executing.
Exam-Style Question
Which statement correctly describes the Project Handbook?
A. It is the detailed plan of activities, resources and budget.
B. It defines the project’s management approach, governance and operating arrangements.
C. It records daily risks and issues.
D. It is produced only during Closing.
Correct answer: B. The Project Work Plan details delivery; logs record operational information; the Project Handbook establishes how the project is managed.
In the Next Article
In the next article, we will enter Executing: delivery, deliverables acceptance, transition, Business Implementation and the RfC Gate.
Essential Sources
- European Commission, PM² Project Management Methodology Guide v3.1.
- European Commission, PM² Project Management Methodology – Highlights, 2025 Edition.