Most project charters are written to satisfy a governance requirement rather than to make a decision. They get signed, filed, and never opened again. Then six months later the project is in trouble and nobody can agree what it was supposed to deliver.
A charter is not paperwork. It is the record of what everyone believed at the moment the organisation committed money to this. Its value is not in the writing — it is in the arguments the writing forces you to have while they are still cheap.
Five questions do most of that work. If a charter answers them honestly, the project has a foundation. If it can't, the project is already carrying a problem it hasn't discovered yet.
1. What does this project actually change?
Not what it delivers — what it changes. There is a difference, and most charters only answer the first.
"Implement a new ERP" is a deliverable. "Reduce month-end close from twelve days to four, and give plant managers same-day visibility of production costs" is a change. The first tells you what to buy. The second tells you when you can stop.
This is the question that determines whether the project can ever be declared finished. A project defined by its deliverable ends when the deliverable exists, whether or not anything improved. A project defined by the change it makes has a test it can pass or fail.
Write the change in the language the business already uses to describe the problem. If the sponsor wouldn't recognise it as their problem, you have written a specification rather than a charter.
2. Who decides, and what can they decide alone?
Almost every charter names a sponsor. Very few say what the sponsor is actually allowed to approve without going elsewhere.
That gap surfaces at the worst possible moment: a change request arrives, the sponsor says yes, and three weeks later someone discovers the approval needed a steering committee the sponsor didn't know had authority. Work stops. Trust erodes. The change gets re-litigated.
The charter should record decision rights explicitly. Who approves scope change below a threshold, and what is the threshold. Who approves it above. Who can move the date. Who can accept a deliverable on the customer's behalf. Who can say no to something the project team thinks is a good idea.
This takes twenty minutes to write and saves weeks. It is also uncomfortable, because it requires senior people to state the limits of their own authority in front of each other. That discomfort is the point — if it is awkward to establish now, it will be far worse to establish mid-delivery under pressure.
3. What are we explicitly not doing?
Scope is defined as much by its boundaries as by its contents, and boundaries are where charters are weakest. Most list what is in scope and stop there, leaving everything unmentioned in a grey zone that gets resolved later by whoever argues hardest.
An exclusions list is not pessimism. It is the difference between a change request and an argument. When something excluded gets requested — and it will — the conversation is about whether to fund it, not about whether it was always supposed to be included.
Be specific. "Reporting is out of scope" is not useful. "Custom management reporting beyond the five standard reports listed in Appendix B is out of scope" is enforceable.
The exclusions people resist writing down are usually the ones that matter most. If a stakeholder is reluctant to see something on the excluded list, you have found a genuine disagreement about scope that would otherwise have surfaced in month seven.
4. What has to be true for this to work?
Every project plan rests on assumptions. Most charters record none of them, which means nobody notices when one quietly stops being true.
The assumptions worth writing down are the ones that would change the plan if they were wrong. Key people being available at the agreed percentage. A supplier hitting a lead time. A decision arriving by a date. Data being in better condition than anyone has actually verified. Another project finishing first.
Writing them down does two things. It makes them reviewable, so somebody can check periodically whether they still hold. And it makes them negotiable — an assumption that is visible at the start can be challenged by someone who knows better, which is the cheapest possible moment to find out.
The test for whether you have recorded enough: if the project slipped badly, would the explanation appear anywhere on this list? If the likely failure mode isn't written down, the charter is describing a project other than the one you are about to run.
5. How will we know it worked?
This is the question most often answered with something that cannot be measured. "Improved efficiency." "Better visibility." "Increased customer satisfaction." All plausible, none testable.
Acceptance criteria need to be specific enough that two people looking at the same evidence would reach the same conclusion. That usually means a number, a date, and a named person who will confirm it.
It also means agreeing the measurement before the work starts, not after. Measurement criteria negotiated at the end of a project are always shaped by what the project happened to achieve. Criteria agreed at the start are the only ones that can genuinely fail.
And capture the baseline while you still can. You cannot demonstrate a reduction in month-end close without knowing what it was before you started. That number is easy to obtain in week one and nearly impossible to reconstruct credibly in month nine.
What to do with a charter that can't answer these
The usual instinct is to write something plausible in the gaps and move on, because the charter is blocking a gate and the gate is blocking a start date.
Resist it. A charter with an honest gap is more useful than one with a confident invention. Write what you don't yet know, who is going to find out, and by when. An unanswered question with an owner and a date is a managed risk. An invented answer is an unmanaged one, and it will be discovered at exactly the wrong moment.
If the gap is question one or question five — what changes, and how you'll know — that is worth escalating rather than papering over. A project that cannot describe the change it makes or the evidence it will accept is not ready to be authorised, however much pressure there is to start.
Find out where your delivery actually stands
Eight dimensions, thirty-two indicators, about twenty minutes. The output is a gap profile you can take straight into a leadership conversation.
Open the assessment