Every project starts with an idea, but ideas alone don’t get teams aligned or budgets approved. That’s where a project charter comes in. Writing a strong project charter gives your project a clear foundation, and more importantly, it gives you the authorization from the sponsor to begin the work.
What is a project charter and why does it matter?
A project charter is the official document that authorizes a project to exist. It names the project manager, outlines the high-level objectives, identifies key stakeholders, and sets the boundaries for what the project will and won’t do. Think of it as the founding agreement between everyone involved, before the real work begins.
It comes after the business case but before any of the project management plan documentation. It’s the first real project artifact that you’ll create (unless you get involved in the business case creation) so it happens early in the project lifecycle.
Without a charter, projects tend to start on shaky ground. Teams make assumptions, sponsors have different expectations, and scope starts creeping from day one. The charter puts everyone on the same page from the start.
And if you’re still thinking that project kickoff documentation is bureaucracy and that the business case is enough, the numbers support working in a structured way.
According to one of PMI’s Pulse of the Profession reports, organizations that invest in structured project management practices (which I would say includes documentation for governance purposes), waste 28 times less money due to poor project performance.
What’s the difference between a charter and a PID?
A project initiation document (PID) is what I learned to use and you don’t need both. In my experience, a PID tends to be a bit longer with more information in. Charters are the preferred term in the PMBOK® Guide. I’ve also seen it called a project contract, proposal or project brief, or you could use a Terms of Reference if your project is small (here’s a guide on how to choose whether you need a charter or ToR).
What should be included in a project charter?
A good project charter doesn’t need to be long, but it does need to be complete. There are several core components that every charter should cover.
Project purpose and description
Start your charter with the project title or name, and a short description. You want two or three sentences at most, that any stakeholder could read and immediately understand what this project is about — the business need.
Project objectives
Focus on the purpose of the project and its objectives. I tend to copy these from the business case.
If the objectives in the business are a bit vague, this is your opportunity to use the SMART framework to write better ones, with the consent of the sponsor.
Tie objectives directly to business outcomes where you can. When stakeholders can see how your project connects to organizational goals, buy-in becomes much easier to secure.
Scope, deliverables, and constraints
There might be a scope section in the business case you can copy in, but in my experience they are nowhere near detailed enough. Your charter should list exactly what is being covered and what is excluded. If you have different phases planned, detail what’s going to happen in each one.
Of course, you can change this later through the change control process (not uncontrolled scope creep), but at least you’re starting out with a common view of what should be included in the project.
List your key deliverables clearly as well. Scope and deliverables are different. Scope could include statements like “Rollout solution to all UK offices” and the deliverable would be “training material to support the rollout”.
Tip!
Add budget constraints into your constraints section, because money is nearly always constrained so you may as well call it out!
Roles, responsibilities, and stakeholders
If you have a RACI already, point to it. On that note, link any other documents throughout – don’t duplicate the work if you can add a link to where the reader can find the information.
Name the project sponsor or owner, the project manager, and the core team members in the charter. You should already know who these people are. The charter is the document that gives you (the project manager) delegated authority from the sponsor to lead the work .
Timeline, milestones, and budget overview
The charter is not a project plan. You’re not expected to have a fully built schedule or a line-item budget at this stage. What you do need is a realistic high-level view: key milestones, a rough project timeline, and a budget range that reflects honest estimates.
All of this would have been in the business case, so if there was one (and I get it, there might not have been), pull the data from there. You may now be in a position to have the next-level down information or a bit more of an idea about dates, so expand and amend as necessary.
My recommendation is that you are careful about presenting project budget figures as fixed commitments in the charter. At the initiation stage, there is still a lot you don’t know. Presenting a range with clear assumptions is more credible and more honest than giving a precise number you can’t yet defend.
Benefits and outcomes
Add in a section for expected project benefits, whether they are financial or other. You can also add in OKRs or any other agreed metrics that will be used to track outcomes and validate whether the project met its business case expectations and targets.
How to write a project charter step by step
Here is a straightforward approach that works for projects of almost any size.
Step 1: Gather context and background from key stakeholders
Before you write a word, talk to the people who have a stake in the outcome. Understand the business problem, the history behind the request, and any constraints that already exist. The more context you have upfront, the stronger your charter will be.
Get a copy of the business case or any other documentation that already exists. Find your Charter template from the PMO or ask another project manager for one so you don’t have to create it from scratch!
Step 2: Define the project purpose in one to two clear sentences
Keep it plain and simple. If you can’t explain what the project is trying to achieve in a couple of sentences, you don’t have enough clarity yet. Go back and ask more questions.
Step 3: List measurable objectives aligned with organizational goals
Use SMART criteria and connect each objective to something the business actually cares about.
Step 4: Define scope boundaries and identify key risks
Write down what’s in scope, what’s out of scope, and flag any known risks or dependencies that could affect delivery. They don’t need to be exhaustive at this stage, just the obvious ones from the risk register that stakeholders should be aware of.
Step 5: Add the stakeholders and resource estimates
Name the sponsor, project manager, and core team. You’ll move on to do proper stakeholder analysis later, but at this point you’ll have a good idea of which teams need to be involved and which subject matter experts you will have to lean on.
If you know it (or can guess), add in how much resource you’ll need from each team and when that resource requirement will start.
If your PMO mandates a RACI matrix, this is a good time to be preparing it alongside the charter.
Step 6: Check the high-level timeline and budget range
When you picked up the PM work for this project, you probably got told the ballpark budget and the expectations for dates. Take those, and if you have the time, do a quick review with key stakeholders to double-check they are sensible.
Add in a milestone chart once you’re confident you have a realistic understanding of what the dates should be. Add budget estimates into the document as ranges with clear assumptions rather than fixed numbers, with a note saying at what point you’ll have a clearer view.
This step gets easier the more project management experience you have. At this point in my career I can look at a project (in my industry) and know what key milestones are likely to be required, and I’ve worked in my organization long enough to know who I need to lean on as subject matter experts.
If you are still new to project management, ask a mentor or another project manager to help if you need it. If you already have a high-level Gantt chart, paste a screenshot into the document.
Add the detail to the charter template; this becomes the basis of your implementation plan later.
Contingency plans
If there are contingency plans, mention these too. For example, on one of my projects, we had to launch it at a quiet time for the business. That meant a go live at Christmas. The contingency plan was to go live at Easter if we missed the Christmas window because that was the next opportunity we would have to minimize disruption on the business.
Step 7: Get formal sign-off from the project sponsor
This step is non-negotiable, although in practice, I’ve managed plenty of projects where we haven’t had official sponsor approval until way after we’ve started the work.
In the textbooks at least, without a sponsor signature, the charter is just a document. With it, the project has official authorization, and you have documented support to point back to if things get complicated later.
Meanwhile in real life, we all just get on with the work while we wait for the paperwork to catch up.
Electronic ‘signature’ is OK and that can mean replying back to an email saying they approve. Just print out a copy of the email (print to PDF) and save it with the project files. Link their name in the document to the electronic copy of the email and you’re good.
Common mistakes to avoid when writing a project charter
Even experienced project managers make avoidable mistakes when writing charters. Here are the ones that come up most often, and how to sidestep them.
Writing the charter in isolation
I get it, it’s easier to do the bulk of the work yourself. However, when stakeholders haven’t been part of the process, they’re more likely to push back on the content and less likely to feel ownership over the outcome. Involve key people early, even informally.
Making it too long and detailed
Aim for 2-3 pages. You’ll go longer with a PID. A project charter is not a project plan. The charter should be high-level enough that a busy executive can read it in ten minutes and understand what the project is, why it matters, and what it needs to succeed.
Sometimes we’ve even had to prepare these as 1-pagers as an exec summary.
Using jargon that alienates stakeholders
Remember your audience is not people who necessarily understand the technical jargon. Technical language might feel precise to you, but it creates distance with non-technical sponsors and business leaders. Write the charter in plain language. If someone outside your team couldn’t understand a sentence, rewrite it.
Skipping formal sign-off
Verbal agreement isn’t the same as documented approval. If your project runs into trouble and decisions need to be revisited, the signed charter is your evidence of what was agreed.
If you do have to settle for a verbal agreement, document it in the minutes of the meeting so you still have a record to look back on.
Treating the charter as a one-time document
Projects change. Scope shifts. Priorities evolve. Your charter should be treated as a living reference point that gets reviewed and updated when significant changes occur. If the document sitting in a shared drive no longer reflects reality, it’s not helping anyone.
In practice, this means reviewing it at the end of every major phase or when something big happens that changes the budget or timeline. Save a different version with a different version number (using version control) so you keep the history.
How to get stakeholder buy-in for your project charter
In theory, the stakeholders (mostly) want the project so getting buy-in should be straightforward.
In reality, you might have to negotiate scope, point out why a high impact risk really should be included and fight for more funding.
Getting buy-in for the project isn’t a one-off job. The charter helps because it helps people see what the project is all about and how it supports the organization’s strategy and objectives.
When you’re ready to present the charter formally, frame everything around value and outcomes. Stakeholders want to know what the project will achieve for the business, not how you’re planning to manage it. Lead with the why, back it up with the what, and save the how for the project plan.
If stakeholders don’t appear to be keen, this is useful information! Use the challenge to better understand what their concerns are. Then you can better address them.
Tips for sharing the charter with senior leaders
Personally, I would circulate the draft charter for comment on email. Give people a set amount of time to comment and then either incorporate those comments, or if you don’t get any, issue the final version to the people who need to approve it.
Project charter vs. project plan
This is a question that comes up in my mentoring calls with newer project managers: what’s the difference between a project charter and a project plan?
The charter is the authorization document that kicks off the work and gives you the delegated authority to run it. It’s high level.
The project plan describes how the project will be executed, covering the project management processes you’ll use to do the work. It includes the resource management plan, the risk management approach, a communication plan, and more. It’s a working document for the project team, and it gets built after the charter has been approved.
On top of that, you’ll have the project schedule, which is also informally called the plan, and will be built up from the key dates in the charter. Still with me?
Typically, a plan is something you can put together once and then use a copy of for most projects with some small tweaks, as your organization’s approach for change management isn’t going to change massively between projects.
Does every project need a charter?
I’m also asked if every project needs a charter, and honestly I don’t think they do. You do need something, however that documents what the project is and what stakeholders are expecting to happen. Whether that’s a charter, a one-pager on a slide, a PID, a terms of reference, a quick brief on email or some other kind of project intake form, is up to you.
I would lean towards having a charter/PID for every project, but that’s just me. I’m pretty sure most PMO professionals would agree!
Frequently Asked Questions
What is the purpose of a project charter?
How long should a project charter be?
Who writes the project charter: the project manager or the sponsor?
In most cases, the project manager (i.e. you) drafts the charter with input from key stakeholders. The project sponsor reviews and approves it. The sponsor’s approval is what gives the charter its authority, but the project manager typically does the heavy lifting in terms of actually writing it.
That’s why it’s useful to start from a template or use one from a different project!
What is the difference between a project charter and a project scope statement?
If you already have a scope statement, just link to it instead of replicating it.
Can a project charter be changed once it is approved?
If the project scope, objectives, or key constraints change significantly, the charter should be updated. Treat it as a living document but don’t be changing it every week.
What happens if you start a project without a charter?
It also means there is nothing to document what you said constraints, dependencies and assumptions would be, so if something turns out to be not as you expect and the plan needs to change, it makes those conversations harder.
It’s a risky-ish move, but most execs would prefer that the work gets done rather than you spend your time on project documentation, so it’s a balance!
Is a project charter the same as a business case?
This article first appeared on Rebel’s Guide to Project Management and can be read here: How to write a project charter that gets stakeholder buy-in
