Guide to a Project Brief

Provides guidance in the form of headings, examples and descriptions on the level and type of information required in a project brief by the Treasury Board Policy on the Management of Projects.
Date modified: 2014-03-31

More information

Policy:

Hierarchy

Print-friendly XML

Introduction and Purpose

Under the Policy on the Management of Projects, when Treasury Board approval is required for either project approval (PA) or expenditure authority (EA), including amendments to a PA or an EA decision, a project brief must be appended to the Treasury Board submission.[1] For guidance on PA or EA and the Treasury Board submission process, please refer to the 2014 Guidance for the Preparation of TB Submissions.

A project brief ensures that Treasury Board ministers or the department's approval authority have a thorough understanding of the proposed initiative by providing additional detail and/or context not in the Treasury Board submission. The project brief is an iterative document that progressively reflects the state of the project with each update and shows the relationship between the project, government priorities, departmental priorities, and long-term strategic planning objectives and outcomes.

In accordance with the Policy on the Management of Projects, a project brief is to be supported by a business case, project charter and project management plan. The project brief contains a synopsis of the key components of these core project documents and provides a concise but complete description of the scope of the project, permitting the Treasury Board submission to be as succinct as possible.

Departments are encouraged to update their core project documents, and subsequently their project brief, at regular and meaningful intervals throughout the life-cycle of the project[2]. Although these intervals could coincide with Treasury Board decisions, the timing of Treasury Board submissions should not be the determining factor for ensuring that current information is available to decision makers. Each time the project brief is submitted to the Treasury Board, reconciliation with the previous Treasury Board decision should be apparent in the project brief.

Appendix B of the Policy on the Management of Projects lists the required content of a project brief. The Guide to a Project Brief has been designed to provide guidance on the level and type of information required in a project brief by the policy. The Guide aligns with those requirements and includes additional guidance in the form of headings, examples and descriptions. The structure of the Guide to a Project Brief follows that of Appendix B and is intended to ensure the completeness of the required content. Excerpts from Appendix B are included throughout the Guide.

It is important to note that the Guide is provided as guidance and that the content of the project brief may be tailored to better reflect a particular project. Departments are encouraged to consult with the Treasury Board of Canada Secretariat about the content of their project briefs.

1. Project Description

This section provides a brief high-level summary of the important details of the project.

4.2 The level of service or capability to be developed, accessed or improved and a general description of the good or service and the program outcomes to be achieved.

1.1 Project Background

This section presents a high-level description of the project’s history, a summary of any relevant Cabinet or Treasury Board decisions, any project approval (PA) and expenditure authority (EA) decisions or conditions, including the Treasury Board Number and the appropriate date, and the general context of the initiative’s progress in terms of any Cabinet decisions or other key decision points.

1.2 Description of Service or Capability

It is critical to position the proposed project or project phase in the context of the identified program requirement and the full investment proposal.

This section provides a description of the service or capability that the project intends to develop, create or improve, as well as the benefits that are to be derived and how that service or capability will be managed once the solution is in place at project closeout. In the context of the definition of a project, in accordance with the Policy on the Management of Projects, the service or capability is the defined output that the project is required to produce.

1.3 Project Scope

Project scope can be defined as the work that needs to be accomplished to deliver a product, service or result with the specified features and functions.[3] This section describes the project scope in terms of a scope statement. Depending on the maturity of the project, this can be either the preliminary scope statement at the early stages of a project’s life-cycle or a more detailed scope statement that is the basis for future project decisions. The scope statement should be fully articulated and detailed in a project document. This document should be the source document for the content of this section and appropriately referenced.

The scope statement should address a number of key factors (refer to the PMBOK® Guide), the key activities and outputs, and any significant performance criteria. The presentation of scope is to align with the key deliverables and planned phases of the project.

In addition, this section should include a description of how the scope was developed, including the requirements determination, a scope definition in response to the defined requirements, and a summary of the key deliverables from the work breakdown structure.

A table may be used to present what is in and out of scope for the project. The table below provides an example output and a succinct description of the scope.

Project Output Description

Financial Reporting Form

A common form and guide to annually report financial data with an income tax return.

1.4 Project Cost Estimates and Sources of Funds

This section presents the approved sources of funds and either a total indicative cost estimate or substantive estimate for the entire project. Project cost estimates for PA are likely to be at an indicative level, and include all activities and project deliverables from the project definition phase through to project closeout. In accordance with the Policy on the Management of Projects, and 2014 Guidance for the Preparation of TB Submissions, the cost estimate for EA is to be substantive in nature and can only be sought for phases of the project that have been appropriately defined and assessed using the Project Complexity and Risk Assessment (PCRA) Tool.

Sources of Funds

In this section, the sources of funds are identified and all assumptions and constraints related to funding are clearly described.

Project Cost Estimates

The Secretariat’s Guide to Costing has been developed to advance stewardship, accountability, and value for money across the Government of Canada. Departments are encouraged to prepare the cost estimates for all Treasury Board submissions using the Guide to Costing, and to present the cost estimates for all Treasury Board submissions using the Guide to Preparing TB Submissions.

The following are considerations for inclusion in articulating the project cost estimates in a project brief.

  • Estimated project costs are provided at a level of detail that provides assurance that detailed costing due diligence was performed. This will include a description of the costing methodology, references to source documents, and a statement on whether the cost estimates presented are substantive or indicative in nature.
  • Costing is detailed, at a minimum, by project phase (e.g., definition, implementation, closeout), as well as by fiscal year if the project spans fiscal years. To fully substantiate the cost estimate provided, costing is to be further detailed by each defined work package or project stage and tied to a discrete project deliverable (output). For those phases of the project for which the organization is seeking EA, the sponsoring department must clearly demonstrate that the estimates supporting this request are substantive in nature.
  • For projects spanning more than a single fiscal year, project costs are to be presented in both current and constant dollars. The annual escalator and its source and appropriateness to the project must be clearly articulated.
  • Salary costs are included to reflect the organization’s practice for attributing salary costs to projects. A brief description of the practice and these estimated costs are clearly highlighted. The Guide to Costing provides more information.
  • Costing, which covers the full life-cycle of the recommended investment option, is also presented. The TBS Guide to Management of Materiel defines the phases of life-cycle management as: assessing requirements; analyzing options; planning acquisition; acquiring; operating, using, and maintaining; and disposing and replacing. This cost estimate is to be prepared in accordance with departmental standards and processes for developing a total investment life-cycle cost estimate. The investment life-cycle will include the project life-cycle (i.e., activities required to produce the project output) and the operations, use and maintenance costs covering the useful life of the proposed project output. This information is to reflect the detailed options analysis considered in the business case, which is to be referenced.
  • Costing information is to include a list of assumptions and exclusions, and risk and contingency broken down as appropriate by deliverable, phase and work package.
  • For projects involving more than one department, costing tables are to be developed to provide a full project costing estimate, including costs incurred by all contributing partners, including non-federal partners.
  • The reference documents and methodology used to derive the project cost estimates are described.
    • For example: “The Guide to Costing was used to develop all cost estimates presented, in close collaboration with the CFO. Further details on the cost estimate are available in the Project A cost estimation document, approved on January DD, YYYY. These estimates were based on Project B, which was closed out on December DD, YYYY. A workshop with all key stakeholders was held, and the findings were documented in the cost estimation document. A quantity surveyor and professional costing firm were then engaged, and the relevant costing documents are referenced.”
  • A table may also be useful in presenting the cost estimates.

1.5 Project Schedule

A high-level project schedule summarized for Treasury Board ministers is presented in this section. The schedule reflects a documented and authoritative project schedule and baseline and includes:

  • Milestones and key project outputs (i.e., deliverables);
  • Checkpoints within the project governance hierarchy, including the department and the Treasury Board of Canada Secretariat (the Secretariat);
  • Details on implementation planning; and,
  • Project gates at which consideration by Treasury Board ministers will be relevant.

A project gate is a key decision and control point that occurs before the next major milestone or project deliverable or a new project phase (e.g., implementation) begins. The gate represents a logical point at which executive "gatekeepers" can determine whether and how to proceed. Project gates effectively "open" or "close" the path leading to a subsequent project phase. The project gate schedule is developed to fit the needs of the project and to identify to the Treasury Board at which gates the project will seek EA.

4.7.1 The estimated schedule from project inception to completion of the project. At a minimum, Treasury Board approval is sought to endorse the strategic assessment and to further refine the business justification and implementation strategy in advance of implementation.

1.6 Assumptions

This section describes all assumptions relevant to the project, explains the possible impacts and considerations of these assumptions, and outlines any strategies for addressing assumptions that do not materialize.

1.7 Constraints

All specific constraints or restrictions that limit or place conditions on the project are described in this section. The description includes dependencies on common service providers and other stakeholders, or a limited time frame for developing and implementing the proposed project or project phase when applicable. Potential impacts are explained and quantified whenever possible, and strategies are described for managing these constraints.

2. Policy and Program Linkage

This section provides a description of the links between the project outcomes and the mandate and programs of the sponsoring department, as well as to other government-wide objectives. The department’s Program Alignment Architecture (PAA) usually supports this explanation. (Visit the Secretariat’s website for more information on the PAA.)

4.1. The relationship of the project outcomes to the sponsoring department's mandate, programs and to government-wide objectives.

2.1 Project Goals and Business Outcomes

The goals and expected business outcomes or benefits of the project are described in this section.

Project goals are high-level statements about what the project is expected to accomplish.[4] Project goals are broad, general intentions and are typically intangible and abstract. An example of a project goal is “greater flexibility in responding to stakeholder requests.”

Business outcomes can be used to articulate the value of the initiative. In an organizational context, an outcome involves an intentional change (people, processes, technology) being imposed on the system, with a resulting end state that can be measured.[5] Examples of business outcomes are “decreased inspection time” and “increased public confidence.”

It is recommended that departments articulate business outcomes over the life-cycle of the project and tie the measurement of intermediate outcomes to the proposed gating model for the project so that outcome realization is being reviewed at key “go” and “no-go” decision points.

As the brief is to enable decision makers to fully understand the proposed initiative, it is important that the project’s expected business outcomes be clearly articulated in commonly understood terms. Decision makers must also be informed of the criticality of the proposed project.

Specifically:

  • What is the business outcome?
  • Why is the specific business outcome needed?
  • Why is the project to deliver the business outcome needed now? (i.e. What are the consequences of not going forward with this proposed solution now?)
  • Two examples of a description of a project and its business outcomes are included as an annex to this guide.

2.2 Mandate

This section briefly describes the mandate of the sponsoring department and any partnering departments in a joint project, along with any branches, if applicable, and relates the business outcomes to each relevant mandate.

2.3 Alignment with Program

This section describes the program outcomes to be supported by the end result of the project and explains how the achievement of project goals will enable the intended program outcomes.

Where possible, the degree of alignment with the department’s PAA and Management Resources and Results Structure (MRRS) should be articulated.

2.4 Alignment with Government-Wide Priorities

This section, when applicable, describes linkages with other public sector programs and projects (e.g., federal, non-federal, provincial, municipal, First Nations) and how this project solution supports broader government-wide priorities.

3. Link to the Investment Plan

This section clearly positions the project, as part of an investment, within the departmental investment plan.

4.3 The significance of the project in the context of the department's investment plan.

The importance and magnitude of the project as part of an investment and how it supports and aligns with other investments included in the investment plan are described. The project proposal should be consistent with the project information in the investment plan and should describe the total estimated life-cycle costs of the entire investment. This includes both the project required to produce the defined outcome or product, and the subsequent operations, maintenance and disposal, if applicable, of that outcome or product. The plan should clearly confirm the affordability not only of the proposed project but also of all ongoing (i.e., life-cycle) costs of the entire investment.

If the project was not in the most recent investment plan provided to the Secretariat and/or the Treasury Board, this section includes an explanation of what caused the change (e.g., additional funding provided through a Cabinet decision or a change in priority) and a brief description of the incremental capacity needed to deliver this new, unplanned project. Departments should also confirm that departmental operations remain affordable and sustainable over the long term.

4. Performance Management

This section describes the project’s performance management and outcome management measures.

4.5 The performance and outcome management measures, including an evaluation strategy and provision for an independent third-party evaluation when required.

4.1 Business Outcome Management Strategy

In any performance management framework, it is critical to adequately define the expected outcomes at the outset. This section provides a description of the strategy for measuring, monitoring, reporting and managing the business outcomes described in Section 2 of the project brief. The measurement of any intermediate outcomes, in accordance with the proposed gating model for the project, is articulated so that outcome realization is reviewed at key “go” and “no-go” decision points over the project life-cycle.

An outcomes register may be used to present the outcomes and the associated measures.

4.2 Project Performance Management Strategy

This section provides a description of the integrated and disciplined approach to managing project performance and results. It also includes a succinct explanation of how project progress will be monitored and tracked in terms of the project performance metrics associated with cost, schedule, scope and any other critical objectives.

In addition, this section includes the strategy outlined in the Project Management Plan and aligns the strategy with the project schedule (refer to the Guide to Project Evaluation and Close-out Reports[6] for more information).

4.3 Audit and Evaluation Strategy

This section presents a detailed audit and evaluation strategy for the project, including any provisions for independent third-party evaluations, reviews or audits as and when required. This section also addresses when and at what phases of the project life-cycle monitoring and reporting activities are planned. All planned reporting to the project authority (i.e., Treasury Board or the sponsoring minister) is included, at a minimum. Relevant reporting to the Secretariat and other stakeholders is also described.

5. Project Options Analysis

In considering any project delivery option, it is important for the sponsoring department to recognize that the project life-cycle is only a subset of the investment life-cycle. The decision to proceed with a particular project solution is expected to consider the full implications of that decision over the entirety of the investment. The direct comparison of different investment options and the resulting cost-benefit analyses support the planned investment and the project proposal. For example, the decision to acquire an asset must consider, at a minimum, all applicable costs directly attributable to that asset over its entire useful life.

For instance, an acquisition decision that is based on the lowest purchase price but that ignores potential operations and maintenance costs may result in higher overall costs. Decision making in life-cycle management is an iterative process that considers all phases of an asset's life cycle, at key points throughout its life cycle. Effective management requires that an appropriate level of management interest and control be maintained throughout the investment's life cycle.

Although the project may be affordable on its own, the continued affordability of the entire asset portfolio as well as departmental operations must be confirmed in accordance with the Policy on Investment Planning – Assets and Acquired Services before the project can be approved.

This section summarizes each of the considered viable options, including at a minimum the status quo and the recommended option.

When describing the project options, Treasury Board ministers must be assured that the proposed investment is affordable over the entire life-cycle. For example, once the project to acquire the use of an asset is approved, the government begins to spend resources; once the asset is operational, there can be legal obligations and the government is committed financially. The project’s business case provides an analysis of investment options to achieve the intended business outcomes based on life-cycle cost estimates, likely future conditions, relevant risks, impacts, and life-cycle management issues. The recommended project option supports the recommended investment option in consideration of the cost-benefit of the investment over its entire life-cycle. Therefore, when articulating project options, it is important to ensure alignment with, and support of, the investment plan and the affordability of the investment, not just the project.

4.6 The business case reflecting the results of benefit-cost and options analyses and a description of each option considered. Comparison of options should be based at a minimum on a preliminary asset life-cycle cost estimate for each. Any strategic direction that has been given approval-in-principle or that limits available options should be provided.

In accordance with Appendix B (Section 4.6) of the Policy on the Management of Projects, the options analysis summary captures the specific required details of the business case. However, the summary is not repeated verbatim in this section.

4.6.1 Business cases are to be prepared according to standards or guidance issued by the Treasury Board Secretariat.

5.1 Methodology

The methodology used to screen, assess and compare options and select the recommended option is described in this section, including a summary of each option that was considered. In accordance with the Appendix B (Section 4.6) of the Policy on the Management of Projects, the options analysis is to be based, at a minimum, on preliminary life-cycle cost estimates for each investment option.

In considering viable project options that will deliver the solution or output needed to achieve the defined outcomes, it is important that each project option be considered as part of the total life-cycle of the investment. This ensures that the cost-benefit analysis considers the entire investment resulting from the project being approved.

Should the activities and resources required to operate, maintain and dispose of the project outcome or solution be precisely the same, irrespective of each option considered, this should be clearly noted and those cost estimates articulated in this section.

5.2 Option 1 - Maintain Status Quo

A succinct description of the status quo option is provided in this section.

The Secretariat’s Business Case Guide describes the status quo option as the base case. Status quo shows how an organization would perform if it did not pursue one of the investment proposal options or otherwise change its method of operation.

5.3 Option 2

This section provides a description of the considered investment option, including the full life-cycle cost estimate. It should also include a brief description of the rationale for choosing this option; what was considered in the decision-making process (e.g., a public-private partnership (PPP) option was considered and screened in consultation with PPP Canada) and how this option is linked to the achievement of the intended outcome.

5.4 Option 3

This section provides a description of the considered investment option, including the full life-cycle cost estimate; a short description of the rationale for choosing this option; what was considered in the decision-making process (e.g., Crown construction and outsourced operations and maintenance were considered), and how this option is linked to the achievement of the intended outcome.

5.5 Public-Private Partnerships

As stipulated in Budget 2011, federal departments are required to assess planned investments for PPP potential. Planned investments that consider the creation of an infrastructure asset with a capital cost of $100 million or more and with a useful life of at least 20 years must include a screening of the entire investment life-cycle, in consultation with PPP Canada, to determine the viability of a PPP. The results of the screening are to be presented in the project brief.

Departments are also encouraged to explore the potential of PPPs for other types of investments in assets and acquired services when there is demonstrated value.

To assist departments, the Secretariat has developed the Guideline to Implementing Budget 2011 Direction on Public-Private Partnerships.

5.6 Justification and Recommendation

This section identifies the preferred option and demonstrates why the option is deemed preferable over all others. This includes a summary of a thorough cost-benefit analysis fully documented in the business case.

6. Project Management Plan

A summary of the project management plan is provided in this section. A project management plan defines the planned objectives and outcomes of the project, and establishes the scope, work breakdown structure, budget, schedule, risks, roles, resources, functional strategies, project monitoring and control strategies, governance, process deviations and management approach. This section supports the proposal to the project approval authority and establishes the baseline for the project reflected in the project charter, against which changes and performance are measured and reported.

6.1 Project Review and Gating Strategy

This section describes the project gating strategy, incorporating any planned independent third-party evaluations, reviews or audits. A project gating strategy ensures that resource implications and results are made fully visible to the project approval authority at logical, predetermined checkpoints or "project gates."

As stipulated in Appendix B of the Policy on the Management of Projects, the project gating strategy articulates off-ramps linked to specific, identified project gates, allowing the project approval authority the option to end the government’s involvement if required and at appropriate decision points.

4.7 The segmenting of the project into gates, the proposed phased approach to managing changes and the opportunities for terminating federal involvement.

Treasury Board Secretariat Consultation and Treasury Board Reporting

This section provides a summary of proposed Treasury Board and Secretariat engagement and reporting aligned to the project gating strategy and over fiscal years when the project spans multiple years. For example, for large and complex projects, it may be determined that the most effective way to ensure that the Treasury Board is appropriately informed is through annual status reports and regular updating of the PCRA shared with the Secretariat.

4.8 The proposed timing of reports to Treasury Board and future submissions, when required.

Future Treasury Board Submissions

This section provides a summary any future Treasury Board submissions (e.g., EA, contracting, real property) and their proposed timing, including submission of the project close-out report.

6.2 Project Change Management Strategy

This section describes the project change management strategy and the methodology on which the strategy is based. Departments should consider including a description of:

  • The process for logging, analyzing and approving project change requests;
  • Change control board procedures;
  • The tracking of project changes in progress; and
  • Procedures for notification of concerned parties, including the Secretariat, when changes to the project baseline are being proposed to the project approval authority.

4.7 The segmenting of the project into gates, the proposed phased approach to managing changes

6.3 Communications Strategy

The methods, tools and techniques to be used for communications are described in this section. The communication strategy includes communication plans for all stakeholders, both internal and external to the project, and relevant ministerial announcements.

4.12 The communications strategy.

6.4 Risk Management Strategy

This section provides information on the risk factors that could affect the project and a description of the risk management plan for identifying, analyzing, and prioritizing project risks. Plans for assessing initial risk factors and for the ongoing identification, assessment, and mitigation of risk factors throughout the project life-cycle are specified.

The PCRA provides the basis for determining the level of project risk and complexity and the project approval authority. Its use will assist in identifying areas of project risk and complexity warranting further assessment and active risk management. In this way, the PCRA can be used as a tool to mitigate project risk. This section can elaborate on which areas of risk or complexity the PCRA exposed and what actions the department took or plans to take to mitigate project risks. For example, a project affected by procurement risks, as identified through a high score in the PCRA Procurement Knowledge area, may warrant the creation of a Senior Project Advisory Committee to mitigate the risks.

Project Risks

This section provides an assessment (probability and impact) of the most significant project risks and how they are addressed. Risks may be presented in a table format, as shown below. The probability and impact of the risks, as well as the planned mitigation strategy should be included. The risk owner is the individual who has accountability for the risks.

No. Risk Description Probability (H,M,L) Impact (H,M,L) Planned Mitigation Risk Owner

1

Training manuals may not be ready by the planned training date; this may affect the schedule.

H

H

Wikis will be used as an alternative solution to publish essential training material.

Training Lead

4.10 The other features of the project that could affect its progress, such as privacy and environmental issues, land claims, regulatory or legislative changes and agreements with other governments, including international or domestic participants.

Project Complexity and Risk Assessment

This section summarizes the results of the PCRA and highlights key risk factors identified in the PCRA.

The details of the PCRA and the assessment requirements can be found in the Standard for Project Complexity and Risk.

4.11 The results of the project complexity and risk assessment.

Other Issues and/or Risks

This section addresses any issues that have not been addressed earlier in the project brief.

4.10 The other features of the project that could affect its progress, such as privacy and environmental issues, land claims, regulatory or legislative changes and agreements with other governments, including international or domestic participants.

6.5 Procurement Strategy

When requirements are to be met through procurement activities, the procurement strategy is described in this section.

The procurement strategy for a project outlines the Crown procurement contracts or contractual arrangements necessary to achieve the defined project outcomes. It includes a description of the deliverables, by contract, as well as the relationship to other phases of the project and suppliers. It explains which department(s) will be responsible to issue the contracts, the anticipated value and duration of each contract, and whether the anticipated contracts will require Treasury Board approval.

The procurement strategy also sets out the approach for solicitation and evaluation of bids as well as the manner in which contracts will be awarded. Economic considerations are factored into the process during the development of the procurement strategy. It explains how the proposed approach meets the objectives of fair, open, and transparent procurement.

This section also explains the process and outcome of interdepartmental consultations with key federal stakeholders as well as any recommendations in developing the procurement strategy. It discusses the relevance and application of any applicable legislative, contractual or regulatory impacts on the various contracts (e.g., Government Contracts Regulations, trade agreements, and comprehensive land claims agreements). A discussion on the impact of socio-economic and national procurement policies should also be presented, including the identification of any incremental costs, if applicable, and risks associated with the strategy.

4.13 The procurement strategy, including the procurement review process and the proposed strategy for soliciting and awarding relevant contracts, when required.

7. Project Governance and Oversight

This section provides a description of the governance for the project. The Secretariat’s Project Governance and Oversight Guide[7] provides detailed guidance on governing projects in the Government of Canada.

4.9 The governance and management approach to the overall project including:

  • Accountability for project outcomes;
  • Documented roles and responsibilities of participating departments and of the different units within the lead department;
  • The structure and committees focused on achieving the project and program objectives; and
  • The nature and extent of consultation with Treasury Board Secretariat and other central agencies.

7.1 Project Oversight

This section provides the approval authority with a clear understanding of the oversight of the project. Oversight encompasses accountability, requires authority, and is a critical part of project governance. Refer to the Guide to Project Governance and Oversight for more information.

Roles and Responsibilities

This section describes the roles and responsibilities established to manage the project, including other participating departments if applicable. It also identifies and describes Memoranda of Understanding (MOUs) or Service Level Agreements (SLAs) that have been signed by the sponsoring department and participating departments. Refer to the Secretariat’s Guide to Joint Projects[8] for more information.

When an organization establishes an interdepartmental agreement in the form of a project charter or MOU with the other participating organizations, the project brief should identify the governance structure in the agreement, as well as the titles of the individuals accountable to the deputy heads for the successful management of the project.

The roles and responsibilities may be presented in a table format, as in the example below.

Project Role Responsibilities

Project Manager

  • Achieving the approved project scope within the planned (baseline) cost and schedule;
  • Reporting to the Business Sponsor or the Project Steering Committee (PSC) and managing the Project Team;
  • Tracking project status by comparing cost-schedule performance to approved and documented cost-schedule baseline; and
  • Ensuring proactive and continuous risk and issue management and escalating risks and/or issues for resolution.

Business Sponsor

  • Delivering the business outcomes and benefits;
  • Ensuring the engagement of required project stakeholder groups (e.g., project interdependencies); and
  • Ensuring resolution of risks and issues escalated by the project manager.

Senior Project Advisory Committee (SPAC)

  • Establishing business buy-in and support;
  • Considering appropriate steps to orient a risk project to achieve national objectives;
  • Enabling success of the project through appropriate resourcing; and
  • Resolving issues that arise and facilitating communication with all stakeholders;

7.2 Project Governance Structure and Committees

This section includes a summary of the structure within which the decision makers are situated and, when applicable, the mandate (e.g., terms of reference) of each committee involved.

7.3 Consultations with the Secretariat and other Agencies

If the project requires oversight by the Treasury Board, or if the project has departmental impacts, the related governance committees established to support appropriate engagement of the Secretariat and other potential stakeholders, including Public Works and Government Services Canada, Shared Services Canada, the Department of Justice Canada, PPP Canada and other departments, are described in this section.

8. Privacy Impact Assessment

Privacy Impact Assessments (PIAs) are used to identify the potential privacy risks of new or redesigned federal government programs or services. PIAs also help eliminate or reduce those risks to an acceptable level. Information on PIAs can be found on the website of the Office of the Privacy Commissioner of Canada.

In accordance with the Policy on the Management of Projects (Appendix B), this section provides a high-level description of the results of the PIA or the Preliminary Privacy Impact Assessment (PPIA) and the measures taken or planned to address privacy issues and risks if applicable.

4.14 The results of the Privacy or Preliminary Privacy Impact Assessment (PIA/PPIA) and the measures taken or to be taken to address privacy issues and risks.

9. References

9.1 Contributors

The following departments contributed to the preparation of this guide:

  • Fisheries and Oceans Canada
  • Human Resources and Skills Development Canada
  • National Defence
  • Natural Resources Canada
  • Royal Canadian Mounted Police
  • Treasury Board of Canada Secretariat, Chief Information Officer Branch (CIOB)

9.2 Questions and Feedback

Please direct enquiries about this policy instrument to the organizational unit in your department responsible for this subject matter. For interpretation of this policy instrument, the responsible organizational unit should contact: TBS Public Enquiries.


Appendix: Examples of a Description of a Project and its Business Outcomes

Example 1 – Downtown Ottawa Transit Tunnel

Current State

Public transit through downtown Ottawa accommodates over 10,000 riders in each direction along the Transitway during peak hours. Currently, the transit service is limited to approximately180 buses an hour through downtown to meet travel demand. Effectively, the transit system has reached its capacity in providing Bus Rapid Transit service through the downtown to serve surrounding communities. The system will no longer be able to expand service beyond 2018, and is expected to reach capacity shortly afterwards. Ottawa has an expanding population and is Canada’s fourth-largest city and Ontario’s second-largest city, with a population of over 900,000 (metropolitan area is over 1.2 million) and an area of 2,596 square kilometres.

Project Purpose

In 2003, the City approved the Transportation Master Plan (TMP) for public transit in Ottawa. The Downtown Ottawa Transit Tunnel (DOTT) project is the centrepiece of the TMP. The purpose of the DOTT project is to establish a faster, more efficient, high quality rail-based rapid transit service which will accommodate existing and future travel demand into and through the downtown. The DOTT project will help address existing congestion and aid in preventing even higher levels of congestion in the future

Project Scope and Timing

The TMP includes a phased set of projects to be implemented by 2031. The DOTT project includes a new 12.5 km LRT line operating east-west through a 3.2 km tunnel beneath downtown Ottawa. The DOTT route will connect major development nodes and bus routes, providing the core of a larger light rail transit network.

The DOTT project consists of the following three segments:

  • An alignment from the western terminus at Tunney’s Pasture to east of Booth Street,
  • A 3.2 km tunnel through the downtown core from Booth Street to south of

the University of Ottawa, and

  • A route from south of the University of Ottawa to Blair Station.

Overall, thirteen stations are proposed along the 12.5-km route. Four of the stations will be underground and the remaining nine will be conversions of the existing Transitway stations to LRT stations. The route will connect into the existing Transitway east and west of the study area, into the Southeast Transitway at Hurdman Station, and to the O-Train at Bayview Station.

Business Outcomes

Building and widening roads alone, especially in downtown Ottawa, is not a practical or affordable solution to meet the anticipated demands and to support the projected growth on the City’s transportation system. By providing greater transportation choice, attracting more riders and adding more capacity to the overall transportation network, the DOTT project is aiming to help address existing congestion and aid in preventing even higher levels of congestion in the future. The growth of downtown employment is expected to continue through the ability to increase capacity on transit service in the downtown, primarily on the DOTT LRT line.

The final outcomes of DOTT are as follows:

  • Improve mobility, reduce travel times and increase safety and efficiency;
  • Expand public access and ridership;
  • Reduce the growth of GHG and other emissions; and,
  • Contribute to sustainable municipal development and land-use planning.

Example 2 – Email Transformation Initiative

Current State

Shared Services Canada (SSC) was established in 2011 to modernize how the federal government manages its information technology (IT) infrastructure in order to better support the delivery of programs and services to Canadians. A key element of IT infrastructure is email, which has become one of the Government’s preferred communications mediums. The 44 partner organizations, for which SSC provides infrastructure services, currently use 63 separate and distinct email systems, different email technologies, and are managed by separate support organizations. With no common standards across the Public Service, compatibility is limited and interoperability is a major issue. The existing system is complex, inefficient, and expensive. The current cost of email services to the 44 partner organizations is approximately $128.3 M.

Project Purpose

Before SSC became responsible for infrastructure services, the operation of multiple email systems across the Government meant that departments and agencies negotiated and maintained separate licenses, and had their own technical support teams in place. This duplication was costly and unnecessary. In Budgets 2012 and 2013, the Government announced that SSC will realize significant costs savings by creating economies of scale with a whole of government approach to IT. In May 2012, SSC launched the Email Transformation Initiative (ETI) project to consolidate the Government’s separate email systems to a standardized email service, managed by SSC, and delivered to the Partner organizations.

Project Scope and Timing

The primary requirements of the ETI are listed below.

  • SSC will establish a new email service for its SSC Partners and itself, in both official languages. The new email service will also be available to other departments and agencies, on an optional and cost recovery basis.
  • The new email service will use a single email domain name. A standard email naming convention will be adopted for all Government of Canada (GC) employees prescribed in a TBS policy instrument.
  • The new email service will be user-friendly and intuitive, requiring limited formal training. The new email solution will provide online help services and self-training functions to facilitate both the transition and ongoing use of the new email solution.
  • The new email service will be developed and operated to a single government service standard, which will meet at a minimum 99.9% availability on a 24 / 7 / 365 basis.
  • The new email service will be comprised of two individual email systems. The first will be certified to handle emails designated up to and including Protected B level, with attachments, when sent or received from within the Government network. The second email service will be certified to handle email designated as Secret. Secret email will not be deployed until the GC has a secure infrastructure available.

The duration of the project should not exceed three years, and preliminary savings are to be realized in fiscal year 2013-2014. To delay the project would delay the realization of any savings.

Business Outcomes

The output of this transformation is a new, enterprise-wide, centralized model and delivery of a standardized GC email services. The ETI project will deliver: a standard and consolidated email service for GC operations; reduced costs for delivery of email services; a secure and reliable email services; and a common domain name and email address.

The final outcomes of ETI are as follows:

  • Reduced and avoided costs;
  • Greening of IT services;
  • Business needs that can be responded to in a more timely manner;
  • Email services that are highly available;
  • Email content that is secure from a confidentiality and integrity perspective;
  • Ability to develop and deploy skilled workforce; and
  • Partnerships with industry that are open transparent and fair.
Date modified: