The Project Charter gives a clear picture of the project ...ksinc.com/pmTools/Project Charter.doc · Web viewThe Project Charter gives a clear picture of the project and the rationale

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 step—Project Feasibility Analysis.

Why? To collect information needed to evaluate whether or not a project should be funded—it is a GO/NO GO/GO BACK test that must take place before a project starts.

Who? Created by the project sponsor’s program staff and the project manager, with assistance from other managers and technical staff—the core team members.

When? Development time depends on the size of the project—a 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



1. PROJECT NAMEChoose a short, energizing name or acronym that describes your project. Be specific and make sure you're not duplicating another project's name.

2. OVERVIEW2.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 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.

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 caution—Make sure that the POS is measurable and achievable. The project’s 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 project’s 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 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 Does Not ProvideUpgrades all central office workstations to CyberOS

Workstations at sites outside the central office

Ensures that current user applications continue to function

Replacement or upgrades to user applications

Training to central office users on the new CyberOS interface

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 project’s 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 project’s 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 organization’s 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.

Identify how the project fits with the organization’s strategic/tactical vision(s). Determine which set of visions/plans the project must satisfy or be tested against.



Then describe the project’s 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 project’s alignment and/or variance.

Identify the fit with legal/regulatory direction, if appropriate for this project. Describe how the project complies with the organization’s legal mandates.

2.7 PROJECT ORGANIZATION

PROJECT ORG CHART

To better assess this project’s 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 ResponsibilitiesProject 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 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

stakeholdersProject 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,

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 Participate in issue management Participate in risk assessment and mitigation activities Identify ways to improve project processes Participate in the project retrospective

End User Representatives 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 OBJECTIVES3.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)

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

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 customer’s perspective. The completion criteria should be in quantifiable/measurable terms so that there is no doubt as to the project’s 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 CHARACTERISTICS4.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 project’s 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.

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

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

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


Documents

The Project Charter gives a clear picture of the project ...ksinc.com/pmTools/Project Charter.doc · Web viewThe Project Charter gives a clear picture of the project and the rationale