Hi there!
We created this Toolkit to simplify the process of creating a project charter document. We noticed that finding a good template, samples, and guide gathered in one source is hard. This Toolkit will help you find all the information in a cozy place.
If you are familiar with a project charter, go straight to templates and samples. If not, please scroll down to the guide section or video tutorials, where you find all the information you might need.
Enjoy!
This guide covers everything you need to know about the project charter. It is based on the template you can download here.
A project charter is a central document that defines the fundamental information about a project and is used to authorize it.
In a nutshell, a charter provides a picture of where you are going, why you are going there, who will be impacted, the main riss involved, and who is going to help you. It's crucial that the charter not only establishes basic information but also that it reflects the key stakeholders' common vision.
A project charter is typically created early in the project lifecycle, hopefully before the project is staffed and the business is running for delivery date. It is usually created collaboratively as a team and shared with stakeholders upon completion. In most cases, the charter is signed off for approval by project sponsors.
It's some kind of must-have document for any project.
The project charter is a document. There is no universal formula for a project charter. It can either brief or as long as 50 pages. But the more detailed it is the less chance that someone will actually read it. We believe that you do want your project charter to be read, so try to keep your project charter to a maximum of 5 pages. Ideally, it should be 1-2 pages.
Usually, project charters are text documents or google documents, although it can be a presentation, too. Take a look at a template or sample sections to see how a real charter looks.
Absolutely yes. Here are two killer benefits supporting why you must use project charters:
We suggest using the following sections:
1. Background
Give a straightforward answer to the question: 'why are you doing this project?'
Describe what problem it solves and what gave you the opportunity to make your idea a
reality. Try to articulate this section as if you're trying to hire a complete stranger
and you need to briefly explain the basic elements of your project.
2. Goals
Describe what goals you are going to achieve and when. It's crucial that your goals be specific and measurable (SMART). For example, "Significantly increase customer satisfaction level" is a bad goal because it's up to interpretation as to whether or not you've met it. However, "Increase retention rate from 5% till 10% by the end of 2015" is a good one.
It's essential that upon reading over your goals you clearly understand what you consider to be a successful part of your project and how you measure that.
3. Scope
What product, service, or result do you expect to get from this project? What actions will your team take to undertake the project?
It's also important to mention what your team will not do. For example, your end product is "a new website for a public library". You will develop and design it. But will you test it, set it up or fill this site with content? Try to make it absolutely clear what you are going to do and what you aren't. It helps you eliminate any confusion in the future.
4. Key Stakeholders
Make a list of people involved in your project. Some sort of who is who in it: PM, sponsor, client, and team members. If you don't know the names of individuals, list the title of the required position and department.
5. Project Milestones
Establish significant dates of your project: start date, end date, invoicing dates. It's important to understand that these dates are merely guesses. When writing the charter you don't have firm dates yet.
6. Project Budget
Make a note of the main project expenses. Treat them as rough estimations. Try to make note of non-recurring and monthly recurring costs separately.
7. Constraints, Assumptions, Risks and Dependencies.
Constraints:
These are the limiting factors that impact your project in a particular way. For example, when developing a new website the number of available programmers and technical limitations (platform, coding language, etc.) must be considered.
Assumptions:
Factors that you are relying on in order to succeed in your project. These factors are considered to be true but without including proof. A few assumptions: contractors will be paid without delay and your client will test the website.
Risks:
Anything that might get in the way of you and your team when you're trying to accomplish your project goals. Make sure to carefully weigh in on this point and clearly articulate the risks. A few examples:
Dependencies:
An absolutely essential part of the project. For a new website, it'd be client-driven content.
Don't do it alone. The best way to create a charter is to do it with your entire team by having a project charter session. Get everyone together and cover the main points in the document. You may notice that many participants will have different perspectives on the project and that's excellent. You'll reach a consensus during the discussion.
But keep in mind that making a project charter is an interactive process. After the project charter session writes a rough draft and sends it to all project participants. Gather their feedback and update the document. Discuss and finalize the document one more time and have the project sponsor sign it once it's been approved.
Here's a free project charter template you might use with this guide. If you think you need more information – browse the video tutorials and check out articles in the additional information section.
from Harry Hall at PM South
If you think that something is missed here, please let us know by dropping us an email at nick@casual.pm
If you find this toolkit helpful – please spread the word!
You may also check out other toolkits crafted by Casual: Project coordinator, Project proposal and Project brief.