A project charter formally outlines a project in an organization. It covers the scope of what the project will achieve, as well as the people involved, milestones, budget, and possible risks. Many organizations consider this document as an essential part of project planning—although it's not the same thing as a project plan because it doesn't get into the details of individual tasks within the project.
An effective project charter may do the following:
- Outline the project scope and objectives
- Ensure project sponsors and all stakeholders are in alignment on a project
- Be a clear, single reference for all involved in a project
- Help project sponsors get approval of stakeholders when buy-in is still needed
Project charters can vary depending on type of project and organization, but the basic elements usually include the project background, stakeholders, budget, risks, milestones,
The first section of a project charter will offer basic details such as the name of the project, the project sponsors and manager, and the date the document was prepared.
This section will also explain the purpose of the project. You can refer to a business case or the contract that is driving the project or simply spell out why it’s important to the organization. It should address why this this project was started: Does it solve a problem for the business? Does it address a new trend? Does it support the company's overall strategic direction?
This will outline the people and departments that are involved in the project. It will not get into the nitty gritty of each task in the project, but instead will acknowledge general roles and involvement. For example, you may list the main project sponsors, lead project managers, team members, any outsourced workers or partners, and clients, if applicable. Larger projects may not list every single person involved, but instead might note the department lead for a certain aspect of a project.
Here, you're answering the question, “How will we know when we’ve finished?” It includes what you expect the project to deliver and how you will know if you’ve gotten there. For example, in a project to launch a time recording system for all departments, the objective could be: “All teams will be using the timesheet system by the end of the year.”
Also, make a note of who is going to be responsible for agreeing that you have reached this objective. It avoids any problems at the end of the project where suddenly no one is prepared to sign the work off as complete.
At this point you might not have all the details about the project tasks, so you can’t put a full and detailed project budget together. However, you can note down any budget constraints or the high-level estimation of expected costs.
All projects have risks. This section of the project charter forms the early version of your project risk log. Document any risks that you know about at this point so that the management team can see what might affect the project going forward.
If you know the high-level milestones include them in the project charter in this section. At the very least, you should include estimated project start and end dates. You should also list drop-dead dates or anything specified in the contracts you are working with. You can transfer these milestones to your Gantt chart later when you come to put together a more detailed project plan.
Project Manager Authority Levels
Unless it is clear and documented somewhere else, it’s worth including a section in the charter about what the project manager can do without getting further sign-off from someone more senior. It generally relates to what tolerance levels have been set on the budget and timescales and would be expressed like this: “Project manager has a 10% tolerance on budget and a 5% tolerance on schedule. Any deviation above these approved limits must be signed off by the project sponsor.”
You can extend this section to specify what, if any, authority the project manager has about hiring and firing staff from the project team.
Approving the Project Charter
The final section of the project charter is the approvals section. The project manager and project sponsor (or the person who kicked off the work, if a longer-term sponsor has yet to be appointed) should sign and date the document. Today, that’s likely to be via email, so keep a copy of the email authorization in your project files in case you need to refer back to it.