Project Charter

Sun, 23 Aug 2026 00:00:00 +0000

A charter is the document that turns an idea into a funded project. Its real job is not description — it is authorisation and boundary setting. It names the sponsor who can say yes, the manager who can spend, and the things this project is explicitly not going to do.

When to use it

At project initiation, before any team member is assigned.
When a piece of work that started informally has grown enough that people are arguing about its scope.
When the sponsor changes and the mandate needs re-confirming.

What it must answer

Question	Why it belongs in the charter
Why now?	Separates a real trigger (contract expiry, audit finding, capacity ceiling) from a preference.
Who is accountable?	One sponsor, one manager. Two of either means neither.
What is out of scope?	The only section that reliably prevents a fight in month four.
What does success look like?	Measurable, with a baseline. “Improve performance” is not a success criterion.
What is the budget and deadline?	An order of magnitude is fine; a blank is not.

Template

 # Project Charter: <Project Name>

| Field | Value |
|---|---|
| Charter version | 1.0 |
| Date | YYYY-MM-DD |
| Sponsor | Name, role |
| Project manager | Name, role |
| Status | Draft / Approved |

## 1. Business case
Two or three sentences. What changes in the business if this succeeds, and what
happens if we do nothing.

## 2. Objectives and success criteria
| # | Objective | Measure | Baseline | Target | Measured by |
|---|---|---|---|---|---|
| 1 | | | | | |

## 3. Scope
**In scope**
- ...

**Out of scope**
- ...

**Assumptions**
- ...

## 4. Deliverables and milestones
| Milestone | Deliverable | Target date |
|---|---|---|

## 5. Budget
| Category | Amount | Notes |
|---|---|---|
| People | | |
| Licences / cloud | | |
| Contingency | | |

## 6. Key risks
Top three only; the full list lives in the RAID log.

## 7. Stakeholders and governance
| Name | Role | Decision rights | Cadence |
|---|---|---|---|

## 8. Approval
| Name | Role | Date | Signature |
|---|---|---|---|

Worked example

 # Project Charter: Payment Gateway Migration

| Field | Value |
|---|---|
| Charter version | 1.0 |
| Date | 2026-03-02 |
| Sponsor | R. Okafor, VP Engineering |
| Project manager | S. Lindqvist |
| Status | Approved |

## 1. Business case
Our contract with the incumbent payment provider ends 2027-01-31 and renewal
pricing is 40% higher. Migrating to the new provider saves roughly EUR 380k
per year and removes the single-region dependency that caused the outage in
January. Doing nothing means auto-renewal at the higher rate.

## 2. Objectives and success criteria
| # | Objective | Measure | Baseline | Target | Measured by |
|---|---|---|---|---|---|
| 1 | Migrate all card traffic | % of volume on new provider | 0% | 100% | 2026-12-15 |
| 2 | Hold authorisation rate | Weekly auth success rate | 96.4% | >= 96.4% | 2027-01-15 |
| 3 | Reduce annual cost | Provider fees per year | EUR 950k | <= EUR 570k | FY2027 close |

## 3. Scope
**In scope**
- Card payments (credit, debit) on web and mobile.
- Refunds, chargeback handling, reconciliation feeds to Finance.
- Dual-running both providers during cutover.

**Out of scope**
- Bank transfers and direct debit — remain with the incumbent until 2028.
- Repricing of merchant fees to customers.
- Replacing the internal ledger service.

**Assumptions**
- The new provider's sandbox is available from 2026-04-01.
- Finance can accept two reconciliation feeds during dual-running.

## 4. Deliverables and milestones
| Milestone | Deliverable | Target date |
|---|---|---|
| M1 | Integration spec signed off | 2026-05-15 |
| M2 | Sandbox integration passing test suite | 2026-07-31 |
| M3 | 5% live traffic on new provider | 2026-09-30 |
| M4 | 100% traffic migrated | 2026-12-15 |
| M5 | Incumbent card contract terminated | 2027-01-31 |

## 5. Budget
| Category | Amount | Notes |
|---|---|---|
| People | EUR 640k | 4 engineers, 1 QA, 0.5 PM for 9 months |
| Licences / cloud | EUR 45k | Sandbox, additional egress during dual-run |
| Contingency | EUR 100k | 15% |

## 6. Key risks
1. Authorisation rate drops after cutover and revenue falls before we can react.
2. The provider's PSD2 flow differs enough to require checkout redesign.
3. Finance reconciliation cannot handle dual feeds, delaying month-end close.

## 7. Stakeholders and governance
| Name | Role | Decision rights | Cadence |
|---|---|---|---|
| R. Okafor | Sponsor | Budget, go/no-go on cutover | Monthly steering |
| M. Duarte | Head of Finance | Accepts reconciliation design | Monthly steering |
| S. Lindqvist | PM | Day-to-day scope within charter | Weekly |
| A. Berg | Security lead | Accepts PCI scope changes | Gate reviews |

## 8. Approval
| Name | Role | Date | Signature |
|---|---|---|---|
| R. Okafor | Sponsor | 2026-03-02 | signed |
| M. Duarte | Head of Finance | 2026-03-04 | signed |

Common mistakes

No out-of-scope section. This is the single most common defect. Without it, every adjacent idea is arguably in scope.
Objectives without a baseline. “Reduce latency by 30%” is meaningless if nobody wrote down today’s number before the work started.
Two sponsors. Shared accountability produces deadlock at exactly the moment a decision is needed.

Charter as a design document. Architecture belongs in the When to use it

Immediately after the Project Charter is approved.
Before committing to an external date (a contract, a regulatory deadline, a marketing launch).
Whenever a dependency changes enough that the finish date moves.

What it must answer

What are the work packages, and who owns each one?
What must finish before what — and which of those chains determines the end date?
Where does the plan depend on people or systems outside the team’s control?
How much buffer exists, and where is it held?

Template

 # Project Plan: <Project Name>

| Field | Value |
|---|---|
| Plan version | |
| Baseline date | |
| Owner | |
| Related charter | link |

## 1. Approach
One paragraph: delivery method (iterative / phased), why it suits this work,
and how progress will be measured.

## 2. Work breakdown
| ID | Work package | Owner | Effort (days) | Depends on | Start | Finish |
|---|---|---|---|---|---|---|
| 1.1 | | | | — | | |

## 3. Milestones
| Milestone | Definition of done | Date | Owner |
|---|---|---|---|

## 4. Critical path
List the chain of work packages that determines the end date, and the total
float on the next-nearest chain.

## 5. Resourcing
| Role | Person | Allocation | Period | Confirmed? |
|---|---|---|---|---|

## 6. External dependencies
| Dependency | Provider | Needed by | Status | Escalation route |
|---|---|---|---|---|

## 7. Assumptions and buffer
- Assumptions this plan rests on.
- Where contingency is held and who may release it.

## 8. Change control
How a date change gets approved, and by whom.

Worked example

 # Project Plan: Payment Gateway Migration

| Field | Value |
|---|---|
| Plan version | 2.1 (rebaselined after M2 slip) |
| Baseline date | 2026-08-04 |
| Owner | S. Lindqvist |

## 1. Approach
Incremental migration behind a routing flag, with traffic moved in steps
(5% / 25% / 100%). Progress is measured by percentage of live card volume on
the new provider, not by code completeness, because the integration is only
proven under real traffic.

## 2. Work breakdown
| ID | Work package | Owner | Effort (days) | Depends on | Start | Finish |
|---|---|---|---|---|---|---|
| 1.1 | Integration spec | A. Vogel | 15 | — | 2026-04-06 | 2026-05-15 |
| 1.2 | Sandbox client library | J. Marek | 25 | 1.1 | 2026-05-18 | 2026-06-26 |
| 1.3 | Routing flag service | J. Marek | 10 | — | 2026-05-18 | 2026-06-01 |
| 1.4 | Reconciliation feed | P. Nowak | 20 | 1.1 | 2026-06-01 | 2026-07-10 |
| 1.5 | Test suite against sandbox | H. Ito | 20 | 1.2 | 2026-06-29 | 2026-07-31 |
| 1.6 | 5% traffic ramp | J. Marek | 10 | 1.3, 1.5 | 2026-09-01 | 2026-09-30 |
| 1.7 | Full ramp | J. Marek | 30 | 1.6 | 2026-10-05 | 2026-12-15 |

## 3. Milestones
| Milestone | Definition of done | Date | Owner |
|---|---|---|---|
| M2 | Full sandbox suite green for 5 consecutive nightly runs | 2026-07-31 | H. Ito |
| M3 | 5% of card volume settled and reconciled through new provider | 2026-09-30 | S. Lindqvist |
| M4 | 100% volume, incumbent in standby only | 2026-12-15 | S. Lindqvist |

## 4. Critical path
1.1 -> 1.2 -> 1.5 -> 1.6 -> 1.7. Total float on the reconciliation chain
(1.1 -> 1.4) is 15 working days, so a two-week slip there does not move M4;
a two-week slip in 1.5 does.

## 5. Resourcing
| Role | Person | Allocation | Period | Confirmed? |
|---|---|---|---|---|
| Backend | J. Marek | 100% | Apr–Dec | Yes |
| Backend | A. Vogel | 50% | Apr–Jul | Yes |
| Data | P. Nowak | 50% | Jun–Jul | No — shared with Reporting |
| QA | H. Ito | 100% | Jun–Dec | Yes |

## 6. External dependencies
| Dependency | Provider | Needed by | Status | Escalation route |
|---|---|---|---|---|
| Sandbox credentials | Payment provider | 2026-04-01 | Received 2026-04-03 | Account manager |
| PCI scope sign-off | Internal security | 2026-08-15 | In review | A. Berg -> CISO |
| Finance dual-feed capacity | Finance systems | 2026-08-31 | Not started | M. Duarte |

## 7. Assumptions and buffer
- P. Nowak's 50% allocation holds; if Reporting reclaims it, 1.4 slips 3 weeks
 and consumes all its float.
- 15 working days of contingency sit before M4, released only by the sponsor.

## 8. Change control
Any change to M4 requires sponsor approval at monthly steering. Changes inside
the plan that do not move a milestone are the PM's to make.

Common mistakes

A schedule with no critical path. If everything looks equally urgent, the team optimises the wrong task.

Unconfirmed resources shown as confirmed. Mark them honestly; an unconfirmed 50% allocation is a risk, and belongs in the When to use it

On a fixed weekly or fortnightly cadence for any project with a sponsor.
Ad hoc when a milestone date changes — do not wait for the next scheduled report.

What it must answer

Is the end date still credible, and has that answer changed since last time?
What did we finish, and what did we say we would finish and did not?
What decision or unblocking do I need from the reader, by when?

Template

 # Status Report: <Project> — week ending YYYY-MM-DD

**Overall:** Green / Amber / Red (last period: X)
**Next milestone:** <name>, due YYYY-MM-DD, confidence High / Medium / Low

## Decisions needed
| # | Decision | Owner | Needed by | Impact if late |
|---|---|---|---|---|

## Progress this period
- Completed: ...
- Slipped: ... (planned <date>, now <date>, cause)

## Plan for next period
- ...

## Risks and issues (changes only)
| ID | Item | Change since last report |
|---|---|---|

## Metrics
| Metric | Last | Now | Target |
|---|---|---|---|

## Budget
Spent to date / forecast at completion / approved.

Worked example

 # Status Report: Payment Gateway Migration — week ending 2026-08-21

**Overall:** Amber (last period: Green)
**Next milestone:** M3 — 5% live traffic, due 2026-09-30, confidence Medium

## Decisions needed
| # | Decision | Owner | Needed by | Impact if late |
|---|---|---|---|---|
| 1 | Confirm P. Nowak stays at 50% through September | M. Duarte | 2026-08-28 | Reconciliation feed slips 3 weeks and consumes all float |
| 2 | Accept 3DS challenge rate rising to 8% during ramp | R. Okafor | 2026-09-04 | Ramp cannot start; M3 slips |

## Progress this period
- Completed: sandbox test suite green on 5 consecutive nightly runs — M2 met,
 one week late.
- Completed: routing flag service deployed to production, disabled.
- Slipped: reconciliation feed UAT (planned 2026-08-19, now 2026-09-02).
 Cause: Finance systems team unavailable during month-end close. Known
 dependency, not a new one.

## Plan for next period
- Dry-run the ramp procedure against 0% traffic in production.
- Reconciliation feed UAT with Finance, 2026-09-01.
- Close out the PCI scope review with Security.

## Risks and issues (changes only)
| ID | Item | Change since last report |
|---|---|---|
| R-04 | Auth rate drop after cutover | Unchanged. Mitigation (automatic rollback below 95.5%) implemented this week. |
| R-07 | Shared data engineer | Escalated to Amber — this is decision 1 above. |
| I-02 | Sandbox rate limits | Closed. Provider raised the limit on 2026-08-18. |

## Metrics
| Metric | Last | Now | Target |
|---|---|---|---|
| Sandbox suite pass rate | 92% | 100% | 100% |
| Live volume on new provider | 0% | 0% | 5% by 2026-09-30 |
| Open defects (sev 1–2) | 3 | 1 | 0 before ramp |

## Budget
Spent EUR 402k of EUR 785k approved. Forecast at completion EUR 760k,
including EUR 45k of the EUR 100k contingency. No new budget request.

Common mistakes

Green until the week it is Red. A status that never goes Amber is not being measured; it is being performed. State milestone confidence separately from overall status so the trend is visible.
A list of activity instead of outcomes. “Held three workshops” is not progress. “Integration spec signed by Finance” is.
Decisions buried in prose. Put them in a table at the top with a date. A decision needed “soon” will not be made.

Restating the whole risk register every week. Report the changes; the full list lives in the When to use it

From project kickoff to closure, reviewed at every status cycle.

As the standing input to the risk section of the When to use it

Any meeting where a decision is made, money is committed, or scope changes.
Governance meetings — steering, change advisory board, design review — where an audit trail is expected.
Not for standups or informal syncs; a shared task board is cheaper.

What it must answer

Who was there, and who was invited but absent (absence matters when a decision binds them).
What was decided, by whom, and on what basis.
Which actions were accepted, by which named person, by which date.
What was explicitly deferred, so it does not silently disappear.

Template

 # <Meeting name> — YYYY-MM-DD

| Field | Value |
|---|---|
| Chair | |
| Minutes by | |
| Attendees | |
| Apologies | |
| Distribution | |

## Decisions
| # | Decision | Rationale | Decided by | Reversible? |
|---|---|---|---|---|

## Actions
| # | Action | Owner | Due | Status |
|---|---|---|---|---|

## Discussion notes
Brief, per agenda item. Record positions where people disagreed — not who
"lost", but what the competing arguments were.

## Deferred
| Item | Deferred until | Why |
|---|---|---|

## Next meeting
Date, and what must be ready beforehand.

Worked example

 # Payment Migration Steering — 2026-08-19

| Field | Value |
|---|---|
| Chair | R. Okafor (Sponsor) |
| Minutes by | S. Lindqvist |
| Attendees | R. Okafor, M. Duarte, A. Berg, S. Lindqvist, J. Marek |
| Apologies | P. Nowak (data) — represented by M. Duarte |
| Distribution | Attendees + programme mailbox |

## Decisions
| # | Decision | Rationale | Decided by | Reversible? |
|---|---|---|---|---|
| D-14 | Ramp starts at 5%, not the originally planned 10% | Auth-rate signal is statistically usable at 5% within 48h, and halves revenue exposure if the rate drops | R. Okafor | Yes — step size can be raised at the next gate |
| D-15 | Automatic rollback threshold set at 95.5% rolling auth rate over 30 minutes | 0.9pp below current baseline; below this the revenue loss exceeds the cost of a rollback | R. Okafor, on Finance's numbers | Yes, by steering only |
| D-16 | Dual-running extended to 8 weeks from 4 | Finance needs two full month-end cycles to trust the new reconciliation feed | M. Duarte | No — provider contract dates now assume it |

## Actions
| # | Action | Owner | Due | Status |
|---|---|---|---|---|
| A-31 | Confirm P. Nowak's allocation through September in writing | M. Duarte | 2026-08-28 | Open |
| A-32 | Implement 95.5% rollback trigger and prove it in a game day | J. Marek | 2026-09-11 | Open |
| A-33 | Re-forecast provider costs with 8-week dual-run | S. Lindqvist | 2026-09-02 | Open |

## Discussion notes
**Ramp size.** Engineering argued for 10% to reach statistical significance in
24h; Finance argued for 5% to cap exposure. Both accepted that 5% reaches
significance in 48h, which does not move M3. Decision D-14 taken on that basis.

**PCI scope.** Security has not completed the scope review (dependency D-01,
now 4 days late). A. Berg confirmed no new scope is expected but would not
sign before review completion. No decision taken.

## Deferred
| Item | Deferred until | Why |
|---|---|---|
| Bank transfer migration | FY2027 planning | Out of scope in the current charter; needs its own business case |
| Merchant fee repricing | After M4 | Depends on realised provider costs |

## Next meeting
2026-09-16. Required beforehand: PCI scope sign-off (D-01), rollback game day
result (A-32), revised cost forecast (A-33).

Common mistakes

Actions without a named person. “The team will investigate” is an action nobody has.
Recording only the outcome of a contested discussion. Six months later, someone will re-open it. Two lines on the competing arguments prevent re-litigating from zero.
No “reversible?” marker on decisions. Reversible decisions can be made quickly by one person; irreversible ones deserve the meeting’s full attention. Marking them changes how the next one is handled.
Publishing days later. Minutes lose most of their value after 48 hours; people have already acted on their own recollection.
Minuting everything. If a meeting produces no decision and no action, the minutes should say exactly that — in one line.

IT Template Library

Project Charter

When to use it link

What it must answer link

Template link

Worked example link

Common mistakes link

What it must answer link

Template link

Worked example link

Common mistakes link

What it must answer link

Template link

Worked example link

Common mistakes link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

When to use it link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

Related templates link

What it must answer link

Template link

Worked example link

Common mistakes link

When to use it

What it must answer

Template

Worked example

Common mistakes

What it must answer

Template

Worked example

Common mistakes

What it must answer

Template

Worked example

Common mistakes

What it must answer

Template

Worked example

Common mistakes

Related templates

When to use it

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer

Template

Worked example

Common mistakes

Related templates

What it must answer