This document is a project charter that outlines the scope, objectives, risks, and management approach for an unnamed project. It includes sections that define the background, objectives, success criteria, scope across processes, organizations, locations, applications and data, assumptions, constraints, risks and mitigation strategies, documentation, timeline, and management roles. The project charter establishes a baseline for tracking work activities and managing the scope, schedule and budget of the project.

1. (PROJECT TITLE)
Project Charter
Version Control
Version Date Author/Modifier Comments
1.0
1.1
1.2
- 1 -

2. Document Sign-Off
Accepted By:
Sponsor Names Signature Date
- 2 -

3. Table of Contents
(PROJECT TITLE)....................................................................................................................................1
...................................................................................................................................................................1
Project Charter...........................................................................................................................................1
Accepted By:..............................................................................................................................................2
Sponsor Names..........................................................................................................................................2
Signature Date............................................................................................2
.................................................................................................................................................................2
...................................................................................................................................................................2
Table of Contents...................................................................................................................................3
I. Background of the Project..................................................................................................................5
II. Project Objectives..............................................................................................................................5
III. Success Criteria................................................................................................................................5
IV. Consequences of Failure..................................................................................................................5
V. Project Scope.....................................................................................................................................5
A. Process Scope....................................................................................................................................5
B.Organization Scope............................................................................................................................5
C.Location Scope (Campus, District, Vendor Locations).....................................................................5
D.Application Scope..............................................................................................................................6
E.Data Scope..........................................................................................................................................6
F.Technology Scope...............................................................................................................................6
G.Other Scope........................................................................................................................................6
VI. Assumptions.....................................................................................................................................7
VII. Constraints......................................................................................................................................7
VIII. Risk Analysis................................................................................................................................7
There are high level risks and there are risks pertaining to this project. Please list all.........................7
IX. Contingency Plans...........................................................................................................................7
X. Project Documentation......................................................................................................................8
XI. Key Dates in the Project..................................................................................................................8
XII. Management Approach..................................................................................................................8
A. Project Baseline...............................................................................................................................9
B. Project Control..............................................................................................................................10
C. Project Communication.................................................................................................................10
D. Project Issue Resolution................................................................................................................11
E. Project Change Control Process....................................................................................................11
- 3 -

4. XIII. Project Team...............................................................................................................................13
- 4 -

5. I. Background of the Project
II. Project Objectives
III. Success Criteria
IV. Consequences of Failure
V. Project Scope
A. Process Scope
The following business processes will be reviewed and defined as part of the
project.
In Scope Out of Scope
• • All processes not specifically defined
as “In Scope”.
•
B. Organization Scope
The following departments will be impacted
In Scope Out of Scope
• • All organizational components not
specifically defined as “In Scope”.
C. Location Scope (Campus, District, Vendor Locations)
In Scope Out of Scope
• • All locations not specifically defined as
“In Scope”.
- 5 -

6. D. Application Scope
In Scope Out of Scope
• •
E. Data Scope
The data domain addresses the content, structure, relationships, and business
data rules surrounding the information that the enterprise retains permanently.
In Scope Out of Scope
• • All data components not specifically
defined as “In Scope”.
F. Technology Scope
In Scope Out of Scope
• • All technology components not
specifically defined as “In Scope”.
G. Other Scope
In Scope Out of Scope
• • Anything that is outside of A-F that is
out of In Scope.
- 6 -

7. VI. Assumptions
Category Assumption Criticality
Technical
Project Team
Members
Application
Training
VII. Constraints
VIII. Risk Analysis
There are high level risks and there are risks pertaining to this project.
Please list all.
POTENTIAL RISK POTENTIAL IMPACT MITIGATION STRATEGY
Natural Disaster or other
unforeseen circumstances
Project schedule/deliverables
may not be completed timely
Additional time is built into the schedule to
accommodate a one-two week delay and
still meet the payroll for the summer
schedule.
Project team resources are
not available based on
required resource allocation
worksheet
Project schedule/deliverables
may not be completed timely.
Procure executive commitment to team
member allocation for project, with back-
fill of current assignment, if needed.
Functional and Technical
Subject Matter Experts
(SME’s) are not available as
needed and/or are not open
to the project goals/concept.
Project schedule/deliverables
may not be completed timely.
Procure executive commitment to provide
subject matter experts as directed by
mutually agreed upon schedule for
functional and technical information;
communicate needs at the project start-up
to SME’s and stakeholders along with
proposed schedule of project participation.
Personnel is overcommitted Project schedule may be
delayed
Raise awareness to Project Sponsors.
Identify any delays through bi-weekly
status reporting.
Key personnel may leave Project schedule may be
delayed
Raise awareness to Project Sponsors.
Identify backup personnel. Attempt to
accommodate any special needs of key
personnel.
POTENTIAL PROJECT RISK POTENTIAL IMPACT MITIGATION STRATEGY
. .
IX. Contingency Plans
- 7 -

8. X. Project Documentation
Project documentation will be consolidated in a central directory
pbcc.edusharespmoprojectsXXX
XI. Key Dates in the Project
Phase Description Milestone Target
Start Date
Target
End Date
XII. Management Approach
Information Technology and the Sponsors are jointly responsible for the management
of the project and for providing the necessary resources to the project. Our
management objectives are aligned on tightly monitoring, controlling, and balancing
the project’s 3 key constraints: Scope (or Product), Budget, and Schedule. This
section describes the basic approaches that we will use to provide this type of
control.
To be effective in achieving this primary management objective, we must establish:
- 8 -

9. • An agreed-upon baseline
• A process to monitor progress
• A clear means of communication
• An open approach for dealing with issues/problems
• An objective change control procedure
• Identify risks to the project that are beyond our collective control and have
strategies in place to mitigate those risks.
A. Project Baseline
This Project Charter is the foundation or baseline for all the key project
management activities on the project. It identifies the work activities that will
be tracked, defines the boundaries for scope control, and clarifies many of the
areas where issues may arise that need to be managed.
The Project Charter is then used as the basis for creating a detailed project
plan for all the work activities to be performed on the project which will identify
Information Technology and Sponsor responsibilities. Every activity will have
an estimate of work effort. All project team members, from Information
Technology and Project Sponsor, (and at times sub-contractors) will be
assigned these activities.
Once all the activities are allocated to team members, the project plan is
leveled and loaded against the calendar. This completed plan represents the
baseline plan. This plan will provide the key milestone dates to track schedule
progress and can be revised as the project proceeds.
- 9 -

10. B. Project Control
The detailed project plan is the key vehicle for measuring progress. The
specific activities that each team member works on, and their progress
against completing those activities, are the only objective measure of where
the project stands against the schedule and budget. To capture this
information every team member, both Information Technology and Sponsor,
will record and report their actual hours spent on project activities against the
budgeted time in the project plan. In addition, each team member will provide
estimates of the effort remaining on activities that have not been completed.
This information will be recorded along with a status report that provides a
brief description of work accomplished, issues/problems, and planned work.
This information is analyzed by the management team to determine where
the project stands versus the schedule and budget.
C. Project Communication
It is imperative that we use a formal process of communication to ensure
timely and accurate communication between the organizations. There are two
key vehicles for providing this communication: a bi-weekly status report and a
bi-weekly status meeting.
As mentioned earlier, all team members will report progress and status bi-
weekly. This information, and the analysis of it, will be summarized into a
project status report presented to Implementation Team and Information
Technology Management. This report contains the following information:
• Project Status
• Issues Log: Major Issues/Issue Resolution
• Accomplishments
• Planned Accomplishments
Project status meetings and Status Reports will be used to review the project
status and open issues in the status report. The project team must be
committed to having this meeting and making it effective. The keys to making
the meeting worthwhile are:
• Have the meetings often enough so that timely information is available
• Focus the meeting on major issues or areas where management action
or intervention is required
• Make sure that the information provided is accurate and objective.
- 10 -

11. D. Project Issue Resolution
Every project has issues that hinder progress. It is important to ensure that
these issues are identified and resolved quickly by the right person. The first
step in effectively dealing with these issues is to make the entire team aware
of the importance of identifying issues and getting proper resolution. Both
Project Team Members and Management Teams have the below
responsibilities in managing the issues and issue log:
Project Team Members:
• Identify issues. When the project begins, we will start identifying any
issues that could hinder our ability to meet the objectives of the project.
Issues can be identified by anyone involved with the project.
• Document the issue. The person who identifies the issue must
document it.
• Report progress on issue resolution. As mentioned earlier, the
issues log will be a part of the bi-weekly status report and discussed in
the bi-weekly status meeting.
• Document resolutions of issues so resolutions are available to all
team members.
Management Team:
• Assign responsibility for resolving issues. The project management
team will determine the appropriate individual who will be responsible for
resolving each issue. The responsible person must be an individual who
has the knowledge and authority to make decisions regarding the issue.
• The management team will also assign a priority to the issue.
• Monitor and control progress. All issues will be tracked on an issues
log that will be maintained to formally track the status and resolution of the
issues.
In the event that an issue cannot be resolved in a reasonable timeframe to
the mutual satisfaction of Information Technology and the project team, we
will determine a mutually acceptable approach to escalating it to the next level
of management.
E. Project Change Control Process
- 11 -

12. The Change Control Procedure is a crucial mechanism that can affect the
success or failure of this project. This process is the primary vehicle for
containing scope and ensuring that management has the opportunity to make
timely trade-offs between the three key project variables of cost, time and
scope. It is imperative that potential changes are identified early, documented
carefully, and resolved at the appropriate levels of responsibility.
Changes are broadly defined as those activities not originally considered
within either the products to be delivered or tasks to be performed as defined
by the Project Charter. More specifically, changes will include:
• Any business-related scope items not listed in the Project Charter (Like
additional business processes, functions, programs, databases, etc.)
• Participation in activities not previously included in the Charter’s list of
work activities
• Provision or development of work products or deliverables not included
in the Project Charter
• A change in the assumptions defined in the Project Charter
• Delays or rework caused by items identified in the Project Charter as
dependencies or constraints
• Requirement changes
• Delays caused by a change in previously agreed-upon acceptance
criteria
• Investigative work to develop impact statements for major change
requests
In order to manage change properly, a Change Control Process will be
established to identify, record, assess, and approve changes to the project.
Information Technology and the Sponsors will follow this process to classify,
prioritize, approve, or reject out-of-scope changes.
Change requests need to be clearly defined, including cost and schedule
implications, to allow Information Technology and Sponsor management to
make accurate decisions about changes identified during the project.
Information Technology will always need prior authorization and approval of
expenditures by the Sponsor before starting work on out-of-scope changes.
The following steps must be followed for all change requests.
1. Identify a change. Either Information Technology or Sponsor can
state that a change has been identified.
2. Initiate the change request. Once a change has been identified, a
written change request form will be filled out.
- 12 -

13. 3. Conduct a detailed impact analysis. One or more team members
will be assigned to analyze the approved change.
4. Communicate the change. Information Technology will document
the detailed impact analysis, including cost and schedule impact,
and return the change request to the appropriate Sponsor manager
for consideration.
5. Obtain Sponsor authorization to implement the change. Sponsor
will formally authorize the work and expenditure of funds for
changes that should be implemented.
6. Incorporate the change into the project schedule. Once a change
is authorized, project plans and schedules will be updated and
proper work assignments will be made to implement the change.
XIII. Project Team
Project Sponsoring Committee
•
Key Project Personnel
•
XIV. Support Plan
This is text to describe the ongoing and maintenance plan for post implementation of
the project.
XV. Communication Plan
Who? What? How?
XVI. Project Closure:
Customer Sign Off _______________________________
Customer Sign Off _______________________________
Customer Sign Off _______________________________
Customer Sign Off _______________________________
XVII. Lessons Learned
“A lesson learned by doing this project was that…
1.
2.
3.
4.
5.
- 13 -