Section Breakdown
Executive 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 paragraph.
Click here for an example...
Signatory Approval
Authorization for the project is confirmed via 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.
Click 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.
Business Context
This is the section where the project team details their business case for the project; also known as the "why's" of the project. Ensure that this section can be understood by key decision-makers around the university.
Click 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.
Project Deliverables
A project deliverable is a product, service, or process that is created by the project. A project may have multiple deliverables.
Project scope is an overview of the boundaries of the project's deliverables. In other words, it is what deliverables the project will or will not create.
In this section, include 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.
Click here for additional details...
This section should include:
- 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.
High-Level 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.
Click 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.
Note: The timeline should not be finalized until after the project is prioritized and scheduled as part of the project intake process.
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 sponsor, an owner, and at least 1 project team member.
Click 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.
- Sponsor - Also referred to as the "executive sponsor", this individual is someone who has the financial and decision-making authority to approve the 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.
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.).
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.
Click 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.
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, document any significant risks that exist for the project. Each risk should be accompanied by a mitigation strategy.
Click 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, HIPAA, 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.