The Project Charter is a formal document to authorize the project and give the project manager the authority to spend the project budget. It is required for UIT-managed projects. The Project Charter defines the project's business case, scope, goals, metrics of project success, major milestones, high-level risks, and identified key stakeholders and the project team members including the roles and responsibilities of each.
Details
The UIT Practice Area Director and/or UIT Project Manager typically drive the charter process, being sure to get input from all stakeholders during the elicitation and review process. Note: For all P2P and Core Financials projects, FMS will drive step 5, not the UIT Project Manager.
1
Step 1: Elicit
Gather project charter details and update the following sections in the Project Charter template:
- Section 1: Problem Statement, to be completed by business
- Section 2: Solution section, to be completed by UIT
- Remaining sections: to be completed in collaboration
2
Step 2: Analyze
Analyze all inputs and make sure the impacts listed below have been taken into consideration while preparing the charter. The points below are not intended to be a replacement for the Business Requirements Document, but rather a mental checklist for the charter so that you have included all the right stakeholders and, at a high level, have touched upon all the usual topics of our projects.
- Business process improvements
- Reporting and BI
- Authority and security
- Interfaces or impacts to other systems and departments
- Infrastructure and environment needs
- Outside vendor needs
- Integration with outside systems, such as systems outside of UIT or Stanford
- Campus readiness
- Expected support impacts
- Baseline data, if it exists and is not part of the charter itself
3
Step 3: Document
Draft the detailed charter, also known as Funding Project Charter. Make sure all financials foot, i.e., totals add up correctly and Excel formula ranges are accurate. Keep detailed back-up data such as spreadsheets.
4a
Step 4a: Tier 1 Review, Core Team Managers
Route charter to UIT and business for feedback. Allow a minimum of one week for this review; 24-hour notice is unacceptable! Primary driver/coordinator for review is the Project Manager.
List of UIT Functional areas to route to:
- Practice Area Director
- Practice Area Director(s) of other areas where impacts are cited
- Project Manager
- PMO, for tracking purposes
List of business functional areas to route to:
- Core stakeholders of sponsoring department
- Business owner(s)
- Supporting or impacted business owner(s) such as FMCS, OSR, etc.
Incorporate feedback before routing to next step.
4b
Step 4b: Tier 2 Review, Business Client and UIT Executives
Route charter to UIT and business stakeholder management for feedback. Primary driver/coordinator for review is the Project Manager.
Management to route to:
- Applicable UIT AVP(s)
- Business Client Executive(s) as applicable
Incorporate feedback before routing to next step.
5
Step 5: Present for CFO Approval
For SGG and Business Affairs Initiatives Projects Only: After everyone has provided their input and the charter version is final, schedule a meeting with Randy Livingston via his assistant, Ruby Stanfield. Be sure Noel Hirst and Shachi Chopra (or other assigned UIT Financial Analyst) are invited. Route charter to the CFO in advance of presentation.
Attendees of the presentation:
- Project manager
- UIT Director in whose practice area the project is being run
- Affected UIT AVP(s)
- Business Owner or Sponsor
- Business Client Executive
The Project Manager may start the presentation, but the Business Owner typically does the bulk of the talking. Be sure you have practiced the presentation ahead of time and primary speakers know what they need to say. Anticipate questions such as ROI (return-on-investment), metrics showing value and support for the project, solid business problem and solution, number of users impacted or affected by the project, streamlining of process that may be achieved by project, etc. Be sure to bring the resource plan to the presentation.
6
Step 6: File
Once the charter has been fully signed off, upload the final document to the "UIT PMO Project Financials" Google Team Drive. Do not post copies of the charter with financials anywhere else, due to the sometimes sensitive nature of that section. If you need to post a copy of the charter somewhere more accessible for your project team, post a copy with redacted financial data on your project's Google Team Drive.
This section is typically written by the Business Owner/Business SME/Staff.
2.1: Current Situation & Problem Statement
"Current Situation" means the current state of a business process, system, or both. It provides background and context in support of the Problem Statement.
Questions to Answer:
- What is the current business and/or system process?
- Who are the parties involved in the current process?
- What are the pain points and drivers for action?
- Are there and compliance, security, or other risks that might be mitigated?
"Problem Statement" means the problem that the proposed project seeks to solve.
Questions to Answer:
- What is the problem that requires an automated solution, i.e., purpose of project?
- Why is this problem a priority for consideration? Include connections to strategic or technology directions and/or roadmap.
- Which service or services would this project support?
- How does the project contribute to increased strategic value for the university?
2.2: Effects of Not Doing This Project
Use clear, business-centric language to articulate the effect(s). It is helpful to look at the KPIs and reverse the information.
Questions to Answer:
- What manual procedures and business processes would remain? If you can quantify this with metrics, the argument will be more powerful.
- How would employee effectiveness or productivity be reduced?
This section is written by typically written by the Business Owner/Business SME/Staff with input from UIT.
These should be SMART goals or objectives i.e. Specific, Measurable, Achievable, Relevant, Time Bound or KPI’s, Key Performance Indicators, that allow the University to measure the operational efficiency, improved accuracy and/or effectiveness because of this project. The Business owners should review the goals to help determine how to measure KPI’s. An example is, “Decrease Average Turnaround Time per Invoice from 30 days to two weeks by EOY 2010.” The KPI is “Decrease Turnaround Time per Invoice.” If KPI’s cannot be defined then a list of success factors and/or benefits should be described in this section. This will be the list of measures that can be evaluated at project completion to determine if the project value was realized.
This section is typically written jointly by the Business Owner/Business SME/Staff plus UIT.
4.1: Solution Overview & Impact to Community
This subsection should address the improved operations, efficiencies, cost savings and/or changes that will result from the proposed project as well as the high-level solution. This section will help to alert Central Businesses and Distributed Users as to the extent and kinds of changes that will take place and should foster an understanding of upcoming change management necessary. Make reference to findings that resulted from the execution of a Discovery/Assessment if applicable. Please be as specific as possible with respect to identification of the impacted user groups and the timing and nature of the change to their processes. This subsection should be written last, or at least after you know more about the solution.It is recommended that you include a context diagram, as this will be helpful for understanding the solution in context. Some examples appear below.
Questions to Answer regarding "Solution Overview":
- Will the project be organized into phases? If so, this section should identify which phase the project refers to.
- Are there special technology considerations (custom versus off-the-shelf, commercial versus open source, SaaS, etc.)? If so, briefly identify what these are.
| Context Diagram Examples | ||
|---|---|---|
 |
 |
 |
Questions to Answer regarding "Impact to Community":
- What group or department is impacted by automated solution? Characterize their functional role: DFAs, faculty, PIs, etc.
- Who benefits from the investment?
- What manual procedures or processes would go away and be replaced by this solution?
- What training and campus outreach (email, websites, etc.) would be required, and what how frequent would communications be?
4.2: Impacts on or Touch Points with Other Systems
This section should identify the integrations with other systems inside and outside of UIT. Be sure to address impacts on upstream and/or downstream systems, identify whether an integration needs to be built or whether the impacted system is indirectly impacted. This section is important to complete as it may also affect other staff resources who may not be called out explicitly on the project.
Questions to Answer:
- What upstream/downstream systems might be impacted by this solution? If there is an impact:
- Is the impact intrusive (requires changes in impacted system) or not?
- Does the team supporting the system know about this solution and its potential impact?
- Does a custom integration need to be built? What is the anticipated frequency of when the integration will run? Is it live, on-demand, or scheduled?
- Will a new job have to be created? Will it fit in the desired processing window, i.e., is there enough time or will other jobs have to "move around" to accommodate the new job?
- Will the new solution be created in the same database as an existing system?
- How will database refresh schedules impact the new solution?
- Is there a supporting environment impact: DEV, INT, UAT?
This section is typically written jointly by the Business Owner/Business SME/Staff plus UIT.
5.1: Scope
This subsection should clearly define the scope of the solution. You may want to list In-Scope, Out-of-Scope items in a table or list, by category/functionality, if it helps with reader understanding. Watch out for too much detail; this document is not a Business Requirements Document (BRD). Only list In-Scope features that you have confidence can be delivered, as this section acts as a contractual punch list of items. Out-of-Scope is one of the most important things to include in a charter because it clearly lists what the solution will not do. Items that are defined here may arise as "Change Requests" later.
For "In-Scope," include features as follows:
- Front-end features in the user interface
- Data
- Reports
- Interfaces
- Jobs and their frequency (live, nightly, weekly, monthly, annually)
- New business procedures
- Backlog of enhancements (assuming that this charter represents an addition to an existing system)
Questions to Answer:
- What are key features?
"Out-of-Scope" commonly includes but is not limited to:
- Items that are part of another charter or phase
- Reports that will be delivered later
- Interactions or other functionality that cannot be completed until the system has stabilized
- Mobile application support (e.g. iOS, Android)
- Stanford non-supported web browsers or platforms
Questions to Answer:
- What will the solution not address or do, as planned by the charter document?
5.2: Deliverables
There are two types of deliverables: solution-based (functionality) and project (project plan, BRD, technical specs, etc.). This subsection refers to project deliverables. Listed below are a super set of deliverables from the standard Software Development Life Cycle (SDLC). For the project charter, choose those that are relevant to your project; do not attempt to include all deliverables from the list below in you charter. Focus on the most important and relevant ones.
|
|
|
5.3: Estimated Timeline
This subsection should provide a rationale or reason for the timeline, such as meeting compliance deadlines, award deadlines, staff availability, budget constraints, etc. It should also include dates and events in which delivery cannot be completed such as year-end, commencement, etc. Present just enough for the reader to get a sense of how the project will unfold; do no provide too much detail. This high-level schedule will act as a guide for the WBS. Example timelines are provided below.
Questions to Answer:
- Does the overall time frame seem reasonable given the scope? If no, why not?
- Is there enough time for planning, requirements, and design given the scope?
- Is there enough time for testing given the timeline for development? Does the ration of effort seem reasonable?
- Are phases overlapping too much? If so, why?
- Are cut-offs (exit criteria) clearly identified and doable?
- Is there enough time for the back-end activities of testing, UAT, and campus readiness?
- Can everything be delivered given the scope and resources that have been identified in the charter?
This section is typically written jointly by the Business Owner/Business SME/Staff plus UIT.
Create an org chart and paste the image into the project charter document. Some samples appear below.
| Org Chart Examples | |||
|---|---|---|---|
 |
 |
 |
 |
6.1: Roles & Responsibilities
This subsection outlines all team members' roles and responsibilities on the project. A sample set of roles and general responsibilities will soon be available on the PMO Website. When working with a new customer or a high-risk project, be sure to review everyone's role carefully. This chart will be the foundation for the RACI matrix. Instructions for and an example of the RACI matrix are available.
Here are some examples: Example 1, Example 2, and Example 3.
6.2: Stakeholders
This subsection lists all other important stakeholders on the project.
This section is typically written jointly by the Business Owner/Business SME/Staff plus UIT.
7.1: Estimated Project Costs
The table in this section provides all estimated costs to be born by the project and an explanation of how they will be funded is included in section 7.3, “Funding Source(s).” The most important costs to capture are the contractor staffing costs. When costing them, use real monthly hours (160, 172, 184) or real weekly numbers and do not round down to 160 or your budget will fall short. Be sure to leave enough time for contractor ramp-up time; don't have them start the day they need to be productive. Do not cost internal staffing; instead, represent the impact via FTEs (Full-Time Equivalents). For example, you estimate that three of your operating budget staff will be involved in the project. You represent this as three FTEs in the Operating Budget/Internal Impact column. Contact all department heads to ensure that you have all efforts/costs accounted for; do no assume you know everyone that needs to be involved and for how long. Standard budget contingency values are 10% for normal risk projects and 15% for medium or high risk projects.
7.2: Estimated Ongoing Support Costs
The table in this subsection provides all estimated support costs in USD ($) for the three years following project completion. These are not costs born by the project, and an explanation of how they will be funded should be provided above or below the table itself.
7.3: Funding Source
The table in this subsection identifies estimated costs to be born by the project by funding source(s); refer to the section 7.1 categories if that is helpful. Indicate whether the funding source is known, and if so, what the amount will be. Projects can have several funding sources; add rows for each source.
7.4: Flexibility Matrix & Contingencies
The flexibility matrix what constraints are flexible and what project goals must be held. Place an “X” in the box that reflects the appropriate flexibility (only one "X" per row is allowed). Some narrative examples are noted below.
- Schedule is least flexible because we must have the release ready by October 1.
- Scope (quality) is the most flexible because we can release an upgrade or modification after December 1.
- Resources and cost offer a moderate amount of flexibility.
Appendices
This section will vary from charter to charter but should include a Resource Allocation sheet, either as part of the document or as a separate handout. This sheet is required for all SGG-funded projects that go to Randy Livingston for approval. Some samples appear below.
Copyright Stanford University. Stanford, California 94305.