Your project has been approved and you are ready to write the Charter. Here’s what to include, along with examples.
The Project Charter is the document that many firms use as the official beginning of the work. It can be any format but it’s usually a document. We talk about it as providing the mandate for the work to begin and giving the project manager the authority to get started.
The Charter is pretty much the next step after the business case and project approval, and you might have something similar in your organization, like a project initiation document or project kick-off document. It doesn’t really matter what you call it – what’s important is what is inside.
Given that Charters can be long or short, detailed or basic, the most important thing to remember is that it should be fit for purpose. You don’t need a giant document for a project that is to organize a staff family day next summer. However, you might want more detail if your company is investing multi-millions into a new product that’s going to revolutionize your industry. As with all things in project management, tailoring is key.
Having said that, there are some basic things that any Charter should include, whatever the project that is being described. Below we look at the critical items you should make sure are in the document.
Table of content:
1. Project background
2. What work is needed
3. High-level schedule
4. Risks and issues
5. Resource allocation
Include a quick overview of the project context and explain why the project is required. This would normally be something you can lift from the business case as that would have a lot of detail about why it is worth investing in the work.
However, here in the real world, we know that many projects don’t have businesses cases, especially if there is no large sum of money being requested. If your boss has simply asked you to get on with the project, then you will have to write this section from scratch. A few sentences might be enough.
This project provides the infrastructure required to upgrade our server estate. Our current servers are end of life and in order to ensure all our IT software and platforms can adequately run over the next 5 years, we need to replace the hardware they run on, based on our IT provider’s recommendations.
In agile projects, you’ll create a backlog of user stories that set out the project requirements. In a more predictive project, you may have some requirements workshops or scoping sessions or work with a business analyst to understand what is in scope.
However, don’t worry if you don’t have too much detail at this point. The planning work hasn’t yet been done so you may only have high-level information about what you want to achieve with the project.
This project will replace 10 servers in our data warehouse with new state-of-the-art equipment and upgrade a further 15 servers with new memory. We will also replace 200 meters of cabling and upgrade the air conditioning unit in the server room to better cope with the load. This work must be completed during the holiday period at the end of the year as it requires downtime to all IT systems and this is the time that downtime will be least disruptive to the business.
As we’ve said, the project planning work is not yet complete, so you won’t have an idea of how long the work will take. If you are using sprints or agile iterations, you may already have some idea of how many you can commit to based on the backlog. Or you may have fixed delivery dates and the project work needs to be compressed to fit into that timeline.
The Charter should have some information about the timeline because it helps set expectations for the project customers – whether they are internal or external. If people don’t see any schedule information they may get the wrong idea about when the work can be completed. Include a high-level timeline diagram, Gantt chart, or milestone list if you have enough information at this point. If you have made any assumptions about what (or who) will be available to help ensure those initial dates are met, make sure they are documented too.
The server upgrade project will be completed in three phases: Installation of new equipment, decommissioning of old equipment, and testing. Some of these phases will overlap. The planning work will take 3 weeks and after that, a detailed timeline will be available outlining the procurement and build of the new kit. The goal is to have the final prep work completed on 20 December in anticipation of completing the installation and upgrades over the year-end period. A milestone list can be found in the appendix to this document.
What might go wrong with this project? The Charter is a good place to help people see what is being committed to and how that might unfold – including all the things that might get in the way of the work being completed in a straightforward manner. There are always things that might not work out quite as planned, so it’s best to highlight these now so everyone is aware.
The business case may have included a list of key risks and issues that you can simply copy and paste (with edits so the list is updated). Alternatively, make some up from what you know of the work and your conversations with the team. The project sponsor may have concerns that should be addressed in this section.
If there genuinely aren’t any that warrant noting down, say that – on a small project, or work that has been done many times, you might not have anything specific to add here. Instead, let people know that you’ll be keeping a risk log and dealing with problems as they come up. That gives the team confidence that you are aware there might be something to look into as the project progresses.
The following risks are being actively managed:
- There is a risk that the cost of new servers increases between now and the time we are able to place the order.
- There is a risk that the team will not be available to work over the year-end period due to illness or planned vacations.
- There is a risk that the downtime to the business causes some disruption.
The risk management plans for these risks and any new risks identified during the project will be managed in the risk log.
The Charter is all about expectation setting and it’s important to review who is needed to help out on the project so you can set expectations about the time they are required for. Often, projects get approved without any real consideration of whether anyone is actually available to work on them. Then the project gets added to your workload. Ideally, it should be prioritized in the portfolio so people who are assigned to the work understand the relative priority against the other projects. Then they can make better decisions about where to spend their time, and what to work on first.
That’s why it’s relevant to include resource assignments in the Charter where you can. If you don’t yet know the names of people who will be involved, you can note down their job roles and then speak to the relevant team leaders to find available people. Don’t forget to include yourself in the resource overview! Include the list of names (or roles) and hours required in a table.
This project requires:
- 1 FTE platform engineer
- 1 FTE project manager
- 2 FTE hardware engineers
- 0.3 FTE procurement executive
It will also require some staff to work unsociable hours during the holiday period and the project will budget overtime payments in addition to normal salary to accommodate this.
The Charter is a great document for getting everyone on the same page, but you should only spend time on it in proportion to the complexity of the project. Don’t spend hours crafting the perfect document only for your project to take a few weeks. Tailor what goes in and how detailed it is to the type of work you are doing, and use the above pointers as a guide to how best to bring everyone together with a common understanding of the work. Now you are ready to get started!