A project charter someone will actually read

A project charter authorizes work and records the decisions behind that authorization. It names the sponsor, the objective, the decision rights, the constraints, and the measure of success. That is the whole job. Everything else in a typical charter template is context, and context belongs somewhere people can search for it rather than at the front of the document you need in an argument.

The test is simple. Six weeks in, someone disputes whether a piece of work is in scope. Does anyone open the charter? If the answer is no, the charter is decoration. If the answer is yes and the dispute is settled in under a minute, the format is right.

This is why length matters more than completeness. A one-page charter that gets consulted beats a twenty-page charter that gets filed. Atlassian's overview of project management methodologies makes the same point about process generally: the framework that helps is the one the team will actually follow, not the one that scores highest on paper.

Three reasons, and they compound. The first is that the template front-loads background. Business case, market context, strategic alignment. All potentially true, none of it useful when you are deciding whether to accept a change request on a Thursday afternoon.

The second is that it hedges. Charters written to survive review by committee use language like "aims to improve" and "stakeholders will be engaged as appropriate". Neither sentence can be violated, which means neither sentence can settle anything.

The third is that it has no owner after signature. A charter written by a consultant and handed over is an artifact of a sales process. A charter written by the person accountable for delivery is a working document, because that person has to live inside it.

Fixing the first two is mostly a matter of deleting. Fixing the third is a staffing decision. If nobody on the project has both the authority and the incentive to maintain the charter, do not write one, and be honest that governance is happening informally.

Seven fields, one page, no appendices. If a field cannot be filled in, that is the finding. A project with no named sponsor is not underspecified, it is unfunded, and writing a charter will not change that.

The constraints row is the one people fight about, because the honest answer is unpopular. A project cannot hold date, budget, and scope simultaneously fixed. Naming which one flexes, in writing, before work starts, is worth more than the rest of the document combined.

Most charters name a sponsor and stop. That is not decision rights, that is an org chart. Decision rights answer a narrower question: for each class of decision, who can approve it, and what is the fallback when that person is unavailable?

Three classes cover almost everything in digital delivery. Scope changes, which alter what gets built. Spend changes, which alter what it costs. Release approval, which decides whether something goes live. These are frequently held by three different people, and the charter is where you find that out cheaply rather than expensively.

Write the fallback explicitly. "If the sponsor is unavailable for more than three business days, the delivery lead may approve changes up to $5,000 and will report them at the next steering session." That sentence prevents a specific, common, expensive failure: work stopping because one person is on holiday.

If you are running a programme rather than a single project, the same discipline applies one level up. Atlassian's description of program management as the coordination of related projects toward a shared outcome is useful here, because it makes clear that the programme charter and the project charter answer different questions and should not be merged.

A success measure is a number and a date. "Improve reporting efficiency" is not one. "Monthly client reporting takes under four hours of analyst time, measured in the first full month after go-live" is one, because at the end of that month it is either true or false.

Two rules make this easier. First, name where the number comes from before the project starts, not after. A measure with no agreed source becomes a negotiation. Second, record the baseline. A target with no baseline cannot demonstrate improvement, only compliance.

The baseline rule is the one agencies skip most often, and it costs them the strongest evidence they will ever have. On a transit BI programme, the fact that 154 data sources moved with zero unplanned outages is only a claim because someone counted the sources beforehand. Without the count it is an adjective.

Keep the number of criteria to three or fewer. A charter with nine success measures has none, because nobody will hold nine numbers in their head, and at the end somebody will select whichever three look best.

These three documents get conflated constantly, usually by pasting the charter into the SOW or the SOW into the deck. They serve different readers and different moments, and a merged document serves none of them well.

The clean division: the SOW is the commercial boundary and the charter is the operating one. If your commercial document is doing both jobs, read what actually decides margin in a fixed-fee scope document first, because the exclusions section is doing work the charter cannot do.

Do not circulate a blank charter and ask for input. You will get either silence or nine opinions, and neither converges. Write a complete draft with every field filled in, including the ones you are guessing at, and send it with a specific request: correct what is wrong.

People are far better at objecting to a wrong answer than producing a right one. A draft that says "Constraint: the launch date is fixed, budget flexes" will get corrected within an hour if it is wrong. A blank field labelled "Constraints" will sit untouched for a week.

Hold one meeting, forty-five minutes, with the sponsor and the two or three people who hold decision rights. Walk the seven fields in order. Change what needs changing in the room. Get agreement verbally and confirm it in writing the same day.

If the meeting cannot be convened, that is your first real finding about the project, and it should go in the risk section rather than being worked around. Requirements discipline follows the same logic: Atlassian's guidance on the product requirements document treats it as a living record of decisions the team has agreed on, which only works if agreement was obtained rather than assumed.

A charter is not immutable, but it should be expensive to change. Reopen it for exactly four triggers: the sponsor changes, a constraint that was flexing becomes fixed, a success measure becomes unmeasurable, or scope changes by more than a threshold you named in advance.

Everything else is change control, and change control belongs in the tracker rather than the charter. Confusing the two produces a charter that is edited weekly and therefore trusted by nobody, which returns you to the original problem.

Version the document and keep the old versions readable. When a project is reviewed after the fact, the sequence of charter changes is often the most honest account of what happened that anyone will find.

One practical note on ownership. The charter is the artifact that makes delivery accountability visible, which is why it is normally the first thing produced in a fractional technical project management engagement and one of the deliverables described in what the role actually covers. If nobody produces one in the first two weeks, the engagement has already drifted toward coordination and away from ownership.