Project Charter Explained: Authorisation, Boundary and Success

A project charter is the document that authorises a project to exist. It names the sponsor, states what the project will and will not do, defines what success looks like, identifies the constraints, and gives the project manager the authority to spend resources.

It is short — one to three pages — and it is the document most often skipped, most often written as a formality, and most reliably missed six months later when three people have three different understandings of what was agreed.

What it decides#

Who is accountable. One named sponsor, not a steering group. When a decision must be made and opinions differ, somebody decides. If that person cannot be named, the project does not yet have authorisation — it has interest.

What is in scope, and what is explicitly out. The out-of-scope list prevents more disputes than the in-scope list. Every project acquires expectations; the ones written down as excluded are the ones you can decline without a negotiation.

What success means, in measurable terms. Not "improve the customer experience" but the specific change that would justify the investment.

What the constraints are. Budget, date, regulatory deadline, resource availability, technology mandated by someone else.

What is assumed. The assumptions section is where the project's real risk usually lives. "Assumes the finance team can provide historical data in a usable format" is a sentence that, when wrong, costs a quarter.

Writing success criteria that can be measured#

The test is whether someone could determine, a year later, whether it was met — without a discussion.

Weak: Improve the efficiency of the claims process.

Measurable: Reduce average claim handling time from 14 days to under 7, measured on claims received after go-live, without increasing the reopen rate.

Include the baseline. A target without a starting point cannot be assessed, and the baseline is much harder to establish after the project has begun disturbing the process.

Include what must not get worse. Most projects improve one number by damaging another, and the damage is discovered by whoever owns the second number.

The sections worth having#

• Purpose — why this, why now, in a short paragraph
• Objectives and success criteria — measurable, with baselines
• Scope — in, and explicitly out
• Deliverables — what will exist at the end
• Sponsor, project manager, key stakeholders — named individuals, with decision rights
• Constraints — budget, dates, mandated technology, regulatory deadlines
• Assumptions — what must be true, and who confirms each
• High-level risks — the three or four that could stop this
• Milestones — a handful, not a plan
• Approval — signature and date

Anything beyond that belongs in the plan, not the charter. A ten-page charter is a plan with the wrong title, and it will not be read at the moment it is needed.

Why charters fail#

Nobody can find it. The most common failure by a wide margin. A charter that exists in an email attachment from March is not a reference point; it is an artefact.

The sponsor is a committee. Escalations then take weeks, and each one re-opens a question the charter was supposed to have closed.

Success criteria are aspirational. Written to be approved rather than assessed, so at the end nobody can say whether the project worked — and the organisation learns nothing about which projects to fund next.

No out-of-scope section. Every request becomes a negotiation, because nothing was ever declared outside the boundary.

Written after the project started. Backfilled charters describe what is already happening and authorise nothing.

Never revisited. Constraints change, sponsors move on, the business context shifts. A charter that is never updated becomes progressively less true, and at some point people stop citing it — which is the moment scope control ends.

How it relates to everything else#

The charter sets the boundary. The BRD states the business requirements inside that boundary. Change Management governs movement of the boundary, and the charter is what a change request is measured against — without it, there is no baseline to change from.

At the end, the charter's success criteria are what Lessons Learned and any benefits review assess against. A project that closes without comparing outcome to the original criteria has completed, but nobody knows whether it succeeded.

A realistic starting point#

One page. Purpose, three measurable success criteria with baselines, in-scope list, out-of-scope list, named sponsor and project manager, top three risks, key constraints, key assumptions, signature and date.

Circulate it to the people whose expectations differ — that is what the document is for. If nobody objects to anything, either it is genuinely agreed or nobody read it, and it is worth finding out which.

FAQ#

Do agile projects need a charter?#

Yes, and often more than plan-driven ones. Agile flexes scope, which makes the boundary and the success criteria the stable reference. Something has to say what this initiative is for and who decides; that is the charter, whatever it is called.

How long should it be?#

One to three pages. If it exceeds that, the extra content is planning detail that will go stale and dilute the parts that need to be read.

Who writes it?#

The project manager, with the sponsor. Written by the sponsor alone it tends to be aspirational; written by the project manager alone it may not carry the authority it claims. It must be signed by the sponsor to mean anything.

What if there is no clear sponsor?#

Then you have a serious problem, not a documentation gap. A project without a single accountable sponsor will escalate every difficult decision into a committee and will absorb scope from whoever is most persistent. Resolve this before starting; it is far harder to fix mid-flight.

Can the charter change?#

Yes, through the change process, with the sponsor's approval and a version record. What it must not do is drift — informal changes that never reach the document leave you with no baseline and therefore no ability to say what the project agreed to do.

Is it the same as a business case?#

No. The business case argues that the investment is worthwhile; the charter authorises the work and sets its boundary. Small projects often combine them, which is fine as long as both questions — is it worth it, and what exactly are we doing — get answered.

What if the sponsor will not commit to measurable criteria?#

That reluctance is information. Usually it means the benefit is not well understood, or nobody wants to be held to it. Either is worth surfacing before the money is spent, because the project will otherwise be judged at the end against whatever criteria are remembered then.

Related Articles#

Move from the charter to the BRD for requirements, protect the boundary with Change Management, track threats in the Risk Register, and close honestly with Lessons Learned.

What else is coming for Project Charter