The charter is the document that brings a project into existence and names the person authorised to run it. Until it is issued there may be an idea, a budget request or an approved business case, but there is no project and no project manager with any standing.
That is the whole of its job. It is short, it is signed by somebody outside the project, and it is what a project manager points at when asked who decided this work should happen.
Three documents that get run together in conversation, separated by who owns each and by what each one settles. The business case argues for the money, the charter grants the authority, and the plan describes how the authority will be used.
Two authorisations, not one
The charter authorises the project, which means the organisation has decided the work will be done and has committed resources to it. It also authorises the project manager, which means a named individual may apply organisational resources to project activities.
The second is the part people forget and the one that matters day to day. A project manager in a functional organisation has almost no formal power over the people doing the work, so authority comes from the charter and from whoever signed it rather than from a reporting line.
The sponsor issues it, the project manager may draft it
A charter written and signed by the project manager authorises nothing. It is issued by the sponsor, or by whoever sits at a level able to fund the work and commit the resources, which usually means somebody outside the project structure entirely.
Drafting is a different act from issuing. The project manager is very often the person who writes the text, and involving them early is sensible, because the person who will run the work is well placed to describe it. What makes the document a charter is the signature at the end rather than the keyboard it came from.
What belongs in it, and why
A charter states the purpose of the project and the business need it answers, so the reasoning survives after the people who made the decision have moved on. It carries measurable objectives with the criteria by which success will be judged, and vague ones cause more trouble later than any other defect in the document.
Each of the remaining elements is there because a specific argument happens later without it.
| Element | Why it is there |
|---|---|
| Purpose and business need | Keeps the reasoning available after the people who made the decision have gone |
| Measurable objectives and success criteria | Fixes what winning looks like while it can still be argued about cheaply |
| High level requirements and product description | Says what is being built at a resolution a sponsor can agree to in one sitting |
| Boundaries and exclusions | Gives every later argument about creeping scope a written position to start from |
| Overall risk and the risks known now | Puts the exposure in front of the sponsor before the money is committed |
| Summary milestone schedule | Names the handful of dates the organisation is planning around, ahead of any network |
| Summary budget | States the funding envelope the detailed estimates will later have to fit inside |
| Approval requirements | Records who decides the project succeeded, which is a different question from who paid |
| Assumptions and constraints | Exposes what the summary figures rest on, so a broken assumption is traceable |
| Named project manager and authority level | Makes one person able to apply organisational resources, and says how far that runs |
| Named sponsor and signature | Identifies the standing that everything above it borrows from |
Everything in it is deliberately coarse. A milestone schedule in a charter is a handful of dates rather than a network, because detail produced before planning has happened is invented rather than derived. The same goes for the budget, which is an envelope rather than an estimate, and for the requirements, which describe the shape of the product rather than its behaviour.
Why a project without one has nothing to point at
Projects get challenged from the moment they start. A department head wants their analyst back, a competing initiative claims the same budget, a stakeholder insists a deliverable was always included. Each of those is a question about what was agreed and who agreed it.
With a charter, the answer is a document a senior person signed. Without one, the answer is a recollection of a conversation, which loses reliably to a more firmly stated recollection of a different conversation. The charter is also the reference point for the boundaries, so an argument about creeping scope starts from a written position rather than from competing memories.
Work that begins without a charter tends to show the symptoms rather than announce the cause. Resources drift away to other priorities, objectives move quietly, and nobody can say whether the project succeeded because success was never written down.
The charter is not the plan
The charter says what the project is and that it may proceed. The project management plan says how it will be run, and it is developed afterwards, approved separately and amended through change control.
Because it sits above the plan, a charter changes rarely and only through the sponsor. If the purpose or the objectives genuinely change, the sponsor reissues it, and that is a significant organisational event rather than an editing task. A charter quietly updated every month has stopped being an authorisation and become a status report.