Writing a charter doc short enough that people finish reading

Somewhere in the shared drive there is a charter doc for a project that is currently running. It was written in the second week, approved in the fourth, and has not been opened since. The scope in it no longer matches what the team is building. Two of the named stakeholders have moved on. The success criteria were written vaguely enough that nobody can be held to them, which was convenient at the time and is now the reason the project has no defined finish line.

That outcome is normal, and it is not caused by the template. Most charter templates are competent. The problem is that a charter is usually written as a thing to get through rather than a thing to use, so it grows to the length that looks appropriately serious and then stops being read. A charter that nobody rereads has no effect on how the project runs, which makes it an expensive way to pass an approval gate.

The useful version is short, specific enough to be argued with, and kept where the work is visible.

What a charter settles that nothing else does

A charter has one structural job: it converts a project from an idea several people have different versions of into a single stated agreement about what is being done, by whom, with what authority, and what would count as finished.

Everything else in a project can be revised without much friction. Tasks move. Dates move. Owners change. The charter is the layer underneath that, the layer the team goes back to when a disagreement cannot be settled by looking at the board. When a stakeholder asks in month three why a feature was cut, the charter is the document that either answers that in one line or reveals that the boundary was never agreed in the first place.

This is why the vague charter is worse than no charter. A charter that says the goal is to improve the customer onboarding experience cannot settle an argument, because every party can read their own intention into it. A charter that says onboarding will be reduced from eleven steps to six by the end of Q3, with mobile out of scope, settles a great many arguments before they start. The second version is also riskier to write, which is precisely why it gets softened during review.

Two related documents get confused with it constantly, and the confusion inflates charters until nobody finishes them. A charter authorizes and bounds the work. A plan describes how the work will be sequenced. A brief describes the reasoning for an audience that will not do the work. Putting all three in one file produces a twenty page document that gets approved unread.

The eight things it has to answer

Most templates offer somewhere between ten and twenty sections. Eight questions carry nearly all of the value, and each one should be answered in a few lines rather than a page.

Why now. The problem, and what happens if nothing is done. One paragraph. If this cannot be written without referring to a strategy deck, the project is not ready to be chartered.

What finished looks like. Stated so that a neutral reader could check it. Three criteria at most. This is the section that most often gets diluted in review, and the dilution should be resisted.

What is out of scope. The most valuable section in the document, and the one most often left blank. Naming two or three things that will not be done is what prevents the slow expansion that kills the timeline.

Who decides. One named person who can approve a change of scope, not a committee. A charter that lists five approvers has no approver.

Who does the work. Names and the rough share of their time. Half of all schedule failures are visible at this line, when three people are each listed at fifty percent on three different projects.

Time and money. The window, and the budget or headcount. If the budget is not known, state that it is not known rather than omitting the section.

Known risks. Three at most, each with the response already decided. A list of fifteen unowned risks is decoration.

Dependencies. What has to come from outside the team, and who owns each one.

Notice what is absent. There is no methodology section, no glossary, no communications matrix. Those can exist elsewhere if they are needed. Inside the charter they push the eight answers below the point where a busy approver stops reading.

One page, or several

The one page charter is popular for a reason and unsuitable for some work. The honest comparison is about who reads the document and what they are deciding.

Length	Fits	Breaks down when
One page	Small internal projects, a single team, a familiar problem	Money is significant, or an external party has obligations
Three to five pages	Cross team work, a defined budget, a formal approval step	Regulated work needing a documented audit trail
Ten pages or more	Contracted delivery, compliance obligations, capital spend	Anything a working team is expected to consult weekly

The mistake is not choosing the wrong length. It is choosing the long form and then also expecting the team to use it day to day. Those are two different documents doing two different jobs. Where a long charter is genuinely required, the practical answer is to write it, then maintain a one page summary carrying the goal, the non goals, the decider, and the dates, and put that summary where the team can see it.

A rough test for the short version: if reading it aloud takes more than three minutes, it will not be reread, and anything that is not reread has no effect on behaviour.

Getting it approved without a three week loop

Charters stall in review for predictable reasons, and the sequence of who sees it matters more than the wording.

Circulating a blank template with a request for input produces nothing. A charter should be drafted by one person, with real numbers and real names in it, then reviewed. Objections to something concrete arrive quickly. Requests to fill in a blank arrive never.

Talk to the person who controls the scarcest resource before anything is circulated. Usually that is whoever owns the time of the people named in the staffing line. A charter approved by leadership but not by the manager of the engineers in it is not funded, it is only endorsed.

Set the review as a meeting rather than a comment thread. Comment threads on charters run for weeks because no comment is ever the last one. Forty five minutes with the decider and the two people most affected, working through the out of scope list line by line, resolves what three weeks of asynchronous review will not.

Expect the pressure to soften the success criteria, and hold one number. There is usually at least one thing the team is willing to be measured on. Keeping that single number specific preserves most of the value of the document even when everything else drifts toward diplomatic language.

Keeping it from going stale

An approved charter is accurate for roughly as long as the project stays on its first assumptions, which is rarely more than a few weeks. After that it drifts, and the usual response is to ignore it, which wastes the effort that went into writing it.

Two habits are enough to keep it current. First, when scope changes, the charter is edited in the same hour, with one line noting what changed and who approved it. Not a new version in a new folder. The same document, so there is never a question about which copy is real. Second, the out of scope list gets read at the start of any conversation about adding work. Most scope expansion happens because nobody remembers what was excluded, not because anyone decided to override it.

The condition that makes both habits possible is location. A charter that lives in a documents folder, separate from the board where tasks are tracked, gets forgotten within a fortnight. The same charter pinned to the board the team opens every morning gets consulted. This is a mundane point, and it is the single largest determinant of whether the document survives.

Where the document should sit

The practical arrangement is that the charter lives with the work, not in a parallel filing system. That means the board, timeline, or workspace the project actually runs in, as the first card in the first column, or as the description on the board itself.

Most tools support this, though the shape differs. Some keep documents and tasks in the same workspace by design. Others keep a separate wiki, which works as long as one link from the board points at the charter and is kept correct. What does not work is a charter in one system, tasks in a second, and the discussion about scope in a third chat app, because the discussion is where the scope actually moves and it will never be reconciled with the document.

A worked example: a charter as the pinned first card on a kanban board, the milestone dates from it as the top level bars on the timeline view, and the out of scope list copied into the board description so it is visible without opening anything. The comparison of how different tools handle keeping planning documents and task tracking in one place is covered in the tool comparisons, and the boards and views available in one workspace are listed under features.

One more practical detail. Whoever writes the charter should also own the board it lives on. Splitting authorship from ownership is how documents become orphaned, and an orphaned charter is indistinguishable from no charter at all.

When writing one is not worth it

Not every piece of work needs a charter, and writing them for everything is how the format loses credibility. Three cases are usually better served by something smaller.

Work under about two weeks with a single owner and no external dependency does not need one. The overhead of drafting and approving exceeds the risk being managed. A ticket with acceptance criteria covers it.

Recurring operational work does not need a charter either. Monthly reporting, release chores, and support rotations have no finish line, so the success criteria section has nothing to say. These belong in a documented process, kept next to the board where the work appears.

Work where the sponsor cannot yet name a success criterion is the third case, and it is the interesting one. When the goal genuinely cannot be stated in checkable terms, the honest response is to run a short piece of discovery with its own narrow boundary and write the charter afterwards. Chartering an undefined project produces the vague document described earlier, which then gets cited as evidence that charters do not work.

The signal that one is worth writing is straightforward: more than one team is involved, or someone outside the team has an obligation, or the scope will be argued about later. Any of those three, and the hour spent drafting is recovered quickly.

What to change first

Take the charter for the project currently running, cut it to one page, and make the out of scope section real by naming three things that will not be done. Then move it next to the board the team opens each morning, because a charter in a separate folder stops being read regardless of how good it is. A short getting started guide covers pinning it alongside the work in Pinateca if the project is currently tracked somewhere the document cannot follow.

Q1. How long should a charter doc actually be?

For a small internal project run by one team, one page is enough and anything longer will not be reread. Cross team work with a real budget usually needs three to five pages. Where a long formal charter is required for compliance or contract reasons, write it and also maintain a one page summary with the goal, the non goals, the decider and the dates, because the long version will not be consulted day to day.

Q2. Who is supposed to write the charter, the sponsor or the project manager?

Whoever will run the work should write the draft, with real names and numbers in it, and the sponsor should review and approve. Circulating a blank template for the sponsor to fill in almost never produces a usable document. A draft with something specific in it gets objections within days, which is the fastest route to an agreed version.

Q3. What is the difference between a charter and a project plan?

A charter authorizes the project and sets its boundaries: why it is being done, what counts as finished, what is excluded, who decides, and what resources are committed. A plan describes how the work will be sequenced and scheduled. The charter changes rarely and only with approval. The plan changes constantly. Combining them produces a document too long to approve and too static to use.

Q4. Does a charter still matter for a team running in two week sprints?

Yes, and for a different reason than in stage gated delivery. Iterative teams rarely argue about sequence, but they do argue about scope boundaries and about what finished means, which is exactly what a charter settles. A one page version with the goal, three success criteria, and an explicit out of scope list is usually enough, and it saves the recurring argument about whether a request belongs in this project at all.

Q5. How often should the charter be updated?

Whenever scope, dates, budget or the named decider changes, and in the same hour rather than at a later review. Edit the existing document and add one line recording what changed and who approved it, instead of creating a new version in a new location. Two copies of a charter means neither is trusted, and an untrusted charter is not used to settle anything.