Project Work Plan in PM²: turning the mandate into governable work

Twenty-seventh article in the “Learning PM² Through a Project” series

A list of activities is not yet a plan. Managing a project requires a result to deliver, the work needed to produce it, a credible sequence, estimates, responsibilities and an up-to-date view of what can block the path.

The PM² Project Work Plan organises this set. It connects scope, deliverables, activities, resources, effort, schedule, dependencies and milestones: it is the basis for coordinating execution and controlling schedule and cost.

From Charter to actual work

The Work Plan does not replace Requirements Management or Change Management. It uses approved requirements and scope to organise work; when they change, the plan is updated in a controlled way.

Essential components

The level of detail is proportionate. A thirty-minute activity need not appear in the project plan; a dependency that can delay go-live should.

Deliverables first, activities second

Starting from activities often produces a plan such as “analyse, develop, test”. It is difficult to verify completeness and value. Starting from deliverables instead forces the question of what will actually be delivered and accepted.

flowchart TD
  A[Approved scope and requirements] --> B[Deliverables]
  B --> C[WBS]
  C --> D[Activities]
  D --> E[Estimates, resources and dependencies]
  E --> F[Schedule and milestones]
  F --> G[Baseline and control]

A WBS is not merely a hierarchical list: it helps avoid forgetting necessary but less visible work such as documentation, security, testing, training, acceptance, transition and initial support.

Estimates: effort, duration, cost and uncertainty

A useful estimate states assumptions and degree of uncertainty. “Three days” without saying whether it includes testing, review, environment availability and user feedback is an ambiguous promise, not an estimate.

For uncertain activities, a simple technique is three-point estimation:

It need not be applied everywhere; it helps with high-uncertainty or high-impact activities.

Dependencies and critical path

Dependencies determine when an activity can start or finish relative to another. The most frequent are finish-to-start: one activity starts after another has finished. But dependencies can also come from decisions, suppliers, environments, users and regulations.

The critical path is the activity sequence that determines the earliest possible project finish date: a delay on one of these activities delays the final result if no buffer exists. Not every urgent activity is critical; the Work Plan helps distinguish them.

Milestones: control events, not long activities

A milestone is a significant point with no duration of its own: a decision, a gate, an accepted deliverable or a release moment.

Writing “testing” as a milestone is imprecise: testing is an activity; “testing completed and accepted” can be a milestone.

Build a baseline, then manage the forecast

Once approved, the Work Plan becomes the reference for monitoring and control. During execution, the PM updates the forecast using actual progress, remaining work, issues, risks and decisions.

Replacing the baseline each week with the updated plan removes the ability to understand how and why the project changed.

The Annotatio case: simplified Work Plan

For Smart Bookings, part of the plan could be:

This plan exposes work that a purely technical roadmap might ignore: training, support, user availability and benefit measurement.

Rolling-wave planning

Not every part of a project can be planned to the same detail level from the beginning. Rolling-wave planning details near-term work and retains more distant work at a higher level, refining it when better data emerges.

It is not permission to avoid future planning: milestones, dependencies, risks and long-term direction must remain visible. The detail level changes, not the discipline of control.

Do not confuse these

Three questions to anchor it

1. Which accepted deliverable demonstrates completion of this part of scope?
2. Which dependency can genuinely move the final date?
3. Which assumption makes the estimate more uncertain and should be explicit?

Flashcards

Q: What is the Project Work Plan for?
A: To organise deliverables, activities, estimates, resources, dependencies, schedule and milestones so the project can be coordinated and controlled.

Q: Why start from deliverables?
A: To verify completeness and value, then identify the work needed to produce and accept them.

Q: What is the difference between baseline and forecast?
A: The baseline is the approved plan; the forecast is the best current completion prediction.

Exam-style question

The PM lists development, testing and release in the plan, but does not include user availability for acceptance, training or support configuration. Days before go-live, they discover that nobody can accept the deliverable or operate the service.

What is the main cause?

Answer: the Work Plan was built as a technical activity list, not as a complete plan oriented to deliverables and transition. Organisational dependencies, acceptance and operational readiness should have been part of the WBS and schedule.

Source

The Project Work Plan, WBS, estimates, scheduling, milestones and planning techniques are covered in the European Commission’s PM² Methodology Guide 3.1.

Next: PM² Logs, for using the Risk, Issue, Change and Decision Logs as living project-governance tools.