# What is a project charter? How to write one your team will use > A project charter is a one-page agreement on why a project exists, what done means, and who decides. Here is how to write one people use. By Austin DeBerry, Founder, Coastline CRM --- A project charter is a short, one-page agreement that states why the project exists, what "done" looks like, who gets to make decisions, and what is explicitly out of scope. That is the whole thing. It is not a plan, not a spec, not a contract; it is the single page everyone can point to when memory and opinion start to diverge three weeks in. I have come to treat it as the cheapest insurance in project management. Ten minutes of disagreement surfaced on day one beats two months of building the wrong thing and finding out at the demo. ## Why a charter matters more than it looks The value of a charter is not the document. It is the conversation you are forced to have to write it. The moment you try to put "why this project exists" into one sentence, you discover whether the people in the room actually agree. Usually they do not, at least not as much as they assumed. The sponsor wants one outcome, the team is solving for another, and someone has a deadline nobody else knew about. That disagreement is a gift when it shows up early and a disaster when it shows up late. Most of [why projects fail](/blog/why-do-projects-fail) traces back to fundamentals that were never pinned down, and the charter is where you pin them down before they cost anything. It is the artifact that turns vague enthusiasm into a shared definition of the work. ## What goes on the page Keep it to one page on purpose. The constraint forces clarity, and a charter nobody can read in two minutes is a charter nobody will reference. Cover these: - **Purpose.** One or two sentences on why this project exists and what problem it solves. If you cannot say it plainly, you are not ready to start. - **Success criteria.** What done looks like, stated as outcomes you could actually verify. "Reduce manual data entry to zero for the intake step," not "improve the process." - **Scope and out of scope.** What is included, and just as important, what is not. The out-of-scope line is the one most people skip and the one that saves you most often. - **Decision-maker.** Who has final say when there is a tie. One name. Decisions by committee are decisions nobody owns. - **Key constraints.** Hard deadlines, fixed budget, fixed team, anything that genuinely cannot move. - **Top risks.** Three or four things most likely to go wrong, each with an owner. That is enough. Resist the urge to bolt on a full timeline, a staffing plan, and a glossary. Those belong in other documents. The charter exists to answer "what are we doing and who decides," and the more you cram in, the less it gets used. ## The out-of-scope line does the heavy lifting If you take one thing from this, make it the out-of-scope section. It is the part teams are most tempted to leave blank, and it is the part that earns its keep every single time. Writing down what you are not doing gives you a clean, unemotional answer when the requests start arriving: "Good idea, and it is out of scope for this project. Let us put it on the list for later." Without that line, every new request is a negotiation with no reference point, and [scope creep](/blog/what-is-scope-creep) wins by a thousand small yeses. With it, the charter does the saying-no for you, which is much easier than saying no yourself in the moment. ## How to write one your team will actually use A charter that lives in a folder nobody opens is wasted effort. The trick to making it referenced is the same as making anything referenced: keep it short, keep it visible, and use it out loud. - Write it with the team, not for them. A charter handed down is a charter ignored; one built in a half-hour conversation has buy-in baked in. - Read it at the [kickoff meeting](/blog/how-to-run-a-project-kickoff-meeting) so everyone hears the same words at the same time. That single read-through catches more misalignment than any amount of solo review. - Pin it where the work happens, not in a separate archive. The closer it sits to the daily flow, the more it gets used. - Revisit it when something big changes. A charter is allowed to evolve; it is not allowed to quietly go stale while everyone pretends it still describes the project. ## Takeaway A project charter is one page that says why you are doing this, what done means, who decides, and what you are deliberately not doing. Write it with the team, keep it short, lean hard on the out-of-scope line, and read it aloud at kickoff. It is the smallest document in project management and one of the few that pays for itself before the project even starts.