Under Construction

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

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.

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.

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.

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.

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.

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.