Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Panel
borderWidth0

Table of Contents

Table of Contents
excludeTable of Contents




Excerpt

A project charter is a pillar document that contains the high-level details of a project. By putting key project details in writing, the project charter serves the following purposes:

  • Helps the project team remain on the same page.
  • Communicates high-level details to key stakeholders and interested parties.
  • Assists with the project prioritization process.

Once an IT project request has been created, a CIS staff member will work with the project's sponsor and stakeholders to draft the project charter.

This article outlines each section of the project charter and provides examples to aid in the creation of the document. There are three types of project charters, one for medium/large projects, a lightweight charter for small projects, and a research charter for research or product discovery projectsThe full and lightweight project charter templates bellow illustrate how the charter can be modified to contain only the information pertinent to a project.


Project Charter Templates


Panel
borderColor#d3d3d3
bgColor#d3d3d3
titleBGColor#d3d3d3




Image Removed

Panel
borderColor#d3d3d3
bgColor#d3d3d3
titleBGColor#d3d3d3


Panel
borderColor#d3d3d3
bgColor#d3d3d3
titleBGColor#d3d3d3



If you have not If you have not submitted a project proposal, click here to fill out a short project request form.

To check the status of your project proposal, go to the Project Roadmap or the Project Backlog; or, contact a CIS BSA or PM



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
titleClick here for an example...

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
titleClick here for additional details...
  • Project Sponsor - Sometimes referred to as the executive sponsor, this person is the head of an area (department or VP area) who places their executive seal of approval on the project. This individual does not need to be part of the project team.
  • Project Owner - This person is the head of the team or department who will "own" the outcome of the project. They will take the product, service, or process that the project will create or amend and take ownership of ongoing work beyond the project. This individual can inform, assist, or be fully part of the project team.
  • Director/Team Leads - The other signees of the document are the leads or directors of the teams represented in the project team. These individuals may not be part of the project team, but they commit the employees and resources they oversee to the completion of the project.


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
titleClick here for additional details...

Ask the following questions to get an idea of what to write in this section:

  • Why is this project needed by the SPU community?
    List and explain the need for this project at SPU. Is there a business process that can be more efficient? Is there a financial savings potential that can be realized with this project? Are there academic or pedagogical needs for this project? 
  • Are there problems that will be eradicated with this project?
    Problems can be directly related to the needs of the university, but they can also be strategic as well. Include any potential problem that can arise if the project is not done. 
  • How does this project align with the university's mission and/or strategic initiatives?
    Organizationally, projects should be driven by our mission and our strategic goals as defined by University leadership. Even if the effect is minor, most projects should align with SPU's goals. 
  • Are there any external factors that is driving this project?
    Regulatory changes or newer versions of cloud applications (Banner, Canvas, etc.) could force the university to take on certain projects.



Expand
titleClick here for an example...

Under Construction

Timeline

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
titleClick here for additional details...

This section should include:

  • Goal start date - When does the team want to begin this project?
  • Goal launch date - When is the team's target for launching the new system, service, or process? For some projects, the launch date can be in the middle (or towards the end) or a project. 
  • Goal close date - When does the team expect the project to be completed? This date can be after the launch date. For many projects, this date also signals the transition from a project to ongoing maintenance & support. 
  • Timeline Considerations - Include any timeline considerations caused by external factors like regulatory changes.
  • (Optional) Timeline - If any portion of the overall project's timeline is available, put it in this section.



Expand
titleClick 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
titleClick here for additional details...

This section should include:

  • What are the goals for this project?
    Define the overarching goal(s) for the project in this section. Outlining the project's goals illustrate the purpose of this project and how or why this project can benefit the SPU community.
  • What is in the project's scope?
    Scope defines what the team will do as part of this project. If the project's scope needs to change as it progresses, the project team can meet to discuss the possible changes and update the charter as necessary. 
  • What is out of scope?
    Defining what is out of the project's scope provides a boundary which helps prevent scope creep from bloating the project into a larger and more resource-intensive endeavor than originally planned.
  • Are there any scope-related items that haven't been decided yet?
    Be sure to include any scope-related decision points. If a decision has not been made on a scope-related aspect of a project, include it in this section. Knowing that decisions on scope will need to be made later on, and what the potential impacts are, will help the project team in their decision-making process.
  • What are the deliverables and/or milestones of this project?
    Deliverables are the tangible results of a project while milestones are significant markers in a project's progress. Each deliverable is a component of the project's end-product and the sum of deliverables should meet the project's defined goals and scope. Milestones are markers that spotlight key moments during a project. Examples of deliverables include the product/service that is being implemented, documentation for the proper operation or support of the product/service, training outcomes for staff, or more. 



Expand
titleClick here for an example...

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
titleClick here for examples of project roles...

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.

  • Project Sponsor - Also referred to as the "executive sponsor", this individual is someone who has the financial and decision-making authority to approve the project.
  • Project Owner - The project owner is someone who will "own" the final product of the project. 
  • Subject-Matter Expert - This role can encompass any member who is an expert at the subject the project tackles. Subject-matter experts may also be asked to write documentation, train functional users, or provide ongoing support once the project is completed.
  • Project Manager - The individual who focuses on the operational aspects of the project.
  • Business Analyst - Analyzes processes and procedures prudent to the project's subject and provides recommendations of changes or improvements.
  • Developer - Projects involving CIS may require a developer. They write the functional code required in project deliverables.
  • Administrator - The person who will administrate the new system or process that is being implemented by the project.

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
titleClick here for an example...

Under Construction

Stakeholders

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.). 

Expand
titleClick here for an example...

Under Construction

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
titleClick here for additional details...

The type of costs that can be listed in this section include:

  • Cost of the Product(s) or Service(s) Purchased and Implemented
    If the project involved implementation of a new product or service, the cost for the purchase of said product or service should be factored into the costs.
  • Staff Involvement at SPU
    Include the level of staff involvement in the project. This cost can be an estimate based on how many staff members at SPU will be working on the project.
  • Ongoing Costs
    Include any ongoing costs that will be present beyond the completion of the project. Typically, this includes licensing, maintenance, and support. Maintenance and support costs could include internal (support from CIS or other departments) and external (support from the vendor).
  • Is there a cost to not doing this project?
    There can sometimes be a cost to not doing the project. This can be attached to an external factor, or the cost of continuing to use a current system or process.



Expand
titleClick 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
titleClick here for additional details...

Some types of risks common to projects include:

  • Financial
    An uncertain or lack of funding for the project is the most common financial risk. This risk can apply to the project itself or any potential ongoing support, maintenance, or licensing costs beyond the project.
  • Legal & Regulatory
    Legal risk can come in the form of uncertainty surrounding a project's compliance among the many laws SPU must adhere to (FERPA, HIPPA, etc.). A changing rules and regulation environment can also add risk to a project. A common occurrence of this risk is tied to timeline: a project designed to meet an upcoming regulatory change has the risk of non-compliance if the project isn't completed on time.
  • Staff Schedules & Expertise
    A project requires the coordination of multiple staff with varying areas of expertise from across departments or even organizations. The availability of key project team members is important and any upcoming schedule conflicts with project team members pose a risk to the success of the project.
  • Vendor
    Many new system implementation projects involve a vendor of some kind. Most vendors offer their services to assist with implementation, technical integration, and more. While this can reduce the cost of the project, it can also introduce risks tied to the vendor's schedule, performance, or even expertise.



Expand
titleClick here for an example...

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.

Research Charter

The research project charter should only be used for research projects. A research project is a specific kind of project where the team will look to the market to find, test, and ultimately procure a system, product, or service that will meet a specific set of needs. This type of project charter is slimmed to help the team focus solely on the needs they expect to fulfill, the timeline of the project, and any potential budget that may limit the procurement process. Once a research project is complete, then a separate project (with a separate project charter) should be initiated for the implementation of the chosen system, product, or service.