ARCHIVED - Project Charter Template Guidelines

This page has been archived.

An Enhanced Framework for the Management of Information Technology Projects

Project Charter Template Guidelines

February 1999
Chief Information Officer Branch
Treasury Board of Canada Secretariat

Preface

These guidelines explain how the Project Charter Template should be created. Included is a brief description for each section along with an explanation of the contents of the section and/or the rationale for including that section in the Project Charter.

These guidelines are not meant to be standalone, but rather are intended to be used in co-ordination with the Project Charter Template.

Throughout these guidelines, reference is made to your department's existing procedures. If your department does not have these defined, refer to the IT Project Management Guide for examples of standard or generic procedures.

Document Change Control

This section provides control for the development and distribution of revisions to the Project Charter up to the point of approval. The Project Charter does not change throughout the project life cycle, but rather is developed at the beginning of the project (immediately following project initiation approval, and in the earliest stages of project planning). The Project Charter provides an ongoing reference for all project stakeholders. The table below includes the revision number (defined within your Documentation Plan Outline), the date of update/issue, the author responsible for the changes, and a brief description of the context and/or scope of the changes in that revision.

Revision Number	Date of Issue	Author(s)	Brief Description of Change

Project Overview

Project Purpose

A brief description of the project should be provided. This should describe in business terms the reason for the project and the overall timing and expectations. Some background information about how and why the project was initiated should also be included. Describe who (in terms of individual roles and/or organizational areas) will use the final outcome of the project and identify any other stakeholders who will be impacted by the results of the project. The Business Case document may already contain the information to be included in this section and should be referenced as appropriate.

Project Scope

Identify the project scope and the product/service scope.

The product scope defines the spectrum of features and functionality that will be delivered and the limits that have been imposed in order to control the release or delivery of the product or service (what the project will accomplish). The product scope description within the Project Charter will not constitute the requirements specification for the product. Rather, it is expected to provide a general description of the product and the initial understanding and agreement about the scope of that product.

The project scope defines the work that is required to deliver the project product or service to meet the project objectives (how the project will be accomplished).

Although the product scope and project scope are tightly related, the remaining sections of the Project Charter cover the project scope and the processes required to deliver the project. The focus within the Charter should remain on project processes.

Project Objectives

Identify the overall objectives for the project. Identify what the project is intended to achieve, in business and technical terms. Refer to the Investment Decision, the Business Case and the Logical Framework Analysis.

Outstanding Issues

Identify any outstanding issues that need to be resolved within the scope of the Project. These are issues that have been identified during the Business Case creation and approval process and/or through the project initiation process.

Approvals

This section identifies the names and roles of the project stakeholders and their approval of the Project Charter. Signatures are often included in this section, though in some organizations a listing of the Project Sponsor and Project Manager is all that is required.

References

Identify any other documents, including, for example, the IM/IT Investment Decision, the Business Case and/or the Logical Framework Analysis, (in electronic and/or paper form) that relate to the project at the time of development of the Project Charter. Include the current revision number, issue date, author, location of the document and method of access for each document or reference. It is not necessary to repeat the detailed content of these related documents. Rather, enough information should be provided in this section to explain how the document relates to the project, what it contains that is pertinent to the project, and how it can be located.

Terminology

Define any unique of significant terms and/or acronyms that will be commonly used within the project. Terms that may be new or confusing to project stakeholders should be clearly explained.

Project Approach

A brief description of the project approach. Provide a high level overview of the project approach, project team structure, and project plan.

Project Deliverables and Quality Objectives

Provide a list of deliverables that will be generated both during and on completion of the project. Identify key milestones.

For each deliverable, provide a description of its quality objectives in terms of output quality and approval requirements. (For example, "interim status reports will be provided weekly to the Project Sponsor and Project Team Leaders and will be approved by each person prior to being accepted within the project archives.")

The amount of support to be allocated to the implemented product or service should also be included as a quality objective.

Organization and Responsibilities

This section identifies the required Project Team, and, taking the organization's Resource Plan and the project skill requirements into account, assigns roles and responsibilities to named individuals.

The organization may include:

1. Executive Committee
2. Project Leader
3. Project Manager (IT Project Manager and/or Business Area Project Manager)
4. IT Area Project Team Leaders (Development Team Leaders or IT Area Project Team Leaders who assist the Project Manager in administering and/or managing specific aspects of the project)
5. Project Team Member(s) (including IT team members and business clients)
6. Test Co-ordinator
7. Quality Assurer
8. Configuration Controller
9. Change Controller

The same person may have multiple roles on a project. For example, on smaller projects, the Project Manager may also be a Project Team member, Change and Configuration Controller and Test Co-ordinator. On smaller projects, an Executive Committee may not be appointed and the Project Leader handles the approval and oversight roles.

On larger projects IT Area Project Team Leaders may be appointed to assist the Project Manager in coordinating the overall project activities and in managing specific workplan deliverables.

On most projects, it is preferable that the Project Manager does not also fulfil a team member role, as this tends to distract from their primary project management duties.

These roles are further described in the Project Management Guide, General Roles and Responsibilities.

Within this section, reporting relationships and project interfaces should be described. Required approvals (e.g., TBS submissions), interfaces with organizations such as PWGSC (for procurement) and with review, oversight, and/or steering committees should all be documented.

Dependencies

Any dependencies outside of the Project Manager's direct control, or outside of the scope of the project (but which may still influence the project success) should be identified. For example, activities to be carried out by a client or subcontractor, or activities or deliverables from an external project that are required within the context of this project.

Internal dependencies must also be considered. Dependencies of the project, and/or the project deliverable (product) on other projects/products (existing or in development) should be clearly identified. For example, if a needed resource cannot become available until another project is completed, this dependency should be identified and the related risk documented in the appropriate section of the Project Charter. Required linkages to other existing or planned systems should also be identified.

Plans for Support Activities

Plans for support activities are described here. Examples of support activities are training, quality assurance, configuration management, and documentation support. If these plans exist as documents external to the Project Plan (e.g. Configuration Management Plan, Quality Plan, Project Training Plan), they should be referenced here.

Project Facilities and Resources

The project's requirements for facilities and resources, such as office space, special facilities, computer equipment, office equipment, and support tools should be identified.

Responsibilities to procure or develop these items should be clearly assigned and described here.

Planning for adequate computer resources (i.e. memory, processor use, disk space) takes into account the size of the software solution being acquired and/or developed, the project staffing levels, and past history of similar projects.

Risk Management

Any risks associated with the project and the actions that can be taken, during the project to minimize the risks need to be identified. Mitigation and planned response approaches should also be identified.

For example, a risk may be a dependency upon a single skill (one resource) within the organization. The management required would be, at least, to have identified alternative sources of that skill or provide on-the-job training for a backup resource. Use of a new type of hardware could also be considered to be a risk. The management required here could be to introduce early prototyping or additional testing.

The process for identifying, documenting, tracking and monitoring risks, as well as implementing risk avoidance, mitigation and response strategies needs to be defined.

On larger projects, the Risk Management Plan may reside outside of this document. On smaller projects, it will begin as part of the Project Charter but will need to be updated throughout the life of the project within an external document or system.

The federal government has adopted an approach called Continuous Risk Management (CRM). It is based on common sense and practical project management considerations. It is comprehensive and thorough. It is an aggregate of proven best practices that has been successfully used on a growing number of projects in several government departments.

The approach is generic and non-proprietary. All materials are in the public domain. This includes a Guidebook and its contents, such as the taxonomy questionnaire and any algorithms that might be used in the associated tools and techniques. There is no requirement to depend on a proprietary algorithm or special software to generate results.

Training is readily available and personnel in departments can quickly become self-sufficient. There is no requirement to hire consultants to conduct/interpret assessments. The approach can be quickly implemented in a specific project or in an organisation's portfolio of projects. The Guidebook clearly explains how to do this.

More information on CRM can be obtained at the Treasury Board Secretariat's Chief Information Officer's web-site under the Enhanced Management Framework (http://www.tbs-sct.gc.ca/emf-cag/risk-risques/risk-risques-eng.asp).

Process Options and Deviations

If your Department already has a defined Project Management Methodology or Systems Development Life Cycle Methodology, these should be followed on this project. If for any reason, deviations from these defined standards are deemed necessary and/or appropriate for this project, these deviations should be identified and the rationale and appropriate approval for such deviation be recorded here.

Stages

A description of the project life cycle (project) and the solution delivery life cycle (product development) should be included. A definition of the stages to be used on the project, the objectives of each stage and their entry and exit criteria need to be clearly defined.

Refer to your department's definition of phase inputs, outputs and entry and exit criteria. For each life cycle phase, applicable procedures, methods, and standards should be referenced or identified (if your department does not have a defined procedure, refer to the Project Management Guide).

Project Control

Project control explains the methods and processes that will be implemented to assist the Project Manager in identifying project progress and communicating that progress to the project team, project sponsor, and project stakeholders. It also includes definition of the approach for resolving deviations from the project plan and taking corrective action.

Project control should include:

• The type and frequency of production of Project Reports;
• The frequency and attendees of Project Team meetings.
• The frequency of Stage Checkpoint Meetings (attended by the Executive Committee as appropriate).
• The frequency of Executive Committee meetings.
• The name and location of the Project File.
• The methods to be used to log and control project actions.
• The criteria for issuing a revised version of the Project Plan.
• The metrics to be collected during the project and the analysis to be performed on them.

This section should also identify the methods and policies to be used for project scope control, issue management, and change and configuration management.

Also within this section should be an outline of the project communications plan – the methods, timing, audience, etc. of project communications (tools to be used, methods of delivery, recipients, collection of project information and feedback and archiving of project working papers).

Quality Control Activities

Quality control activities relate to both the project management processes and deliverables, and the product development processes and deliverables. A list of all the quality reviews and quality tests that will be carried out during the project, including ownership, approximate schedule and effort required. For example, review of the Project Plan, design reviews, unit testing, system testing, acceptance testing should be identified.

A list of all joint customer/client reviews should be identified and planned for. Include meetings to review acceptance test results and conformance to agreed-upon requirements.

At this point in the project, the specific product-related reviews and processes (design reviews, system tests, etc.) might not yet be known. However, an overview of the types of reviews that are expected to take place and the level of involvement from various project stakeholders and team members, should be listed here.

Project Schedule

A Gantt chart of activities, resources and assigned responsibilities allocated to them. Your Department's Project Management Methodology and/or Systems Development Life Cycle Methodology may influence the creation of this Gantt chart (including the associated Work Breakdown Structure).

The project schedule must take into account critical dependencies between the project groups.

Use of a Project Management software tool is recommended to produce the project schedule and to monitor the progress against the schedule.

Project Effort Estimate

This section identifies the project effort, in person days or person months, estimated in accordance with your department's Estimation Procedure. If your department does not have a defined procedure, refer to the Project Management Guide. Effort should be broken-down by project stage and project phase.

Information used to derive the effort estimate should also be included (assumptions, historical results used to develop the estimates, etc.).

Project Cost Estimate

This section outlines the project cost, estimated in accordance with your department's Estimation Procedure. If your department does not have a defined procedure, refer to the Project Management Guide. Costs should be itemized (i.e. labour, equipment, office space) and broken down by project stage and project phase. Additionally, the procurement policies and methods to be used within the project should be detailed (who is responsible for purchasing decisions and developing and managing purchase orders, requests for proposal, etc. and how will these be managed).

Information used to derive the cost estimate should also be included (assumptions made, sources of costing information, historical costs used to estimate the costs).