Project Management Plan: [Project name]

Integrated project management plan that brings together how the project will be governed, planned, executed, monitored, controlled and closed. The structure is aligned with common project management practice and uses ISO 21502:2020 only as a structural reference. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Project overview
2. Governance and organisation
3. Scope management
4. Schedule management
5. Cost management
6. Performance measurement
7. Quality management
8. Resource management
9. Communications management
10. Risk management
11. Procurement management
12. Stakeholder engagement
13. Issue management
14. Configuration and information management
15. Change control
16. Transition and closure
17. Subsidiary plans and references
18. Baselines and approvals
19. Glossary

1. Project overview

This section summarises the purpose, objectives and boundaries of [Project name] so that every reader shares the same understanding before reading the management approaches that follow.

1.1 Background and purpose

[Two or three sentences on the business problem or opportunity, the strategic objective it supports and the reference to the approved business case.]

Example: Customer onboarding currently takes 11 working days and 18% of applications are abandoned. The project replaces the paper-based onboarding process with a digital workflow, supporting the 2027 strategic objective "digital first service".

1.2 Objectives

Objectives are written to be specific, measurable, achievable, relevant and time-bound (SMART).

1.3 Success criteria and constraints

The project is successful when the objectives above are met within the approved tolerances below.

Key constraints: [regulatory deadline, fixed budget, technology mandate]. Key assumptions are recorded in the RAID log.

2. Governance and organisation

The project is governed through a steering committee that holds decision authority above the project manager's tolerances. The organisation chart below shows reporting lines.

2.1 Roles and decision rights

2.2 Lifecycle and stage gates

The project follows a [predictive / iterative / hybrid] lifecycle with the following stages and gates.

3. Scope management

Scope is defined by the scope statement below, decomposed in the work breakdown structure and accepted deliverable by deliverable.

3.1 Scope statement

3.2 Work breakdown structure

The WBS and WBS dictionary are maintained in [WBS-001 link]. Every deliverable below maps to a level 2 WBS element and to a named acceptor.

3.3 Scope validation

Each deliverable is presented to its acceptor with evidence against the acceptance criteria. Acceptance is recorded with a signed acceptance note in the project repository; rejected deliverables return to the owning workstream with a list of gaps.

4. Schedule management

The schedule is developed bottom-up from WBS work packages, baselined at gate G1 and updated [weekly]. Variance against milestones is reported in every status report.

4.1 Milestones

4.2 Summary schedule

The gantt chart below shows the summary schedule; replace the dates with your baseline.

4.3 Schedule control

Schedule variance beyond [5 working days] on a critical path milestone is escalated to the sponsor. Re-baselining requires an approved change request.

5. Cost management

Costs are estimated per work package and rolled up to the budget below. Actual costs come from [finance system] and are reconciled monthly.

5.1 Budget

5.2 Contingency rules

Contingency is released by the project manager against named risks in the RAID log and recorded in the cost log. Management reserve is released only by the sponsor through change control.

6. Performance measurement

Performance is measured with earned value management (EVM) at work-package level, using the [50/50] crediting rule. The core indicators are:

$CV = EV - AC \qquad SV = EV - PV$

$SPI = \frac{EV}{PV} \qquad CPI = \frac{EV}{AC} \qquad EAC = \frac{BAC}{CPI}$

where $PV$ is planned value, $EV$ earned value, $AC$ actual cost and $BAC$ budget at completion.

Example: with $EV$ = 200,000, $AC$ = 220,000 and $BAC$ = 478,500, $CPI \approx 0.91$ and $EAC \approx 526,000$, which is amber and triggers a cost recovery review.

7. Quality management

Quality is planned into each deliverable through acceptance criteria, assured through stage-gate reviews and controlled through testing and inspections. The full approach is in [QMP-001].

8. Resource management

The team is staffed from [departments] and one external vendor. Resource requirements, RACI and release dates are maintained in [RP-001].

Conflicts over shared resources are resolved by the line managers concerned; unresolved conflicts go to the sponsor within [5] working days.

9. Communications management

Communication is planned per audience in [CP-001]. The core rhythm is:

10. Risk management

Risks are recorded in the RAID log, scored on a 1 to 5 scale for probability and impact, and reviewed [weekly] by the project team and monthly by the steering committee.

$\text{Risk score} = \text{Probability} \times \text{Impact} \quad (1 \text{ to } 25)$

Top risks at baseline: Example: RSK-003 vendor capacity (score 16), RSK-007 identity service API changes (score 12).

11. Procurement management

Procurement follows [organisation procurement policy] and is detailed in [PP-001]. Planned procurements: [implementation vendor (fixed price), identity verification service (subscription)]. Contracts are managed by [@contract-manager], who reviews supplier performance monthly against agreed service levels.

12. Stakeholder engagement

Stakeholders are analysed by power and interest in [SR-001]. Engagement levels are reviewed monthly; any stakeholder whose current engagement is two levels below the desired level gets a named engagement action.

13. Issue management

Issues are logged in the RAID log with a priority and owner. Target resolution: priority 1 within [2] working days, priority 2 within [5], priority 3 within [15]. Issues that cannot be resolved within tolerance are escalated following the path in the communication plan.

14. Configuration and information management

Project documents are stored in [repository or tool] with version numbers in the form major.minor. Baselined items (this plan, requirements, designs, test plans) are listed in a configuration register; changes to them require a change request. Records are retained for [7] years in line with [records policy].

15. Change control

Any change to scope, schedule, cost or quality baselines is raised as a change request (CR) using [CC-001], assessed for impact within [5] working days and decided according to the thresholds below.

Approved changes update the affected baselines and the revision history of this plan.

16. Transition and closure

The solution transitions to [operations team] after go-live, following a [20]-day hypercare period. Transition criteria: support runbooks accepted, service desk trained, open defects transferred with owners, and service levels met for [10] consecutive working days. Closure activities (lessons learned, contract closure, resource release, archive) are recorded in the project closure report.

17. Subsidiary plans and references

The following documents complete this plan.

18. Baselines and approvals

The following baselines were approved on YYYY-MM-DD at gate G1.

19. Glossary

Standard and licence note

Structure aligned with ISO 21502:2020, Project, programme and portfolio management: Guidance on project management, used only as a structural reference for the integrated management practices. Content is based on common project management practice. This template is original text written for this collection and reproduces no text from the standard; obtain the standard for its guidance. Template licence: MIT.