A project charter is a short-ish document that describes your project and gives the project team the authority to proceed with the work. It takes the information from the business case or proposal and turns it into an actionable first plan that gives everyone clarity about what’s going to happen and why.
The exact length of the document depends on what the project is and how much you need to write to adequately explain why the project is being done and what is being delivered.
What goes into a Project Charter?
The project charter serves to document some basic things about the project so everyone has a common understanding of the work that is about to begin.
‘Charter’ is a term used to outline any type of activity, for example to explain what a team does. You may also have a charter for your PMO that covers the scope of that team’s work.
It’s part of the formal activity of planning a project, and we cover chartering in more detail in our Project Management Fundamentals training course. As an introduction, here’s an overview of the main components of a project charter.
1. Project background
Include a few paragraphs about what the project is for and what problem it is trying to solve. You can explain the reasons why the project has been initiated although there is a separate opportunity to go deeper into benefits later, so keep this section to the context and business drivers for the project.
2. Project objectives
Include a list of the project objectives. These will probably be listed in the business case if you have one. Some projects don’t kick off with a business case, so if you haven’t got anything else to go on, talk to the project sponsor.
The point of including objectives here is to make sure everyone has clarity on what it is the project is setting out to achieve. You can include the high-level vision as well as the detailed list of objectives.
You can also include constraints that will shape the project’s scope.
3. Benefits
Write a paragraph about the general benefits you are expecting to deliver as part of the project. Add in as much detail as you have, or include a reference to a document where readers can find out more about expected benefits.
It’s also useful to include a bullet-point list of benefits, because you can then refer back to that at the end of the project to see how many were achieved.
Tip: You can use a lot of the project charter in your project closure document as that file compares what you said you would do (the charter) to what you actually delivered.
4. Stakeholders
The stakeholder section is normally a substantial part of the project charter. You’ll want to list all the core project roles including the types of people and expertise required for the project team, the customer or client representative, the governance framework and who is involved with that, and any other key decision-making stakeholders.
At this point in the project you might not know the names of the people involved, so it’s fine to stick to roles. However, if you do have names – and you would, if this was an approved project for a client as you would know who the client is – you can include them in the document.
5. Initial risks and issues
The business case or any conversations to this point may have highlighted risks and issues that affect the project. You can include a brief list of these in the project charter.
It doesn’t take long for an experienced project team to come up with dozens of risks so prioritize what is included in the document. If your risk log is already coming together as you capture information about the project, pick out the top five risks to highlight in the charter, and refer readers to your document repository or online project management tools where they can see the rest of the risks identified to date.
You can do the same with issues. Include a few of the most important issues for the stakeholder community to be aware of, and then link to where people can find more information and the rest of the lower priority issues.
This gives people confidence that you’re on top of risks and issues and have set up the project for success even at this early stage.
6. Initial budget
You won’t have a lot of detailed information about the budget yet, but you might have enough information to include a general section stating where the budget will come from, how much overall it’s going to be and so on. The detailed breakdown will fall out of your detailed planning and estimating for each task.
Save yourself some time and pull the budget information from the business case. it’s unlikely anything has changed since the business case was approved, so if there is one, use the financial information from that to populate the charter’s budget section.
7. Initial timeline
Again, you won’t have a detailed project schedule at this point, but you should include key dates and milestones where you know them.
In a perfect world, you’d do all the estimating and planning before you told anyone any firm project delivery dates. However, in our experience, projects nearly always come with some kind of expectations from the sponsor or senior executive team relating to when the work will be completed. Clients often have hard deadlines for implementation, and launch dates might be tied into other business events like a new season or the financial year. As a result, you probably do have some time-driven information you can include in the project charter.
List out key milestones or other fixed dates that you intend to include in your detailed project schedule once it is created.
The project charter is a kind of contract between the sponsor and project team, defining what work is going to happen and therefore what success for the project will look like in terms of the resulting deliverables. That’s why it’s important to get it right, so you start the project with everyone having the same understanding of next steps for the work.
Read next: 5 Best Practices for Project Initiation