# 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*.

<!--
Guidance: How to use this template
- Write the plan once the charter is approved and before execution starts. It is
  the single reference for "how we run this project"; detailed subsidiary plans
  (schedule, RAID log, communication plan) are linked, not duplicated.
- Tailor it: keep every section, but scale the depth to the size and risk of the
  project. A one-line answer is fine when the topic is simple.
- Baseline the plan (scope, schedule, cost) at approval. After that, change it
  only through the change control process in section 15.
- Keep numbers consistent across sections: the budget in section 6 must match the
  cost baseline in section 18, and milestone dates must match the gantt chart.
-->

## Document control

<!-- Guidance: Identify the plan and who owns it. Status moves Draft -> In review -> Approved -> Baselined. -->

| Field | Value |
|---|---|
| Document ID | [PMP-PROJECT-001] |
| Project | [Project name] ([project code]) |
| Sponsor | [@sponsor] |
| Project manager | [@project-manager] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Baselined] |
| Classification | [Internal / Confidential] |
| Related documents | [Project charter PC-001, Business case BC-001, RAID log RAID-001] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Project sponsor | [@name] | [Approved / Approved with conditions] | YYYY-MM-DD |
| Steering committee chair | [@name] | [Decision] | YYYY-MM-DD |
| Project manager | [@name] | [Submitted] | YYYY-MM-DD |
| Finance controller | [@name] | [Budget confirmed] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record every approved version. Changes after baselining must cite the change request ID. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft for review |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved and baselined by steering committee |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Schedule re-baselined after CR-007 (vendor delay) |

## Contents

<!-- Guidance: Keep in sync with the headings below. -->

1. [Project overview](#1-project-overview)
2. [Governance and organisation](#2-governance-and-organisation)
3. [Scope management](#3-scope-management)
4. [Schedule management](#4-schedule-management)
5. [Cost management](#5-cost-management)
6. [Performance measurement](#6-performance-measurement)
7. [Quality management](#7-quality-management)
8. [Resource management](#8-resource-management)
9. [Communications management](#9-communications-management)
10. [Risk management](#10-risk-management)
11. [Procurement management](#11-procurement-management)
12. [Stakeholder engagement](#12-stakeholder-engagement)
13. [Issue management](#13-issue-management)
14. [Configuration and information management](#14-configuration-and-information-management)
15. [Change control](#15-change-control)
16. [Transition and closure](#16-transition-and-closure)
17. [Subsidiary plans and references](#17-subsidiary-plans-and-references)
18. [Baselines and approvals](#18-baselines-and-approvals)
19. [Glossary](#19-glossary)

## 1. Project overview

<!-- Guidance: Summarise why the project exists and what success looks like. Reuse the charter, do not rewrite it. Common mistake: objectives that are activities ("implement CRM") rather than outcomes. -->

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).

| ID | Objective | Measure | Target | Deadline |
|---|---|---|---|---|
| OBJ-01 | *Example:* Reduce onboarding cycle time | Median days from application to account active | From 11 to 3 days | YYYY-MM-DD |
| OBJ-02 | *Example:* Reduce application abandonment | Abandoned / started applications | From 18% to below 8% | YYYY-MM-DD |
| OBJ-03 | [Objective] | [Measure] | [Target] | YYYY-MM-DD |

### 1.3 Success criteria and constraints

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

| Dimension | Baseline | Tolerance before escalation to sponsor |
|---|---|---|
| Schedule | Go-live YYYY-MM-DD | +/- 10 working days |
| Cost | [Budget at completion, e.g. 480,000 EUR] | +/- 5% |
| Scope | Deliverables D1 to D6 | No reduction in Must-have scope |
| Quality | Acceptance criteria in section 7 | Zero open severity 1 defects at go-live |

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

## 2. Governance and organisation

<!-- Guidance: Show who decides what. Name people, not just roles. Common mistake: a steering committee without decision rights or a meeting cadence. -->

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.

```mermaid
flowchart TB
  SC["Steering committee"] --> SP["Project sponsor"]
  SP --> PM["Project manager"]
  PM --> PMO["Project office / PMO support"]
  PM --> WL1["Workstream lead: Process"]
  PM --> WL2["Workstream lead: Technology"]
  PM --> WL3["Workstream lead: Change and training"]
  SC -.-> QA["Independent assurance"]
```

### 2.1 Roles and decision rights

| Role | Name | Responsibilities | Decision authority |
|---|---|---|---|
| Sponsor | [@name] | Owns the business case, secures funding, chairs escalations | Approves changes beyond PM tolerance |
| Steering committee | [names] | Direction, stage approvals, risk acceptance | Go/no-go at each stage gate |
| Project manager | [@name] | Day-to-day planning, delivery, reporting | Changes within tolerance |
| Workstream lead | [@name] | Delivers workstream scope and reports progress | Task-level priorities |
| Independent assurance | [@name] | Reviews health and compliance | Advisory only |

### 2.2 Lifecycle and stage gates

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

| Stage | Exit gate | Gate criteria |
|---|---|---|
| Initiation | G1 Plan approved | This plan baselined; funding released |
| Design | G2 Design approved | Solution design signed off; vendor contracted |
| Build and test | G3 Ready for deployment | UAT passed; operational readiness confirmed |
| Deploy and transition | G4 Handover | Service accepted by operations; hypercare complete |

## 3. Scope management

<!-- Guidance: Define what is in and out, how the scope is decomposed and how deliverables are accepted. Common mistake: no explicit exclusions, which invites scope creep. -->

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

### 3.1 Scope statement

| In scope | Out of scope |
|---|---|
| *Example:* Online application form for retail customers | Business and corporate customers |
| *Example:* Integration with core banking and identity verification service | Replacement of core banking system |
| [Item] | [Item] |

### 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.

| Deliverable | WBS ID | Acceptance criteria | Acceptor |
|---|---|---|---|
| D1 Process design | 1.2 | Approved by operations head; covers all 7 onboarding scenarios | [@name] |
| D2 Digital onboarding platform | 1.3 | UAT pass rate at least 95%, no open severity 1 or 2 defects | [@name] |
| [Deliverable] | [x.y] | [Criteria] | [@name] |

### 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

<!-- Guidance: State how the schedule is built, baselined and controlled, then show the milestones. Detailed activities live in the project schedule document. -->

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

| ID | Milestone | Baseline date | Owner | Gate |
|---|---|---|---|---|
| M1 | Plan baselined | YYYY-MM-DD | [@pm] | G1 |
| M2 | Solution design approved | YYYY-MM-DD | [@lead] | G2 |
| M3 | UAT complete | YYYY-MM-DD | [@lead] | G3 |
| M4 | Go-live | YYYY-MM-DD | [@pm] | G4 |

### 4.2 Summary schedule

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

```mermaid
gantt
  title Summary schedule
  dateFormat YYYY-MM-DD
  section Initiation
  Planning and baseline     :a1, 2027-01-04, 20d
  section Design
  Process and solution design :a2, after a1, 30d
  Vendor selection          :a3, after a1, 25d
  section Build and test
  Build and integrate       :a4, after a2, 50d
  UAT                       :a5, after a4, 15d
  section Deploy
  Go-live                   :milestone, m4, after a5, 0d
  Hypercare                 :a6, after a5, 20d
```

### 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

<!-- Guidance: Show the budget by category, how contingency is held and released, and the cost reporting rhythm. Common mistake: mixing contingency into line items so it disappears. -->

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

| Category | Estimate | Basis of estimate |
|---|---|---|
| Internal labour | *Example:* 210,000 EUR | 1,750 person-days at blended rate 120 EUR |
| External services | *Example:* 140,000 EUR | Fixed-price vendor quote Q-2027-14 |
| Licences and infrastructure | *Example:* 60,000 EUR | Three-year subscription, year one |
| Training and change | *Example:* 25,000 EUR | 12 sessions, materials |
| **Cost baseline** | **435,000 EUR** | |
| Contingency reserve (10%) | 43,500 EUR | Held by PM for identified risks |
| Management reserve | [Amount] | Held by sponsor for unknowns |
| **Budget at completion (BAC)** | **478,500 EUR** | |

### 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

<!-- Guidance: Define how progress is measured objectively. Earned value is optional for small projects; if used, define how EV is credited (for example 0/100 or 50/50 per work package). -->

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.

| Indicator | Green | Amber | Red |
|---|---|---|---|
| SPI | at least 0.95 | 0.90 to 0.94 | below 0.90 |
| CPI | at least 0.95 | 0.90 to 0.94 | below 0.90 |
| Milestone slip | 0 to 5 days | 6 to 10 days | over 10 days |

*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

<!-- Guidance: Summarise the quality approach and link the full quality management plan. State acceptance criteria and who checks them. -->

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].

| Deliverable | Quality standard | Control activity | Responsible |
|---|---|---|---|
| Process design | Internal process design standard | Peer review and operations walkthrough | [@name] |
| Platform | Test plan TP-001, accessibility WCAG 2.2 AA | System test, UAT, accessibility audit | [@name] |
| Training materials | Brand and plain-language guide | Review by two pilot users | [@name] |

## 8. Resource management

<!-- Guidance: Describe how people and equipment are acquired, allocated and released. Detailed loading is in the resource plan. -->

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

| Role | FTE | Source | Period |
|---|---|---|---|
| *Example:* Business analyst | 1.0 | Operations department | Design to UAT |
| *Example:* Developer | 3.0 | Vendor | Build and test |
| [Role] | [x.x] | [Source] | [Period] |

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

## 9. Communications management

<!-- Guidance: Summarise the key reports and meetings; link the communication plan for the full matrix. -->

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

| Communication | Audience | Frequency | Owner |
|---|---|---|---|
| Status report | Sponsor, steering committee | Biweekly | Project manager |
| Steering committee meeting | Steering committee | Monthly and at gates | Sponsor |
| Team stand-up | Project team | Daily | Workstream leads |
| Stakeholder newsletter | Affected staff | Monthly | Change lead |

## 10. Risk management

<!-- Guidance: Describe the process: identify, assess, respond, monitor. Define the scoring scale once and use it everywhere. -->

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)$$

| Score | Rating | Response expectation |
|---|---|---|
| 15 to 25 | High | Response plan within 5 days; reported to steering committee |
| 8 to 14 | Medium | Response plan within 10 days; tracked in status report |
| 1 to 7 | Low | Monitored by owner |

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

## 11. Procurement management

<!-- Guidance: State what is bought, how suppliers are chosen and who manages contracts. Link the procurement plan. -->

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

<!-- Guidance: Identify the stakeholders whose support matters most and how engagement is tracked. Link the stakeholder register. -->

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.

| Stakeholder | Current engagement | Desired engagement | Action |
|---|---|---|---|
| *Example:* Branch network managers | Resistant | Supportive | Co-design workshops, pilot in two branches |
| [Stakeholder] | [Level] | [Level] | [Action] |

## 13. Issue management

<!-- Guidance: Distinguish issues (happening now) from risks (may happen). Define resolution times. -->

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

<!-- Guidance: Say where documents and deliverables live, how they are versioned and who controls baselines. -->

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].

| Item | Location | Owner | Baseline control |
|---|---|---|---|
| Project management plan | [Link] | Project manager | Yes |
| Requirements specification | [Link] | Business analyst | Yes |
| Meeting minutes | [Link] | PMO | No |

## 15. Change control

<!-- Guidance: Every change to a baseline goes through one process. State thresholds clearly. Link the change control template. -->

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.

| Impact | Decision by |
|---|---|
| Within PM tolerance (cost under 5,000 EUR, schedule under 5 days, no scope reduction) | Project manager |
| Within sponsor tolerance (cost under 25,000 EUR, schedule under 10 days) | Sponsor |
| Above sponsor tolerance or affecting benefits | Change control board / steering committee |

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

## 16. Transition and closure

<!-- Guidance: Plan the handover to operations from the start, not at the end. Name the receiving owner. -->

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

<!-- Guidance: List the plans and documents this plan relies on, with links and versions. -->

The following documents complete this plan.

| Document | ID | Version | Link |
|---|---|---|---|
| Project charter | PC-001 | 1.0 | [Link] |
| Work breakdown structure | WBS-001 | [x.y] | [Link] |
| Project schedule | SCH-001 | [x.y] | [Link] |
| RAID log | RAID-001 | Living | [Link] |
| Communication plan | CP-001 | [x.y] | [Link] |
| Quality management plan | QMP-001 | [x.y] | [Link] |

## 18. Baselines and approvals

<!-- Guidance: Record the three baselines at approval. These are what performance is measured against. -->

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

| Baseline | Content | Reference |
|---|---|---|
| Scope baseline | Scope statement, WBS, WBS dictionary | Section 3, WBS-001 v1.0 |
| Schedule baseline | Milestones M1 to M4, go-live YYYY-MM-DD | Section 4, SCH-001 v1.0 |
| Cost baseline | 435,000 EUR plus 43,500 EUR contingency | Section 5 |

## 19. Glossary

<!-- Guidance: Define project-specific terms and abbreviations. -->

| Term | Meaning |
|---|---|
| BAC | Budget at completion: total approved budget for the work |
| CCB | Change control board |
| EVM | Earned value management |
| RAID | Risks, assumptions, issues and dependencies |
| WBS | Work breakdown structure |

## 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.