The Project Charter

The Project Charter gives a clear picture of the project and the rationale behind it. It fully
explains the intended path of the project from conception to desired outcome. The
Charter answers the question: Is there a compelling business need for the project?
The purpose of the Project Charter is to provide the approval/funding authority enough
information to decide if the project should proceed to the next stepProject Feasibility
Analysis.
Why? To collect information needed to evaluate whether or not a project should be
fundedit is a GO/NO GO/GO BACK test that must take place before a project
starts.
Who? Created by the project sponsors program staff and the project manager, with
assistance from other managers and technical staffthe core team members.
When? Development time depends on the size of the projecta general rule of thumb
is that development of the Project Charter should be less than 2 weeks.
What? An initial statement of the project scope and objectives, the problem it
addresses, who benefits, successful completion criteria, and a brief alternatives
analysis.
Project Charter Review Questions
Is the Project Background described completely and clearly?
Do the Business Objectives address the problem described in the
Problem/Opportunity Statement?
Do the Functional Requirements (if the project includes information technology)
relate to the Business Objectives?
Does the project sponsor clearly receive benefit from the completed project?
Are the Successful Completion Criteria clear and measurable?
Is the Project Scope stated so that it is clear what the project is to provide and
what it will not provide?
Is the Project Objective Statement clear and concise?
Are all Assumptions and Constraints identified?
Are the Alternatives reasonable?
Do the Project Milestones relate to project deliverables?

1989-20013 Knowledge Structures, Inc. 1

 Project Charter Outline

1. PROJECT NAME.........................................................................................3
2. OVERVIEW..................................................................................................3
2.1 PROJECT BACKGROUND..........................................................................3
2.2 PROBLEM/OPPORTUNITY STATEMENT(S)..................................................3
2.3 PROJECT OBJECTIVE STATEMENT............................................................4
2.4 PROJECT SCOPE.....................................................................................5
2.5 PROJECT SPONSOR................................................................................6
2.6 PROJECT PRIORITY AND STRATEGIC FIT..................................................6
2.7 PROJECT ORGANIZATION.........................................................................7
3. PERFORMANCE OBJECTIVES................................................................10
3.1 BUSINESS OBJECTIVES..........................................................................10
3.2 FUNCTIONAL REQUIREMENTS.................................................................11
3.3 SUCCESSFUL COMPLETION CRITERIA.....................................................12
4. PROJECT CHARACTERISTICS...............................................................12
4.1 ASSUMPTIONS.......................................................................................12
4.2 CONSTRAINTS.......................................................................................12
4.3 ISSUES/CONCERNS/RISKS.....................................................................12
4.4 IMPACT ASSESSMENT............................................................................12
5. PROJECT RECOMMENDATIONS............................................................13
5.1 EXISTING SYSTEM.................................................................................13
5.2 ALTERNATIVE ANALYSIS.........................................................................14
5.3 RECOMMENDED ALTERNATIVE................................................................14
5.4 PROJECT MILESTONES..........................................................................14
5.5 COST ANALYSIS.....................................................................................14
5.6 SOURCE OF FUNDING............................................................................15

1989-20013 Knowledge Structures, Inc. 2

 Project Charter Outline

1. PROJECT NAME
Choose a short, energizing name or acronym that describes your project. Be specific and
make sure you're not duplicating another project's name.
2. OVERVIEW
2.1 PROJECT BACKGROUND
This section describes the context surrounding the project, and presents the primary
motivation for the project. It includes a high-level description of the business area, the
current situation, the desired situation, and the gaps that exist.
The following list identifies potential items that could be included in the project
background:
A general description of the business functions, the specific services, and the
customers
The sequence of events or conditions that contributed to the current problem or
opportunity
Contributing historical data
Relevant features of the program areas involved
The manner and extent to which information technology is currently applied
A definition of the affected units of work and estimates of the quantity of work
processed
2.2 PROBLEM/OPPORTUNITY STATEMENT(S)
This section includes a concise statement of the problem(s) that negatively impacts
current business operations or the specific opportunity(s) that would make the business,
or program operations more effective.
Avoid describing the symptoms of the problem instead of the problem itself. Symptoms,
which may seem to be the problem include:
Processes which are old, confusing, convoluted, redundant, labor intensive,
undocumented, or nonstandard
Data which is incorrect or incomplete
Data which requires excessive effort expended in collection, multiple collection
points, or different versions of the truth
Too many manual processes
The symptoms of a problem are important in that they help lead to a solution. However,
symptoms alone are not enough to justify a project. To make sure that you have reached

1989-20013 Knowledge Structures, Inc. 3

 Project Charter Outline

the real problem, ask yourself So what? for each item you have included as a problem.
If you have identified a business problem or opportunity, your answers should fall into
one or more of the following categories:
PROBLEMS
Excessive costs incurred in operating an existing program
Generation of additional program costs
Services at an unsatisfactory level according to a specified policy
Workload / staff increases
Quality or timeliness of information
Additional requirements mandated by law or Federal regulations
Limitations on the capability or capacity of current resources
The following are example problem statements
Statistics of UI claims filed on Fridays are not available until the following
Friday.
The current process requires 3.6 PYs of overtime to process travel claims.
The current error rate with travel expense claims averages 60%.
OPPORTUNITIES
Avoidance of future operating costs
Improving mission critical customer services
Workload / staff reductions
Ability to add capacity to current resources
The following are example opportunity statements:
Provide the capability for state employees to access and calculate retirement
payments while reducing the number of phone calls into the customer support
unit.
Call center processing allows the department to continue with the current staffing
level, and improve service, even as the number of calls increases.
Since revised Federal law allows state access to Social Security Administration
information, this information can be used to reduce the workload required to
maintain current addresses on all individuals.

1989-20013 Knowledge Structures, Inc. 4

 Project Charter Outline

2.3 PROJECT OBJECTIVE STATEMENT

The Project Objective Statement (POS) is a high-level, written summary of the project.
The POS states what the project must accomplish in order to be successful. It reflects the
current understanding of the project and is used to focus the team members, the sponsor,
and other key stakeholders on the primary objective of the project. The POS should be
concise, 25 words or less, and avoid jargon as much as possible.
A word of cautionMake sure that the POS is measurable and achievable. The projects
success will be determined by how well it achieved the POS. The following are example
POS for different projects:
Apollo 11 Mission: I believe this nation should commit itself to achieving the
goal before this decade is out, of landing a man on the moon and returning him
safely to earth.
For an advanced military aircraft: Design a plane that can fly over the Soviet
Union at more than 70,000 feet, preferably without being detected, and take
surveillance photos that are unprecedented in their clarity.
For a Training Information System project: Develop a central database by
Q3FY13, which will be the sole source of scheduling and registration activities
and information for the department.
For a Procurement Reengineering project: Streamline and automate the
procurement process to provide computer hardware and software to all
department employees in a timely fashion at best-cost value and in compliance
with department and statewide Work Group Computing Policy.
For a software quality initiative: Create and implement a corporate-wide no
rework program to reduce software development costs by 50% within the next
12 months.
2.4 PROJECT SCOPE
Clearly defining the projects scope goes hand-in-hand with the POS. The scope sets the
boundaries on the project so it can be done successfully. The project boundaries are
defined by specific customer business areas to be supported, functionality to be included,
and/or technologies to be addressed. If the project needs to be accomplished in phases,
the specific boundaries for each phase should be stated here.
The project scope must be consistent with the Business Objectives and the Functional
Requirements stated in Section 3, Performance Objectives, of this Project Charter. For
example, the scope statement for the implementation of a new automated system could
include business process re-design, physical office alteration, new office procedures,
legal issues, financial management, and even administrative support such as travel
arrangements.
It is often beneficial to clearly state what the project does NOT include to help identify
the project boundaries. For example, the following table shows the scope of an Operating

1989-20013 Knowledge Structures, Inc. 5

 Project Charter Outline

System Upgrade project. Listed under the Provides column to signify that when the
project is completed, this is what the project results will provide. Listed under the Does
Not Provide column signifies those things that will not be included in the intended
project results.

OS Upgrade Project Scope

Provides
Upgrades all central office
workstations to CyberOS
Ensures that current user applications
continue to function
Training to central office users on the
new CyberOS interface
Does Not Provide
Workstations at sites outside the central
office
Replacement or upgrades to user
applications
End user training on user applications
under the new interface

2.5 PROJECT SPONSOR

Identify the project sponsor by name and organization. This individual is the one whose
department has the greatest stake in the projects success and is responsible for the
project's costs and benefits. Typically, the sponsor comes from the client organization.
Ask the following questions to help identify the project sponsor:
Who cares so much about the successful completion of the project that they are
willing to fund the project and ensure that adequate resources are assigned to it?
Who will make the final decision if the team cannot resolve a problem on its
own?
Who will make the final decision to add resources, cut features, and slip the
schedule for the project?
The project sponsor has the ultimate responsibility for the projects costs and benefits and
should be of a high enough level to have the necessary leverage, authority and the
ultimate responsibility. If it's a small, local project, a division or section manager could be
the sponsor. If it's a large, multi-departmental project, a senior executive should be the
sponsor.
2.6 PROJECT PRIORITY AND STRATEGIC FIT
Identify how this project fits into the business unit and the organizations tactical plan.
Determine the priority for this project relative to other projects that the project sponsor is
responsible for. Then determine the project priority across the organization as well. Refer
to specific goals and/or objectives in the strategic or tactical plan and identify how the
project helps meet these goals.
The following steps may be helpful in clarifying the strategic fit.

1989-20013 Knowledge Structures, Inc. 6

 Project Charter Outline

Identify how the project fits with the organizations strategic/tactical vision(s).
Determine which set of visions/plans the project must satisfy or be tested against.
Then describe the projects alignment and/or variance from the existing
vision/plan.
Identify the fit with organizational strategies. Sometimes the project may affect
one or more local department strategies or business plans. Identify which one(s)
and describe the projects alignment and/or variance.
Identify the fit with legal/regulatory direction, if appropriate for this project.
Describe how the project complies with the organizations legal mandates.
2.7 PROJECT ORGANIZATION
PROJECT ORG CHART
To better assess this projects impact on the organization, provide an organization chart
that includes the project team, including number and classification of team members and
the impacted program organization(s).
PROJECT STAKEHOLDER ROLES AND RESPONSIBILITIES
A formal project structure provides participants with a clear understanding of the
authority and responsibility necessary for successful accomplishment of project activities,
and enables project team members to be held accountable for effective performance of
their assignments.
Briefly describe the roles and responsibilities of the major participants in the project.
These will probably include, at a minimum, the project manager, executive management,
program management and staff, and core team members. In particular, if outside vendor
resources will be used to assist with the project, clearly differentiate between the roles
and responsibilities of State staff versus those of vendor staff. Include tasks such as data
conversion, training, project management and oversight, and ongoing maintenance, as
appropriate.

Project Stakeholder Roles and Responsibilities

Role Responsibilities
Project Sponsor Authorize project
Articulate program requirements
Ensure that requirements are met
Define sponsor needs
Assign sponsorship personnel as project points of
contact
Approve funding
Review and approve project plan
Participate in planning session

1989-20013 Knowledge Structures, Inc. 7

 Project Charter Outline

Make go-no go decisions project if critical issues

arise
Mediate approval issues which cannot be resolved
between core team members and the project manager
Attend executive requirements reviews
Help resolve requirements problems
Provide written agreement to requirements and
qualifying criteria
Monitor milestones, activities, timelines, resources,
budgets and critical path
Monitor contracts
Communicate and coordinate with project
stakeholders
Project Manager Implement project policies and procedures
Review and refine project request documents
Define project success criteria
Document project tradeoffs
Conduct cost/benefit analysis
Acquire reserves required to perform work
Maintain staff proficiency and productivity, and
provide training where required
Establish and maintain project quality
Identify and procure tools to be used on the project
Develop detailed project plan, tailoring methodology
to reflect project needs
Ensure that project plan is approved and baselined
Assign resources to project and assign work packages
Approve project quality and configuration
management plans
Ensure that management, users, and contractors agree
to project commitments
Regularly review project status, comparing budgeted
to actual values
Identify risks and track issues
Manage change request process throughout the life of
the project
Ensure that project plan is updated regularly
Review the results of quality assurance reviews
Obtain management and user approval of design, test,

1989-20013 Knowledge Structures, Inc. 8

 Project Charter Outline

and approaches
Review project risks and establish mitigation
procedures
Develop an action plan for any product that does not
pass acceptance test
Obtain user and management approval of tested
solution
Close-out open action items
Assist in contract close-out
Develop post-implementation report
Conduct project retrospective
Core Team Members Represent business needs/requirements for Identify
project alternatives
Implement solution within budgeted cost and
schedule
Support project planning and tracking
Provide task estimates.
Ensure that requirements are feasible and appropriate
for available resources
Analyze requirements for completeness, consistency,
and ambiguity
Ensure that all team members understand the project
plan
Identify staff training needs and provide qualified
staff
Establish the project's facilities and environments
Ensure that the project team staff fully understands
requirements.
Review technical approach
Assign tasks
Assist in development of estimates and schedules
Track the work effort and submit status reports
Conduct internal and external work product reviews
Coordinate with quality assurance, review quality
assurance results, and correct any deviations
Establish testing plan and coordinate test activities
Accept problems and schedule fixes
Identify risks as they are found
Participate in change request reviews

1989-20013 Knowledge Structures, Inc. 9

 Project Charter Outline

Participate in issue management

End User Representatives
Participate in risk assessment and mitigation activities
Identify ways to improve project processes
Participate in the project retrospective
Define user needs
Review current business practice and the impact the
new system will have on it
Ensure that requirements are met
Ensure that staff are trained and ready to accept the
new system
Be proponents of new system to other remote users
Assign user personnel as project points of contact
Review and approve project plan
Review project status reports
Attend requirements reviews
Help resolve requirements problems
Assist in user testing
Approve delivery and installation procedures
Develop procedures, policies, and systems to support
the new system
Participate in the project retrospective

3. PERFORMANCE OBJECTIVES
3.1 BUSINESS OBJECTIVES
Briefly state the business objectives that effectively respond to the problems and/or
opportunities. Include at least one objective for each problem/opportunity mentioned in
Section 2.2, Problem/Opportunity Statement. Objectives define the significant results
that must be achieved by this project. When writing the objectives remember to focus on
What the system or product will do, not How. Each objective should:
Directly relate to a problem/opportunity item
Be realistically achievable
Be measurable (this means that progress on the objective can be tracked,
measured and compared)
Indicate the direction of expected change (more, less, same as etc.)
Indicate the degree of expected change (percentage, prior year level, numbers of)

1989-20013 Knowledge Structures, Inc. 10

 Project Charter Outline

Business objectives usually fall into one of the following four categories: increasing
revenues for the organization, avoiding costs, improving customer service, or complying
with federal and state governmental regulations. For example:
Provide statistical data of all UI claims filed on Fridays as required by state
mandate.
Eliminate 3.5 PYs for processing travel claims, reducing the cost per travel claim.
Verify current address for 75% of new claims filed, reducing errors and rework
per claim.
3.2 FUNCTIONAL REQUIREMENTS (IF INFORMATION TECHNOLOGY IS REQUIRED)
Identify the essential characteristics that the proposed automated solution must have if it
is to satisfy the objectives. Functional requirements describe how the project result will
function and provide a list of the minimum technical features that must be in place when
the project is complete. Each functional requirement should track back to a business
objective, and should be specific enough to be used to measure the successful completion
of the project. The primary functional requirements appear on the Project Data Sheet as
Ability To statements or Performance Objectives depending on the nature of the
requirement.
Depending on the project, the functional requirements are written in terms of:
Types of data, in terms of groups, size, retention period etc.
Database characteristics
Processing procedures
Processing functions needed to support the program process
Types of output, in terms of groups, volume, timing, location, quality, media etc.
Types of input in terms of groups, volume, timing, location, quality, media etc.
Software constraints
Equipment/hardware constraints
Staffing constraints
Security or confidentiality risks
Hardware/software interfaces
Development scheduling constraints
Data constraints
Organizational constraints

1989-20013 Knowledge Structures, Inc. 11

 Project Charter Outline

Legislative constraints
Functional requirements usually describe very high-level, but specific features of the
resulting system. For example:
The system must have on-line access to SCDB U1 claim records.
The system must print credit card numbers on travel vouchers.
The system must be able to access the SSA UNIX-based database.
3.3 SUCCESSFUL COMPLETION CRITERIA
Describe how the success of the project will be determined from the customers
perspective. The completion criteria should be in quantifiable/measurable terms so that
there is no doubt as to the projects success. If the business objectives have been
sufficiently quantified, meeting them constitutes the successful completion criteria.
Quantifiable measures of customer use and/or satisfaction with the final product also
measure the successful completion of the project.
4. PROJECT CHARACTERISTICS
4.1 ASSUMPTIONS
List any assumptions that were made in defining the project. Assumptions can affect any
area of the project including scope, the stakeholders, the business objectives, and the
functional requirements. A basic assumption behind most projects is that the problem
should be solved. If any assumptions have been made regarding staffing, e.g. specific
technical or business skill sets and/or individuals necessary to complete the project, list
these assumptions here.
4.2 CONSTRAINTS
Identify known or suspected constraints to the execution of the project. These constraints
describe boundaries within which the project must operate and which also may be
obstacles to the projects successful completion. For example, constraints could include
any of the following:
Limited head count
Lack of or limited knowledge
Short window of opportunity
Staffing constraints
Delivering the product within a specific time frame
Delivering the product within a limited cost
Be as specific as possible and describe the constraints in the context of the project.

1989-20013 Knowledge Structures, Inc. 12

 Project Charter Outline

4.3 ISSUES/CONCERNS/RISKS
Identify major items that could cause the project to fail. Concentrate on those items,
which are outside the jurisdiction of the project and could be show-stoppers to the
success of the project. Include what mitigating steps can be taken to reduce each of the
risks.
4.4 IMPACT ASSESSMENT
The Impact Assessment identifies any systems, processes, or projects that will impact, or
be impacted by, the proposed project. The nature of the impact, the owner, and action
required should be addressed. For example:
A new software system may increase the number of calls (transactions) to the call
center.
Deployment of a new software package may require all PCs to be upgraded to the
latest version of the operating system.
Introduction of a new product into the market may render certain current products
obsolete, and they may need to be retired (e.g., existing warehouse stock may need to be
liquidated).
The implementation of a project may impact the redesign of the database structure
used by another project currently under development.
In the case of related projects, it is helpful to describe the nature of the dependency. The
project being planned may be dependent on another project, be interdependent with
another project, or have projects that depend on it. The nature of the dependency can
include:
Data: The project shares data with another project.
Function: The project shares common functionality with another project.
Staff: The project shares staff with another project.
Technology: One project installs the technology that another requires.
Funding: The projects share funding arrangements.
Include any dependent or interdependent projects on the Project Data Sheet under
Dependencies.
5. PROJECT RECOMMENDATIONS
5.1 EXISTING SYSTEM
Briefly describe the current method of operation. If an automated solution currently
exists, include a general description of the system procedures, inputs, outputs, overall
costs, PY numbers and PY costs. In addition, include pertinent information from the
following topics as necessary:
Current system objectives

1989-20013 Knowledge Structures, Inc. 13

 Project Charter Outline

Shortfalls of current operations

Current workload requirements
Backlogs
Data entry methods, both manual and automated
Data characteristics, contents, structure, size, languages, volatility, accuracy
Data integrity, security, privacy, confidentiality; Existing equipment, peripherals,
processors
Software, software languages
Documentation, accuracy
User satisfaction, system drawbacks, failures
System successes, things that work well
Support costs, future costs, overruns
5.2 ALTERNATIVE ANALYSIS
Identify the potential alternatives for accomplishing this project. For example, one
alternative could be to build a solution in-house. Another alternative could be to buy the
software from a vendor, and tailor it to support the organizations business. Still another
alternative might be to accomplish only part of the desired solution in a phased approach
to the project. Include specific technologies in this section only if they are required by
organizational constraints or architectural standards. Include enough detail to thoroughly
describe the potential alternatives, and differentiate between them.
Include the following general information for each alternative:
General description including what the alternative is, how it would be
implemented, and how it would work after implementation. Include additional
details such as specific interfaces, tools required, architecture requirements,
support, etc.
Estimated time frame
Specific assumptions and constraints
Advantages
Disadvantages

1989-20013 Knowledge Structures, Inc. 14

 Project Charter Outline

5.3 RECOMMENDED ALTERNATIVE

Select one of the alternatives to be carried forward. Provide justification for why you
chose this alternative. Provide preliminary costs to develop and maintain the proposed
solution.
5.4 PROJECT MILESTONES
List the major events by which you intend to measure your progress on the project. The
major milestones should coincide with the deliverables. It is not necessary to identify a
separate milestone for each deliverable. However, it should be clear from the milestone
description which deliverables are completed by that milestone.
Events that must be reported include: project start date, development completion date,
operational date and post-implementation evaluation date. Any other important deadlines
or key management checkpoints critical to project success, such as procurement dates,
budget deadlines, legislation enactment dates, or partial implementation dates, should
also be included. Project management milestones should be identified at no less than
three-month intervals during the life of the project.
Most milestone completion dates are represented by elapsed days/months from the
project approval date. However, if the project includes dates mandated by legislation,
show these specific dates as the milestone.
Project Milestones Completion Date

5.5 COST ANALYSIS

Estimate the costs and income of your selected alternative for three to five fiscal years
from the beginning of the project, depending on the project duration and size.. Present
these high level estimates in the following Cost Analysis Table. Remember that this is
only a preliminary estimate. It will be used as a guide to allocate resources, not to
measure the success or failure of the project. A more accurate estimate of both schedule
and resources will be derived during the Plan phase, if the project is approved.
Cost reductions or personnel-year reductions should be reported as negative numbers,
while cost increases or personnel-year increases should be reported as positive numbers.
If the proposal modifies or replaces an existing operation, savings and cost avoidance
should be based upon comparison with the current method of program operation. If the
proposal recommends a new system, provide estimated costs for the proposed

1989-20013 Knowledge Structures, Inc. 15

 Project Charter Outline

information technology capability. If the proposed solution will increase program income
(i.e. tax revenues, collectable audit exceptions, accounts receivable, etc.) such increase
should be reported as negative numbers under Program Income.

FY <1> FY <2> FY <3>

PYs Costs PYs Costs PYs Costs
One-time Costs $ $ $
Continuing Costs $ $ $
Impacted Program $ $ $
Costs
Program Income $ $ $
Net Program Costs $ $ $
Cost Savings $ $ $
Cost Avoidance $ $ $

5.6 SOURCE OF FUNDING

Indicate the source of funding anticipated for the proposed project. If the project is to be
funded from multiple sources, list each source. Examples include the State General Fund,
special funds, Federal grants, interagency reimbursements, redirection from existing
baseline funds, and contracts. Also, state if the funds have been budgeted for this purpose.

1989-20013 Knowledge Structures, Inc. 16