Brand
Get all logo versions.
Download 
A project charter is the one-page document that authorizes a project: why it exists, what it will and won't cover, who is accountable, and what has to be true for it to count as done. This template gives you a metadata table and eight labeled stacks, from Why now through to Budget and resources, each seeded with the questions that section is asking. Sponsors sign it before work starts.
A project charter says what the project is and why it's worth doing. A project plan says how it gets done. The charter comes first, runs to a page, authorizes the work, and is written for the sponsor and senior stakeholders. The plan comes after, runs long, and is written for the team doing the work: tasks, dependencies, dates, owners. If you're asking for permission, write the charter. If you already have it, write the plan.
A project charter is a short document that formally authorizes a project and sets out its purpose, scope, objectives, stakeholders and high-level risks. It's written before work starts and signed by the sponsor, which is what separates it from a plan. Most charters run to a single page. Anything much longer usually means planning detail has crept in.
Eight things cover most charters: the business case for doing it now, measurable objectives, what's in scope, what's explicitly out, key milestones, the people involved and their roles, risks and assumptions, and the budget or resources needed. Put the project name, sponsor and date at the top. The out-of-scope section is the one most often skipped and most often needed.
The project manager usually drafts it and the sponsor signs it. The sponsor is whoever controls the budget and can say yes, which is the whole point of the document: it turns a proposal into an authorized project. Stakeholders review it but don't authorize it. If nobody can sign it, that tells you something useful in itself.
One page. A charter is a summary a sponsor reads in five minutes and signs, not a planning document. If yours is running to five pages, the extra material is almost certainly plan content: task breakdowns, detailed schedules, resourcing models. Move that out and keep the charter to what someone needs to approve the work.
An agile project charter covers the same ground with looser edges. Objectives and success measures stay, and so do the sponsor, the scope boundaries and the risks. What changes is milestones: instead of fixed dates you name the first few increments and what each one should prove. The scope sections matter more, not less, because a backlog will always offer to grow.
