# Project Charter: [Project name]

> Project charter: the short document that formally authorises a project,
> names the sponsor and the project manager, and sets the boundaries the
> project works within: purpose, measurable objectives, high-level scope
> and requirements, summary milestones and budget, key stakeholders, the
> project manager's authority levels, assumptions, constraints, top risks,
> and the criteria for closing or stopping the project. The content is
> aligned with the project charter concept in *A Guide to the Project
> Management Body of Knowledge (PMBOK Guide)*, Eighth Edition (PMI,
> November 2025) and with the pre-project and initiating practices of
> ISO 21502:2020 (Guidance on project management). It works for
> predictive, agile and hybrid projects. Replace every `[bracketed]` value
> and every row marked *Example*.

<!--
Guidance: How to use this template
- The charter answers three questions before work starts: why are we
  doing this, what are the boundaries, and who may decide what. Keep it
  to a few pages; the detail belongs in the project management plan
  (project/project-management-plan).
- The sponsor owns the charter and signs it; the project manager usually
  drafts it. Work from the approved business case
  (business/business-case) and do not repeat its financial analysis here,
  only the summary and a link.
- Write objectives and success criteria that someone outside the team
  could check at closure. "Improve efficiency" cannot be checked;
  "reduce order picking time from 14 to 9 minutes by YYYY-MM-DD" can.
- Fill section 8 (authority levels) carefully. Most charter disputes are
  about who may approve spend, scope or schedule changes, not about
  scope itself.
- Once approved, change the charter only through the change control
  process (project/change-control) and record each change in the
  revision history.
-->

## Document control

<!-- Guidance: Identify the charter and its approval state. Status moves Draft -> In review -> Approved -> Superseded (for example after a re-baseline) or Closed. -->

| Field | Value |
|---|---|
| Document ID | [PC-PROJECT-001] |
| Project name | [Project name] |
| Project code | [PRJ-NNNN] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded / Closed] |
| Sponsor | [Name, role] |
| Project manager | [Name, role] |
| Owner of this document | [Sponsor; drafted by the project manager] |
| Business case reference | [BC-NNN, version, approval date] |
| Portfolio or programme | [Portfolio or programme name, or "Standalone"] |
| Delivery approach | [Predictive / Agile / Hybrid] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Signature or approval reference | Date |
|---|---|---|---|---|
| Sponsor | [Name] | [Approved / Approved with conditions / Rejected] | [Reference] | YYYY-MM-DD |
| Portfolio board or investment committee | [Name] | [Decision] | [Minutes reference] | YYYY-MM-DD |
| Project manager (acceptance of role and authority) | [Name] | Accepted | [Reference] | YYYY-MM-DD |
| Finance business partner | [Name] | [Budget confirmed] | [Reference] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change | Approved by |
|---|---|---|---|---|
| 0.1 *(Example)* | YYYY-MM-DD | [Project manager] | First draft from approved business case | n/a |
| 1.0 *(Example)* | YYYY-MM-DD | [Project manager] | Approved at portfolio board | [Sponsor] |
| 1.1 *(Example)* | YYYY-MM-DD | [Project manager] | Milestone M4 moved by 3 weeks under CR-007 | [Sponsor] |

## Contents

1. [Purpose and justification](#1-purpose-and-justification)
2. [Objectives and success criteria](#2-objectives-and-success-criteria)
3. [High-level scope](#3-high-level-scope)
4. [High-level requirements](#4-high-level-requirements)
5. [Deliverables and summary milestones](#5-deliverables-and-summary-milestones)
6. [Summary budget and resources](#6-summary-budget-and-resources)
7. [Key stakeholders and governance](#7-key-stakeholders-and-governance)
8. [Project manager authority levels](#8-project-manager-authority-levels)
9. [Assumptions, constraints and dependencies](#9-assumptions-constraints-and-dependencies)
10. [High-level risks](#10-high-level-risks)
11. [Exit and approval criteria](#11-exit-and-approval-criteria)
12. [Reporting and change control](#12-reporting-and-change-control)
13. [Authorisation](#13-authorisation)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose and justification

<!-- Guidance: Two short paragraphs: the problem or opportunity, and why now. Summarise the business case; do not copy it. Pitfall: describing the solution instead of the problem. -->

**Problem or opportunity:** [What is wrong today, or what opportunity
exists, and who is affected.]

**Why now:** [The trigger: regulation, contract end, customer demand,
strategy decision.]

**Link to strategy:** [Strategic objective or portfolio theme this project
serves.]

*Example:* Harbourline Freight Ltd. (a fictional company) runs its three
warehouses on a warehouse management system whose vendor support ends on
YYYY-MM-DD. Order picking takes 14 minutes per order on average, against
9 minutes at competitors that use guided picking. The approved business
case BC-112 recommends replacing the system with a cloud warehouse
management service before support ends, with an expected payback of 3.2
years.

## 2. Objectives and success criteria

<!-- Guidance: Three to five objectives. Each needs a measure, a baseline, a target, a date and a person who will confirm it. Separate project objectives (delivered at closure) from benefits that appear later and are tracked in the benefits realisation plan. -->

| ID | Objective | Measure | Baseline | Target | By when | Confirmed by |
|---|---|---|---|---|---|---|
| OBJ-01 *(Example)* | Replace the warehouse system before support ends | All 3 sites live on the new system | 0 of 3 | 3 of 3 | YYYY-MM-DD | Operations director |
| OBJ-02 *(Example)* | Reduce order picking time | Average minutes per order (system report) | 14.0 | 9.5 | 3 months after last go-live | Head of logistics |
| OBJ-03 *(Example)* | Keep service during cutover | Orders shipped on time during each cutover week | 97% | at least 95% | Each go-live | Customer service lead |
| [OBJ-NN] | [Objective] | [Measure] | [Baseline] | [Target] | [Date] | [Role] |

Benefits that arise after closure (for example lower labour cost per
order) are tracked in the benefits realisation plan
(`project/benefits-realization-plan`), not as charter success criteria.

## 3. High-level scope

<!-- Guidance: State boundaries, not tasks. The "out of scope" list prevents more disputes than any other part of the charter. Detailed scope goes into the scope statement or backlog later. -->

| In scope | Out of scope |
|---|---|
| *Example:* Warehouse management for the three existing sites | *Example:* Transport management and route planning |
| *Example:* Integration with the existing ERP for orders and stock | *Example:* Replacement of the ERP |
| *Example:* Data migration of open orders, stock and locations | *Example:* Migration of closed orders older than 2 years (archived read-only) |
| *Example:* Training of warehouse staff and supervisors | *Example:* Changes to warehouse building layout |
| [In scope item] | [Out of scope item] |

## 4. High-level requirements

<!-- Guidance: The few requirements that define success and shape the solution choice. Write them as capabilities or conditions, each with a source. Detailed requirements are written later (requirements/business-requirements). Pitfall: listing features from one vendor's brochure. -->

| ID | Requirement | Type | Source | Priority |
|---|---|---|---|---|
| HLR-01 *(Example)* | Pickers receive guided picking instructions on handheld devices | Functional | Business case BC-112 | Must |
| HLR-02 *(Example)* | Stock levels synchronise with the ERP within 5 minutes | Interface | Finance and sales | Must |
| HLR-03 *(Example)* | The service is available 06:00 to 23:00 on working days with at least 99.5% availability | Non-functional | Operations | Must |
| HLR-04 *(Example)* | Personal data of staff is processed only in the regions approved by the data protection officer | Compliance | Data protection officer | Must |
| HLR-05 *(Example)* | Supervisors can produce the daily productivity report without IT help | Functional | Site managers | Should |
| [HLR-NN] | [Requirement] | [Type] | [Source] | [Must / Should / Could] |

## 5. Deliverables and summary milestones

<!-- Guidance: Name the major deliverables and five to eight milestones, each with an acceptance owner. Dates are targets at charter stage; the baseline schedule is set in planning (project/project-schedule). -->

| ID | Deliverable | Acceptance owner |
|---|---|---|
| DEL-01 *(Example)* | Selected and contracted warehouse management service | Procurement lead |
| DEL-02 *(Example)* | Configured and integrated solution, tested end to end | Operations director |
| DEL-03 *(Example)* | Migrated data, reconciled per site | Finance controller |
| DEL-04 *(Example)* | Trained staff and updated operating procedures | Head of logistics |
| DEL-05 *(Example)* | Live operation at three sites with hypercare completed | Operations director |

| ID | Milestone | Target date | Gate or decision |
|---|---|---|---|
| M1 *(Example)* | Charter approved, project initiated | YYYY-MM-DD | Portfolio board |
| M2 *(Example)* | Vendor selected and contract signed | YYYY-MM-DD | Sponsor |
| M3 *(Example)* | Solution design approved | YYYY-MM-DD | Steering committee |
| M4 *(Example)* | Pilot site live | YYYY-MM-DD | Go-live readiness review |
| M5 *(Example)* | All sites live | YYYY-MM-DD | Go-live readiness review |
| M6 *(Example)* | Project closed | YYYY-MM-DD | Sponsor (section 11) |

```mermaid
flowchart LR
  M1["M1 Charter approved"] --> M2["M2 Vendor contracted"]
  M2 --> M3["M3 Design approved"]
  M3 --> M4["M4 Pilot site live"]
  M4 --> M5["M5 All sites live"]
  M5 --> M6["M6 Project closed"]
```

## 6. Summary budget and resources

<!-- Guidance: Give the pre-approved financial resources: the budget the sponsor authorises at charter stage, the contingency held by the project, and any management reserve held above the project. Make sure the numbers add up and match the business case. -->

| Item | Estimate *(Example, EUR)* | Basis |
|---|---|---|
| Internal staff time | 420,000 | 6 FTE for 14 months, internal day rates |
| Software subscription (project period) | 180,000 | Vendor quotes, 3 sites |
| Implementation partner | 260,000 | Fixed price for configuration and integration |
| Handheld devices and network upgrades | 60,000 | 120 devices, 3 sites |
| Training and change management | 30,000 | Train-the-trainer model |
| **Subtotal** | **950,000** | |
| Contingency (10%, held by the project manager per section 8) | 95,000 | Known risks in section 10 |
| **Authorised project budget** | **1,045,000** | Approved by portfolio board |
| Management reserve (held by the sponsor, outside the project budget) | 50,000 | Unknown risks |

| Resource | Quantity | Source | Committed by |
|---|---|---|---|
| Project manager *(Example)* | 1 FTE | PMO | Head of PMO |
| Solution architect *(Example)* | 0.5 FTE | IT architecture | CIO |
| Site super-users *(Example)* | 2 per site, 20% time | Operations | Operations director |
| [Role] | [Quantity] | [Team] | [Name] |

## 7. Key stakeholders and governance

<!-- Guidance: List the stakeholders who can approve, block or must be consulted at charter stage. The full register comes later (project/stakeholder-register). Show the governance structure so everyone knows where decisions are made. -->

| Stakeholder | Role in the project | Main interest | Influence | Engagement approach |
|---|---|---|---|---|
| Operations director *(Example)* | Sponsor | Continuity of warehouse service | High | Chairs steering committee |
| Head of logistics *(Example)* | Senior user | Picking productivity | High | Steering member, accepts DEL-04 |
| CIO *(Example)* | Senior supplier (internal) | Integration, security | High | Steering member |
| Warehouse staff representatives *(Example)* | Users | Workload, training | Medium | Monthly briefing, pilot feedback |
| Data protection officer *(Example)* | Reviewer | Staff personal data | Medium | Consulted before M3 |
| [Stakeholder] | [Role] | [Interest] | [High / Medium / Low] | [Approach] |

```mermaid
flowchart TD
  PB["Portfolio board"] --> SC["Steering committee (chair: sponsor)"]
  SC --> PM["Project manager"]
  PM --> WS1["Workstream: solution and integration"]
  PM --> WS2["Workstream: data migration"]
  PM --> WS3["Workstream: people and training"]
```

| Body | Members | Decides | Meets |
|---|---|---|---|
| Portfolio board *(Example)* | Executive team | Charter approval, budget above the authorised total, stop or continue | Quarterly and at exceptions |
| Steering committee *(Example)* | Sponsor, head of logistics, CIO, finance | Milestone gates, changes beyond PM authority, top risks | Monthly |
| Project manager *(Example)* | Project manager | Day-to-day decisions within section 8 | Weekly team meeting |

## 8. Project manager authority levels

<!-- Guidance: Be explicit and use numbers. For each area, state what the project manager may decide alone, what needs the sponsor, and what goes to the steering committee or portfolio board. Pitfall: "the PM has full authority" with no limits, which no organisation actually means. -->

| Area | Project manager decides alone | Sponsor approval needed | Steering committee or board |
|---|---|---|---|
| Budget *(Example)* | Spend within approved line items; use of contingency up to EUR 20,000 per change | Contingency use above EUR 20,000 per change, up to the contingency total | Any increase of the authorised budget (portfolio board) |
| Schedule *(Example)* | Moves of internal tasks that do not change a milestone | Milestone moves up to 2 weeks | Milestone moves beyond 2 weeks, or any move of M5 |
| Scope *(Example)* | Clarifications within the in-scope list | Changes to Should or Could requirements | Changes to Must requirements or the out-of-scope list |
| Staffing *(Example)* | Assigning work within the committed team | Requesting extra internal staff | New external contracts above EUR 50,000 |
| Technical decisions *(Example)* | Within the approved solution design | Deviations from the design that affect another system | Deviations from architecture or security policy |
| Vendor management *(Example)* | Day-to-day direction of the implementation partner | Contract change notices within budget | Contract value changes |
| [Area] | [Limit] | [Limit] | [Limit] |

Escalation route: project manager, then sponsor, then steering committee,
then portfolio board. A decision outside these limits is escalated within
[2] working days.

## 9. Assumptions, constraints and dependencies

<!-- Guidance: Assumptions are treated as true until checked; give each one an owner and a date to confirm it. Constraints are fixed limits. Dependencies are things outside the project that it needs. -->

| ID | Type | Statement | Owner | Confirm by |
|---|---|---|---|---|
| AS-01 *(Example)* | Assumption | Sites can release two super-users each at 20% of their time | Operations director | M2 |
| AS-02 *(Example)* | Assumption | The ERP interface specification is current | CIO | M3 |
| CO-01 *(Example)* | Constraint | All sites live before vendor support of the old system ends on YYYY-MM-DD | Sponsor | Fixed |
| CO-02 *(Example)* | Constraint | No go-live in the peak season weeks [week numbers] | Head of logistics | Fixed |
| DP-01 *(Example)* | Dependency | Network upgrade at site 2 by the facilities project | Facilities manager | M3 |
| [ID] | [Type] | [Statement] | [Owner] | [Date or milestone] |

## 10. High-level risks

<!-- Guidance: The top five to eight risks known at charter stage, each with an owner. They move into the RAID log (project/raid-log) when planning starts. -->

| ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| R-01 *(Example)* | Data quality in the old system delays migration | High | High | Data profiling in month 1; cleansing workstream | Data migration lead |
| R-02 *(Example)* | Staff resistance to handheld guided picking | Medium | High | Early involvement of staff representatives; pilot site first | Head of logistics |
| R-03 *(Example)* | ERP integration effort underestimated | Medium | Medium | Integration proof of concept before M3 | Solution architect |
| R-04 *(Example)* | Old system fails before replacement | Low | High | Extended support quote kept as fallback | CIO |
| [R-NN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [Owner] |

## 11. Exit and approval criteria

<!-- Guidance: Define in advance how the project ends: what must be true for the sponsor to accept closure, who signs, and under which conditions the project should be stopped early. Pitfall: no stop criteria, so failing projects continue by default. -->

**Closure criteria (all must be met):**

| ID | Criterion | Evidence | Approver |
|---|---|---|---|
| EX-01 *(Example)* | OBJ-01 and OBJ-03 achieved | Go-live reports per site | Operations director |
| EX-02 *(Example)* | All Must requirements (HLR-01 to HLR-04) accepted | Signed acceptance test reports | Steering committee |
| EX-03 *(Example)* | Hypercare complete with no open severity 1 or 2 incidents | Service desk report | CIO |
| EX-04 *(Example)* | Handover to operations and support signed | Operations handover document | Head of logistics |
| EX-05 *(Example)* | Lessons learned recorded and contracts closed | Closure report (`project/project-closure-report`) | Sponsor |

**Early termination triggers (any one leads to a stop-or-continue decision
by the portfolio board):**

- *Example:* Forecast cost at completion exceeds the authorised budget by
  more than 15%.
- *Example:* M4 (pilot site live) forecast later than [date], which would
  put the support-end constraint CO-01 at risk.
- *Example:* The business case no longer shows a positive net value after
  re-assessment.

OBJ-02 (picking time) is measured 3 months after the last go-live; if the
project closes earlier, the sponsor confirms who measures it and reports
the result through the benefits realisation plan.

## 12. Reporting and change control

<!-- Guidance: Say how the sponsor will hear about progress and how changes to this charter are approved. -->

| Item | Approach |
|---|---|
| Status reporting | [*Example:* Monthly steering report (`project/steering-committee-report`), weekly highlight note to the sponsor] |
| Exception reporting | [*Example:* Immediate report to the sponsor when a forecast breaches a limit in section 8] |
| Change control | [*Example:* Changes follow `project/change-control`; approval level per section 8] |
| Communication | [*Example:* Communication plan (`project/communication-plan`) issued by M2] |
| Next documents | [Project management plan, stakeholder register, RAID log, schedule] |

## 13. Authorisation

<!-- Guidance: The sponsor's signature authorises the project to start and the project manager to use the resources in section 6 within the limits in section 8. -->

By approving this charter, the sponsor authorises the project
[Project name] to start, assigns [Project manager] as project manager,
and authorises the use of the resources in section 6 within the
authority levels in section 8.

| Role | Name | Signature | Date |
|---|---|---|---|
| Sponsor | [Name] | [Signature] | YYYY-MM-DD |
| Project manager | [Name] | [Signature] | YYYY-MM-DD |

## 14. Glossary and references

<!-- Guidance: Define terms that readers outside the project might read differently, and list the documents this charter relies on. -->

| Term | Meaning in this charter |
|---|---|
| Sponsor | The executive accountable for the project and its business case |
| Contingency | Budget held by the project for identified risks, used within section 8 limits |
| Management reserve | Budget held above the project by the sponsor for unidentified risks |
| Milestone | A significant point or event with zero duration, often linked to a gate decision |
| Hypercare | A period of extra support right after go-live |

| Reference | Title | Use |
|---|---|---|
| BC-NNN | Business case (`business/business-case`) | Justification and financial analysis |
| [Doc ID] | Project management plan (`project/project-management-plan`) | Detailed plans, prepared after approval |
| [Doc ID] | Stakeholder register (`project/stakeholder-register`) | Full stakeholder analysis |
| [Doc ID] | RAID log (`project/raid-log`) | Risks, assumptions, issues, dependencies |
| [Doc ID] | Responsibility matrix (`business/raci`) | Roles per deliverable |
| [Doc ID] | Kickoff meeting agenda (`meetings/kickoff`) | First meeting after approval |
| PMBOK Guide, 8th ed. | A Guide to the Project Management Body of Knowledge, PMI, November 2025 | Charter concept and initiating practice (cited only) |
| ISO 21502:2020 | Project, programme and portfolio management, guidance on project management | Clause 6.2 pre-project activities, 6.4 directing a project, 6.5 initiating a project (cited only) |

## Standard and licence note

Structure aligned with *A Guide to the Project Management Body of
Knowledge (PMBOK Guide)*, Eighth Edition (Project Management Institute,
published November 2025; an errata sheet for the second printing was
issued in April 2026), using the project charter concept of the PMBOK
Guide series (a document that formally authorises a project and gives the
project manager authority to use organisational resources; check how the
Eighth Edition places it in your licensed copy), and with ISO 21502:2020,
*Project, programme and portfolio management: Guidance on project
management* (first edition, published December 2020), clauses 6.2
(pre-project activities), 6.4 (directing a project) and 6.5 (initiating a
project). Both are copyrighted publications: this template cites their
names, editions and clause numbers only, is original text written for
this collection, and reproduces no text, tables or figures from them. The
clause numbers were checked against the public table of contents, not
the licensed text. Check the current editions before relying on them.

Official text: Project Management Institute, purchase or member access:
https://www.pmi.org/standards/pmbok. ISO, purchase or licensed access:
https://www.iso.org/standard/74947.html (also available from national
standards bodies).

Template licence: MIT.