The Basics
The project charter is a document that is created by the project team in partnership with one another. As a foundational document to every project, the charter sets the table for a collaborative project from the onset. When creating the project charter, keep the following in mind:
- Each section of the project charter should be written to be as detailed as possible while retaining readability.
- The charter is a reference document that should be easy to read, but packs enough information to guide the trajectory of the project as a whole.
- Avoid diving into the fine details of a project. The charter is meant to be a high or mid-level overview.
- The document is meant to be iterative: create the document during the beginning of the project. But as variables change and new information is available, update it. Don't spend too much time on it at the beginning.
- Use the project charter as a reference document when making key decisions during project implementation.
Section Breakdown
Summary
The project charter begins with an executive summary of the project. Briefly explain the primary cause(s) of the project, the goal(s) of the project, and timeline. Most summaries should be limited to 1-2 paragraphs, but some larger projects may contain an executive summary that can be up to 1 page in length.
Expand | ||
---|---|---|
| ||
Under Construction |
Signatory Approval
The project charter contains signatures from the project sponsor, project owner, and the director-level supervisors of SPU employees on the project team. The signees have read and agreed to the project details outlined in the document and they commit the resources necessary to complete the project from their respective areas.
Expand | ||
---|---|---|
| ||
|
Note: Projects should not proceed as planned without a complete set of signatures from the appropriate parties. These signatures may be gathered after the project charter is completed at the conclusion of the Project Intake Process.
Context & Case
This is the section where the project team details their case for why the project should be executed and prioritized; also known as the "why's" of the project. Ensure that this section can be understood by key decision-makers around the university.
Expand | ||
---|---|---|
| ||
Ask the following questions to get an idea of what to write in this section:
|
Expand | ||
---|---|---|
| ||
Under Construction |
Timeline
Provide an overviewTimeline
Provide an overview of the project's estimated or goal timeline. Include any timeline considerations caused by external factors like regulatory changes. The timeline in this section should be an educated estimate, as they can and will most likely change after the project is started. Any amendments should be discussed and approved by the entire project team.
Expand | ||
---|---|---|
| ||
This section should include:
| ||
Expand | ||
title | Click here for an example.
| .Under Construction |
Note:The timeline should not be finalized until after the project is prioritized and scheduled as part of the project intake process.
Results
Outline the expected results of the project. Include the project's goals, what is in the project's scope, what is out of the project's scope, and any scope-related items that will need a decision later on. This is the start of the project planning process, which helps map out the "path" of the project throughout implementation. This section will likely be the largest in most project charters.
Expand | ||
---|---|---|
| ||
This section should include:
| ||
Expand | ||
| ||
Under Construction |
Project Team
List every person who will be directly involved with the project and their roles on the project team. At a minimum, each project should have a project sponsor, a project owner, and at least 1 project team member.
Expand | ||
---|---|---|
| ||
The following is a list of common of project roles. Depending on the project, some of these roles may not be used or additional roles may be needed. A person in the project team may serve as multiple roles and multiple team members could be assigned to the same role.
Some roles may not have a clear assignee while the project is being defined. For example, a CIS Developer may be involved in a project, but it is still unknown which developer will be involved. In these cases, list the role required and as much information as possible regarding the workload that is required from that role. With this information, the supervisor of that role is committing the resources required for this project when he or she signs the project charter. |
Expand | ||
---|---|---|
| ||
Under Construction |
Stakeholders
A stakeholder is any personStakeholders
A stakeholder is any person or group who is affected by the project. For each person or group, write a brief description of how they will be affected by his project. Effects of the project can be short term (costs, disruptions, etc) or long-term (benefits, process changes, etc.).
title | Click here for an example... |
---|
Costs
A project's costs include labor, time, expertise, and more. The length and level of detail in this section will depend on the project type and how much advanced work may or may not have been done on it. While the university as a whole pays for projects, it's important to note which departments (CIS or otherwise) will bear individual costs so that information is readily available for reference later on. If the data is available, try to attach dollar or time values to each cost.
Expand | ||
---|---|---|
| ||
The type of costs that can be listed in this section include:
| ||
Expand | ||
title | Click here for an example..
| |
Under Construction | ||
Risks
A risk is anything that can increase the cost of the project and potentially compromise the success of a project. It's important to think about project risks ahead of time so team members can work on developing plans to mitigate these risks. Risks can come in all shapes and sizes, so work with the CIS Business Systems Analyst or Project Manager to find risks and develop mitigation strategies. In this section, each risk should be accompanied by the level of severity if the risk were to occur and a mitigation strategy if the risk manifested.
Expand | ||
---|---|---|
| ||
Some types of risks common to projects include:
|
Expand | ||
---|---|---|
| ||
Under Construction |
Project Charter Types
The following sample project charter documents are real projects that CIS have been involved in and have managed. The samples are pulled from a variety of project types and sizes. Note that all project charters can be modified; sections can be removed or added based on the size/scope of the project. The templates are helpful as starting points when creating a new project charter.
Full Charter
The full project charter contains all of the sections listed above. This project charter is best used for medium or large projects and will require the most detail. The full charter will typically take 3+ pages and can reach 10+ pages for really large or complex projects.
Lightweight Charter
This modified version of the charter is designed for small or quick projects. The charter focuses on the most important details for a project: the scope (goals), timeline, and who is involved in the project. While all project charters can be modified depending on the project scope, the lightweight version is a helpful starting point for smaller projects.
|
Project Charter Examples
The following sample project charter documents are real projects that CIS have been involved in and have managed. The samples are pulled from a variety of project types and sizes. Note that all project charters can be modified; sections can be removed or added based on the size/scope of the project. The templates are helpful as starting points when creating a new project charter.
Attachments | ||
---|---|---|
|