Project Charter Guide

Project Charter Guide

An Enhanced Framework for the Management of Information Technology Projects
Project Charter Guide 2008 IT Project Review and Oversight Division Treasury Board of Canada Secretariat http://www.tbs-sct.gc.ca/emf-cag/project-projet/documentation-documentation/guideguide/guide-guidetb-eng.asp

Table of Contents
Introduction Use of the Project Charter What is a project charter? Why create a project charter? Who is responsible for the project charter? How to create a project charter Tailoring the project charter to specific projects Use of the Project Charter Guide Section 1. Charter Introduction 1.1 Document change control 1.2 Executive summary 1.3 Authorization Section 2. Project Overview 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Project summary Project goals, objectives, and business outcomes Project scope Milestones Deliverables Project cost estimate and sources of funding Dependencies Project risks, assumptions, and constraints

Section 3. Project Organization

Project Charter Guide

3.1 3.2 3.3 3.4 Project governance Project team structure Roles and responsibilities Project facilities and resources

Section 4. Project References Section 5. Glossary and Acronyms Appendix: Roles and Responsibilities Matrix Bibliography

Project Charter Guide

Introduction
This guide explains the steps needed to create a project charter for the delivery of a project. The guide is meant to be used together with a document called the Project Charter Template , and, where relevant, it includes examples to illustrate the content. The first section, titled "Use of the Project Charter," gives background information on the purpose of the charter, who is responsible for creating it, work that should be carried out beforehand in order to prepare the charter, how the charter should be customized, and key sections required at the beginning.

Use of the Project Charter

What is a project charter?
The project charter is a "document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities."[1] In addition to its contract purpose, the project charter includes most elements of a preliminary project scope statement, which describes what is and what is not included in the project. It also helps to control changes to the scope of the project througho ut its duration or life cycle. The intent is to cover, in a single document, all activities of the initiating process group[2] as defined in A Guide to the Project Management Body of Knowledge .

Why create a project charter?

As a comprehensive overview of the project, the project charter allows all parties involved (stakeholders) to reach agreement and document major aspects of the project such as the objectives, the scope, the deliverables, and the resources required. The charter supports the decision-making process and is also often used as a communication tool.

Who is responsible for the project charter?

The project charter should normally be developed by the project sponsor or a manager external to the project team. In practice, however, the project manager often plays a major role in the development of the project charter. The project manager works closely with the project sponsor, who provides background information for the project (e.g. purpose of the project and linkages to business needs, strategic priorities, objectives, and outcomes). The project manager also interviews stakeholders to gain more information in order to develop the charter.

How to create a project charter

This guide supports a template that was developed to highlight all standard elements that should be covered in the project charter to formalize a project. The template can be obtained at http://www.tbs-sct.gc.ca/emf-cag/index-eng.asp.

Project Charter Guide

This guide also contains a section called "Use of the Project Charter Template " that explains how to complete each topic covered in the template.

Tailoring the project charter to specific projects

Regardless of the size and type of project, the elements of a project charter are the same, just as the fundamental project management processes and principles remain the same. Although the depth and scope of applying these processes and principles may change from project to project, the project framework remains constant.

Adapting the project charter to the Treasury Board of Canada Secretariat's Project Complexity and Risk Assessment Tool
The project manager is expected to provide a comprehensive overview of the project in the project charter. The following table lists, in the left column, four classes of projects and suggests some areas to consider when developing a project charter, based on the results obtained through a risk assessment. This assessment would be contained in the business case for the project. To help with a risk assessment, a Project Complexity and Risk Assessment Tool is under development.

Sustaining Project

Description
The primary project goal is to sustain service from an existing asset by addressing aging components or deficiencies that limit its ongoing use. It is not a redevelopment. Negligible new capability or functionality added. Business-initiated changes are likely minimal. Scope confined to a single system or asset within a single program; one or few stakeholders.

Risk Considerations
Low to no requirements risk. Business changes are largely cosmetic e.g. a service enhancement or versioning updates. Business processes are essentially unchanged, although technology interfaces may be different minimal retraining is required at the business level. Minimal change management. Risks more likely associated with technology than business. Higher implementation risks in systems with demanding performance or availability (i.e. non-functional) characteristics.

Project Charter Guide

Project Charter Considerations

Scope definition and boundaries should be limited to a single system or asset within a single program. Usually one or few stakeholders. Prerequisites, assumptions, and constraints should address potential disruption to current operations. Deliverables should be expressed mostly in terms of updates to existing product, service, or result. Cost estimate should determine if the updates affect the ongoing costs (operation). Risks and interdependencies should include technology and implementation risks (such as parallel run or business disruption). "Project References" section should refer to a requirements document.

Tactical Project

Description
Usually driven by an immediate business need to deliver an additional capability, often within a limited time frame, or to position an existing asset for anticipated needs by adding capability. Capability added may be functional or non-functional. Scope may involve multiple systems, programs, or organizational entities (departments) but with a clear authority and a simple governance structure.

Risk Considerations
Changes and additions to business processes are required with small- to medium-scale change management. Effect is often localized to a specific segment of the business. Medium to high requirements risk and related risk of scope creep; development risk increases according to portion being redeveloped or added. Technology risk may be high if significant performance or availability (i.e. nonfunctional) enhancements required. Implementation risk medium, ranging to high if underlying technology base replaced.

Project Charter Guide

Project Charter Considerations

The charter and risks should show a greater progression in the level of project management from Sustaining to Transformational, i.e. identify more detailed considerations with increased complexity and risk to support project scope, time, and cost management requirements. Scope should clearly indicate the business processes that are affected. Time constraints should be documented. Interdependencies with multiple systems, programs, or organizational entities (departments) and consequent risks should be addressed. The governance and roles and responsibilities should be well defined. "Project References" section should refer to a requirements document.

Evolutionary Project

Description
Major changes and additions to capability, affecting business processes, job content, and service delivery model. Often a combination of business and technology evolution is involved. Some base components are reused to provide a working platform on which to add function. Scope may involve multiple systems, programs, entities, or jurisdictions and may overlap with client and business systems, requiring an appropriate governance structure.

Risk Considerations
High business risk due to significant change management and business process change. The more pervasive the effect of the solut ion across the business, the greater the risk. High requirements risk and related risk of scope creep, hence significant delivery risk. Governance risk proportional to number and diversity of stakeholder interests. Conversion and implementation risks likely to be high, including organizational change.

Project Charter Guide

Project Charter Considerations

Conversion and implementation activities should be visible in the schedule and cost estimates. Special attention should be paid to interdependencies between the project and business processes. Governance should be well documented. Roles and responsibilities of the stakeholders and the governance bodies should be described. Human resources strategy to address changes to the organization should be documented.

Transformational Project

Description
Project will change fundamentals about the way the business area works, such as processes, job content, organization, outsourcing, client and business involvement, and service model. Few if any existing components will be reused. Project likely spans organizational entities; may be multi-jurisdictional, involve multiple stakeholders, and require a complex governance structure.

Risk Considerations
Carries all the risks of the Evolutionary class of projects, further increased by the absence of any significant reuse. High to very high business risk due to project size; very high change management implications; and pervasive effect of change across the business. High to very high governance risk. High conversion and implementation risk, variable technology risk. Few if any risk mitigators are visible.

Project Charter Considerations

Interdependencies with processes, systems, and people should be documented. Significant risk contingency should be applied to the cost and effort estimates.

Project Charter Guide

The "Project Organization" section should be the object of particular attention. Project facilities and resources are often a consideration for Transformational projects. Interdependencies between the different stakeholders should be presented in the project governance section. The change management strategy should be described.

Organizational Project Management Capacity Assessment

At the time of the publication of this guide, a new tool called an Organizational Project Management Capacity Assessment was being test piloted with select government departments. Authors of a project charter will be invited to analyze the results of their organizations. In this assessment, the knowledge areas with the lowest scores, which indicate lower project management capacity, should be addressed in the project management plan. This will help to ensure that the project charter addresses any issues or concerns regarding the capacity of the organization to implement the project.

Use of the Project Charter Template

This guide explains how to complete the Project Charter Template and gives some insight into the content expected for each of the subjects listed in the template document.

Using this Template Document Purpose Section 1. Charter Introduction

Project Charter Guide

1.1 Document change control 1.2 Executive summary 1.3 Authorization Section 2. Project Overview 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Project summary Project goals, business outcomes, and objectives Project scope Milestones Deliverables Project cost estimate and sources of funding Dependencies Project risks, assumptions, and constraints

Section 3. Project Organization 3.1 3.2 3.3 3.4 Project governance Project team structure Roles and responsibilities Project facilities and resources

Section 4. Project References Section 5. Glossary and Acronyms

Section 1. Charter Introduction

1.1 Document change control
As any project unfolds, the project team gains more information and understanding about the project and its implementation. Consequently, the project charter may have to be adjusted as the scope of the project becomes more precise and the deliverables better understood. This section is used to document any changes and serves to control the development and distribution of revisions to the project charter. It should be used together with a change management process and a document management system. Document management procedures of the sponsoring organization should be applied to determine when versions and sub-versions must be created. This practice keeps an accurate history of the original document that was first approved.

1.2 Executive summary

This section should give a brief summary of the project in business terms, demonstrating alignment with the strategic objectives and vision of the organization or with related horizontal government init iatives. There should also be clear links between the project and the desired business outcomes stated in the business case, as well as with projects identified in the departmental investment plan.

Project Charter Guide

All projects, no matter how large or complex, are initiated in support of a departmental or organizational mandate and strategic priorities. The project charter should give the reader enough information to demonstrate that the project contributes to improving the ability of a program or a department to meet the needs of Canadians. What is the effect of the product or service on the clients of the program? The summary provides some background information on the project that includes the reasons for creating the project (e.g. business needs or legal requirements) and mentions the key stakeholders who will benefit from the project results. As well, the executive summary should cover the project charter and elements that require the approval of stakeholders, sponsors, or both, such as the project goals, project objectives, major milestones, key deliverables, primary risks, and estimated total costs.

1.3 Authorization
This section contains the signatures of the project sponsor or sponsors, the project manager, and other key project stakeholders, confirming that they agre e to their roles, the description of the project, and the project deliverables and outcomes presented in the project charter.

Section 2. Project Overview

2.1 Project summary
This section summarizes the entire project charter and highlights the significant points of interest to the reader. It typically covers project goals and objectives, major milestones, key deliverables, key risks, and estimated total cost.

2.2 Project goals, objectives, and business outcomes

This section describes the project goals and links each of them with related, measurable project objectives. Measurement criteria for each objective must also be included because they will be used to confirm that an objective has been achieved. In addition, business outcomes to be derived from the project goals and objectives are to be presented as outlined in the business case. Project goals are high-level statements about what the project is trying to accomplish. They are broad, general intentions and are typically intangible and abstract. Business outcomes are results expected at the end of the project. Outcomes can often be expressed in just a few words that describe a general aim. This information may be presented using the outcome map, which is a visual model that shows how a project and all of its activities contribute to the realization of the outcomes. Refer to the Outcome Management Guide and Tools on the Treasury Board of Canada Secretariat website at http://www.tbs-sct.gc.ca/emf-cag/outcome-resultat/outcomeresultat-eng.asp.

Project Charter Guide

Project objectives , in contrast, are concrete statements describing a particular desired outcome of the project. They are tightly bound to goals. Sometimes objectives represent steps toward achieving the goals. Measurement criteria are attributes of objectives and business outcomes that you can track over a period of time. They are used to confirm that an objective has been met. No. 1. Goals Greater flexibility in responding to stakeholder requests Objectives New online application form by end of fiscal year 200809 Measurement criteria: Online application form is in production by end of fiscal year 2009. Business Outcomes Client satisfaction Measurement criteria: Uptake of online capability by clients over a specified period of time against others means

2.3 Project scope

2.3.1 Scope definition

This section provides a high-level description of the features and functions that characterize the product, service, or result that the project is meant to deliver. It can include a reference to the business case. Include references like this in "Section 4: Project References" in the project charter. This section on scope definition is to give the reader a clear sense of what is being created by the project. Scope definition should also include additional information about the nature of the project, such as its physical location and legal context, the people and processes affected, and so on.

2.3.2 Boundaries
This section outlines the major activities required to successfully complete the project and describes each activity in a way that specifies what is and what is not included in the activity. While the "Scope definition" section describes the main characteristics of the product(s) or service(s) to be produced by the project, the "Boundaries" section gives a broader view. This section identifies activities that are "out of scope"; including these activities will greatly reduce ambiguity. It is especially important for projects that are multi-phased or part of a bigger picture (i.e. program or portfolio) to define what is being delivered in the undertaking covered by the charter.

Project Charter Guide

The boundaries of small-scale projects can be defined in terms of activities while the boundaries of larger projects may be defined in terms of work streams or subordinate projects. In Scope 1. Design a new business model for Program "X" 2. Develop a change management strategy Out of Scope 1. Building interfaces with corporate applications 2. Communication with external clients

3. Develop an online catalogue of services 3. Translation services

The table above is presented as an example. In many cases, further explanations may be required for a comprehensive presentation of the boundaries. The author may prefer to use the table as a summary and expand the description of each element in a narrative form.

2.4 Milestones
This section identifies the significant milestones or events in the project such as phases, stages, decision gates, or the approval of a deliverable. It presents a highlevel project schedule. Project Milestone Phase 1: Documenting Business Requirements Description Date

Translation of the requirements document into technical specifications for the building of a new yyyy-mm-dd water facility for a community Request for proposal completed, winning bidder selected, and contract awarded by Acquisition yyyy-mm-dd Branch Assessment of the alternative system delivery model yyyy-mm-dd

Phase 2: Contract award Phase 3: Maintenance Delivery

2.5 Deliverables
This section defines the key deliverables that the project is required to produce in order to achieve the stated objectives. It also includes internal project deliverables that are required in the project management process for review and approval (e.g. project plan, transition plan, communication plan, and lessons learned).

Project Charter Guide

The deliverables identified in this section could be used to develop the top levels of your work breakdown structure, which "subdivides the major project deliverables a nd project work into smaller, more manageable components."[3] The criteria that will be used to assess the quality and completion of each deliverable should also be included. Deliverables Project Deliverable Description: Acceptance criteria: Due date: Description A common form and guide to annually report financial and production data with income tax return Single window; one application form yyyy-mm-dd

2.6 Project cost estimate and sources of funding

2.6.1 Project cost estimate

This section summarizes cost estimates based on the project resources (human, material, and financial) that are needed to produce the deliverables and meet the agreed-upon objectives. The cost estimates from the business case can be used as the basis for this summary. Itemize and break down the costs by project stage or phase and show multi-year projects by fiscal year. The estimate identifies other costs driven by the project in order to support decision making. Categories such as salaries and operations and maintenance (O&M) should include the A-base funding in addition to the project specific funding. The intent is to document the full cost of the project. Ongoing costs are those that are permanently required for operations as a result of the project (e.g. additional support, licenses, and hardware maintenance). While not technically considered pure project costs, ongoing costs provide valuable information for decision making. One-time costs can include non-recurring purchases needed for project administration and preparation for gating processes. For more information on the costing process, please refer to the Guide to Costing at http://www.tbs-sct.gc.ca/pubs_pol/dcgpubs/TBM_133/guide_e.asp. Project cost estimate Project Phase Deliverable or Cost Category Estimated Cost FY(1) Estimated Cost FY(2) Estimated Cost FY(3) Estimated Cost FY(4)

Project Charter Guide

(Phase 1/ Deliverable) Salary O& M Professional services Capital Other (e.g. revenue) Subtotals (Phase 2/ Deliverable) Salary O& M Professional services Capital Other (e.g. revenue) Subtotals TOTAL

2.6.2 Sources of funding

This section outlines the various sources of funding that will be used to support the project. It should be clear to the project sponsor and the project manager where the funds come from and the level of resources committed to this project.

2.7 Dependencies
Many projects depend on external factors, whether within or outside the organization, such as the following: A predecessor or successor relationship exists with another project (e.g. an MOU or partnership); A related project expects a deliverable from your project; Your project expects a deliverable from a related project; or

Project Charter Guide

Your project delivers a product, service, or result that will be or needs to be released with another new product, service, or result.

If any situations like this exist, it is important to identify these relationships early. If you expect to have several interactions with the project managers of related projects, include corresponding information in the "Roles and responsibilities" section under "Project managers for related projects." Also, all dependencies should be listed and analyzed in the "Risks" sect ion to ensure monitoring and allow response to a risk as required. If this project is part of a program, the program charter may contain this information. The related project information should be included here or may be referred to in the program charter. This reference should be noted in "Section 4: Project References." For each related project, add an entry to the table below. In the dependency description, specify the organization or stakeholder that should be kept informed of the project's progress. If there are no related projects, this should be mentioned in the form of a generic statement. Dependency Description Critical Date Contact

2.8 Project risks, assumptions, and constraints

2.8.1 Risks
This section outlines the risks identified at the start of the project. It includes a quick assessment of the significance of each risk (probability and effect) and how to address them. It is important to note that this initial risk assessment does not replace the full risk assessment conducted during the planning phase and documented within the project plan. More information and tools are included in the Project Plan Template at http://www.tbs-sct.gc.ca/emf-cag/index-eng.asp and the Integrated Risk Management Implementation Guide at http://www.tbssct.gc.ca/pubs_pol/dcgpubs/RiskManagement/siglist_e.asp. Project risk assessment No. 1. Risk Description Business owners may not be available during validation phase; this may affect the schedule. Probability Effect (H/M/L) (H/M/L) M H Planned Mitigation Resources have been secured with the manager of related divisions. A supply arrangement is in place to provide testers on a casual basis. Statement of

Project Charter Guide

work is ready. 2. Training manuals may not be ready by planned training date; this may affect the schedule. M M Wikis will be used as an alternative solution to publish essential training material.

2.8.2 Assumptions
This section specifies all factors that are, for planning purposes, considered to be true, real, or certain but without including proof. During the planning process, these assumptions will be validated. If any assumptions are inaccurate, inconsistent, or incomplete, they will create project risks and may adversely affect project scope, timeline, and cost. The following table lists the items that cannot be proven or demonstrated at the time of publication but are documented to stabilize the project approach or planning. No. 1. 2. 3. The following is assumed: Release of funds will be timely to pay for contractors. Current service levels to stakeholders will be maintained throughout the project. Privacy Impact Assessments (PIA) will be completed in time as an input to the architectural system design.

2.8.3 Constraints
This section identifies the specific constraints or restrictions that limit or place conditions on the project, especially those associated with the project scope such as a hard deadline, a predetermined budget, a set milestone, contract provisions, or privacy or security considerations. The constraints can come from external factors (social, environmental, political, economic, and technological) or internal factors (resources, expertise, business requirements, legal requirements, facilities, and so on). In order to identify constraints, it is necessary to analyze the project environment. If there are several constraints, they should be classified by category. The following table lists examples of the fixed or pre-set factors that the project must respect: No. Category Constraints

Project Charter Guide

Deadline (time) Legal The online registration service must be available for the 2008 09 campaign starting on October 23, 2008. The online registration service must meet the requirements of theCanada Water Act . End-user will not be available for testing during February and March 2008.

1.

2.

3.

Resources

Section 3. Project Organization

3.1 Project governance
A project organization is a structure that is created or evolves and is intended to serve the project and its participants. It refers to the roles and responsibilities of the project team and it interfaces with all stakeholders. A key ingredient of the project organization is the creation of project governance. Figure 1 presents an example of the bodies that could be applied for decision making and escalating issues. The governance structure should be designed to give the project grounded and its business outcomes focus and to ensure regular reviews of project risks and issues, including changes to scope, schedules, and costs. Keep in mind, however, that these project components, including project scope, schedule, costs, and supporting processes, will be covered more extensively in the Project Management Plan. Figure 1: Project Governance Diagram

Figure 1 - Image description

3.2 Project team structure

Figure 2 illustrates the structure of the project team and stakeholders . For small projects, the names of the team members can be included; for larger projects, the chart should name the groups or entities that form the project teams. For all projects,

Project Charter Guide

the names of the project sponsor, project director or manager, and specialis ts should be clearly identified. A human resources strategy should be developed and included in the project charter if there are any clearly identified key positions that are vacant and must be filled for a successful project delivery. The purpose of the strategy is to address any potential staffing-related risks before the start of the project. The establishment of the project team is an important success factor. Information on a number of the skill sets required for key roles in project management can be found in theTreasury Board of Canada Secretariat's IT Community Generics Resource Centre at http://www.tbs-sct.gc.ca/oro-bgc/it/generics/index-eng.asp. Figure 2: Sample of Project T eam Organizational Chart

Figure 2 - Image description

3.3 Roles and responsibilities

This section defines the roles and responsibilities assigned to the project team members and any stakeholders or working groups that have a significant influence on the project. All stakeholders, working groups, and committees shown in the sections "Projec t governance" and "Project team structure" should have their roles and responsibilities identified. Another way to present this information is to combine the organization of the project team with its members roles and responsibilities in a responsibility matrix. This matrix identifies accountability for each key deliverable.

Project Charter Guide

An example of roles and responsibilities assigned to the project team members is presented in the Appendix to this document.

3.4 Project facilities and resources

Depending on the size and complexity of the project, the need for facilities and material resources such as office space, computer equipment, office equipment, and support tools can involve significant effort and costs. This section describes the project's requirements for such facilities and resources. It also identifies responsibilities for obtaining the specific items needed to support the project's development environment. Project facilities and resource costs should be included in section 2.6.1, "Project cost estimate." If these costs are significant , the activities involved in procurement and logistics activities should be documented as internal deliverables in section 2.5, "Deliverables." The risks associated with project facilities and resources should also be considered.

Section 4. Project References

This section describes and identifies the location of key documents that define and establish the project (e.g. business case, departmental investment plan, departmental long-term strategy, requirements document, outcome management plan,[4] outcome map, Speech from the Throne, Cabinet directions, and horizontal government initiatives). Project References Document Title Business Case Version No. 1D Date 200803-20 Author and Organization Chief Information Officer Branch (CIOB) Location (link or path) Y:\CIOB\Template

Section 5. Glossary and Acronyms

This section defines all the terms and acronyms needed to interpret the project charter properly. Most definitions come from the third edition of the Project Management Body of Knowledge Guide of the Project Management Institute. Initiating Processes Those processes performed to authorize and define the scope of a new phase or project or that can result in the continuation of halted project work. Sponsor The person or group that provides the financial resources, in cash or in kind, for the project. Stakeholder Persons and organizations such as customers, business owners or program managers, performing organization and the public that are actively involved in the project or whose interests may be positively or negatively affected by the

Project Charter Guide

execution or completion of the project. They may also exert influence over the project and its deliverables. Work Breakdown Structure (WBS) A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work. The parts of the WBS consist of work packages. The deliverables orientation of the hierarchy takes both internal and external deliverables into account.

Appendix: Roles and Responsibilities Matrix

Roles and Responsibilities Matrix Project Role Project sponsor Responsibilities Has ultimate authority over and is responsible for a program, project, or both Approves changes to the scope and provides whatever additional funds those changes require Approves budget-related deliverables Controls the business aspects of the project Assists in developing the project charter and project plans Executes formal reviews and management reviews Disposes of issues and change requests Makes user resources available Approves work products Assists in tracking action items and budgets Is responsible for the functional quality of the solution Controls the day-to-day aspects of the project Develops and maintains the project charter and project plans Executes formal reviews and management reviews Tracks and disposes of issues Helps resolve issues and change requests Tracks action items and budgets Is responsible for the quality of the product or service Coordinates all project training Keeps related project managers aware of changes in project scope Executes formal reviews and management reviews Tracks and dispose of intra-project issues Tracks intra-project action items Coordinates all intra-project training Assigned to Resource Name(s)

Project manager Project manager of a related project

Resource Name(s)

Resource Name(s)

Project Charter Guide

Team leader Manages one or more functional aspects of the Resource project Name(s) Helps project managers with formal reviews and management reviews Helps research issues and change requests Helps the project manager create the work breakdown structure for his or her functional area Helps the project manager develop the scope and estimates for his or her functional area Maintains the scope, estimates, and work plans for his or her area Tracks action items related to his or her functional area Ensures the proper reporting of status by his or her team members Is responsible for the technical quality of the product or service assigned to his or her functional area Coordinates all procurement and contract management activities Liaises and coordinates with the contract authority of Public Works and Government Services Canada Provides the financial information needed to manage the project Helps the project manager to define the project budget, estimates, and allocation Helps the project manager with the tracking and reporting of costs and expenditures against project budget Documents and maintains models of business requirements Documents and analyzes business processes using value-added or non-value-added, process modelling tools, cost -time charts, and root cause analysis Ensures effective communications about the project across the whole organization Helps the project teams create a quality management approach and plan Provides support to the project sponsor and project manager Assists in developing divisional implementation plans Establishes standards (where necessary) for tool usage and project management Reviews project performance Exhibits the highest level of expertise in performing a specialized job, task, or skill Resource Name(s) Resource Name(s)

Business area team leader Procurement officer

Financial officer

Business analyst

Project management office

Resource Name(s)

Subject matter expert (SME)

Resource Name(s)

Project Charter Guide

within the organization Understands a business process or area well enough to answer questions from people in other groups Explains the current process to the project team and then answers their questions Has in-depth knowledge of the subject Represents the users area in identifying current or future procedures Approves project investments Reviews the business rationale, projects, and resources Prioritizes projects based on specific criteria Resolves all cross-project issues Reviews all cross-divisional issues Discusses and resolves issues that cannot be resolved by the project team Reviews all budget-related information regarding deliverables for the project Is responsible for organization-wide communications Provides guidance and mentoring to the project sponsors, project manager, and teams Ensures that requirements of the business are adequately represented to the individual projects Represents all affected business areas as determined by the project sponsor and project manager (the executive sponsor extends invitations to members) Reviews and makes recommendations on scope changes Monitors project progress Resource Name(s)

Senior review board Executive steering committee

Resource Name(s)

Bibliography
Canada. National Defence (page accessed on April 10, 2008). "Project Organization" inMateriel Acquisition and Support Information System (MASIS) [Online], http://www.forces.gc.ca/admmat/masis/ipt_e.asp. Canada Revenue Agency (2008). Project Charter Template , Ottawa, Information Technology Branch, Version 1.4, February 18, 2008. Public Works and Government Services Canada (2007). A Guide to ITSB Project Management Process , Ottawa, Information Technology Branch, Project Management Office. Public Works and Government Services Canada (2007). ITSB Project Management Template , Ottawa, Information Technology Branch, Project Management Office.

Project Charter Guide

Treasury Board of Canada Secretariat (2008). Guide to Costing, Ottawa. Also available online at http://www.tbs-sct.gc.ca/pubs_pol/dcgpubs/tbm_133/guide. Treasury Board of Canada Secretariat (1996). An Enhanced Framework for the Management of Information Technology Projects, Ottawa, Chief Information Officer Branch. Treasury Board of Canada Secretariat (2004). Business Transformation Enablement Program: A Template for Project Chart er , Ottawa, Chief Information Officer Branch. Also available online at: http://www.tbs-sct.gc.ca/btep-pto/documents/2004/templates-gabarits/chartermandat/charter-mandattb. Treasury Board of Canada Secretariat (2006). Outcome Management Guide and Tools , Version 1.0 for discussion purposes only, Ottawa, Chief Information Officer Branch. Treasury Board of Canada Secretariat (2007). Oversight Improvement Submission Processing: Alignment and Stewardship Evaluation Criteria , draft version, Ottawa, Chief Information Officer Branch. Treasury Board of Canada Secretariat (2007). "Improving IT Project Performance: Conception, Assessment and Monitoring," Ottawa. Treasury Board of Canada Secretariat (page accessed on October 11, 2007). Policy on the Management of Projects in the Treasury Board of Canada Secretariat [Online], http://www.tbs-sct.gc.ca/pubs_pol/dcgpubs/TBM_122/mp-gp. Treasury Board of Canada Secretariat (page accessed on October 11, 2007). Policy on Investment Planning Assets and Acquired Services in the Treasury Board of Canada Secretariat [Online], http://www.tbs-sct.gc.ca/pubs_pol/dcgpubs/TBM_122/ipaaspiasa. Treasury Board of Canada Secretariat (page accessed on October 11, 2007). Standard for Organizational Project Management Capacity in the Treasury Board of Canada Secretariat [Online], http://www.tbs-sct.gc.ca/pubs_pol/dcgpubs/TBM_122/sopmc ncogp. Treasury Board of Canada Secretariat (page accessed on October 11, 2007). Standard for Project Complexity and Risk in the Treasury Board of Canada Secretariat [Online], http://www.tbs-sct.gc.ca/pubs_pol/dcgpubs/TBM_122/spcr-ncrp-e.asp. Gartner (2007). Gartner for IT Leaders Tool: Developing a Project Charter , USA, Gartner Inc., p.10. Government of British Columbia (page accessed on October 8, 2007). Project Charter Standards in Ministry of Environment, Information Management Branch [Online], http://srmwww.gov.bc.ca/imb/3star/project_mgmt.ht ml. Information Technology CIO Executive Board (page accessed on October 12, 2007).Corporate Executive Board website [Online], https://www.cio.executiveboard.com/Public/Default.aspx.

Project Charter Guide

Kerzner, Harold (2003). Project Management: A Systems Approach to Planning, Scheduling, and Controlling, Eighth Edition, Canada, John Wiley & Sons Inc. Office of Government Commerce (page accessed on October 15, 2007). Office of Government Commerce website [Online], http://www.ogc.gov.uk. Office of Government Commerce (page accessed on October 16, 2007). Governance , in Office of Government Commerce [Online], http://www.ogc.gov.uk/delivery_lifecycle_governance.asp. Project Management Institute (2003). The PMI Compendium of Project Management Practices, Pennsylvania, Project Management Institute. Project Management Institute (2004). A Guide to the Project Management Body of Knowledge , Third Edition, Pennsylvania, Project Management Institute. Project Management Institute (2006). Government Extension to the PMBOK Guide , Third Edition, Pennsylvania, Project Management Institute. Texas Department of Information Resources (page accessed on October 18, 2007).Project Charter Instructions in Texas Department of Information Resources [Online], http://www.dir.texas.gov/pubs/framework/gate1/projectcharter/instruction.pdf. University of Notre Dame (page accessed on October 18, 2007). Project Charter Template in the University of Notre Dame [Online], http://www.educause.edu/ir/library/pdf/MWR0316.pdf.

1. Project Management Institute (2004). A Guide to the Project Management Body of Knowledge , Third Edition, p. 368. 2. Those processes performed to authorize and define the scope of a new phase or project or that can result in the continuation of halted project work. 3. Project Management Institute (2004). A Guide to the Project Management Body of Knowledge , Third Edition, p. 103. 4. Also referred to as "benefits realization" or "value management" plan.