Revision History

Date	Version	Description	

Jan-23, 2002	
1.0 	
Initial version
•	Deliverables described for Starting and Planning Processes	
Feb-06, 2002	1.1	Deliverable descriptions revised and added for the remaining processes.
Finalized draft of Deliverable Descriptions	

Mar-15, 2002	
1.2	
Changed “Closure Plan” to “Closure Report” for consistency.	

			

Deliverable Descriptions

<<Note: The deliverables are described in this separate file for the purposes of simplifying the content maintenance. These descriptions are often referenced from several places within the Guide. Selecting a specific deliverable description should position the user directly at the appropriate deliverable.>>.

Business case
A business case is a detailed investment proposal.  It puts investment decisions into a strategic context and provides the information necessary to make a decision about whether a project should proceed.  It provides an analysis of the costs, benefits, and risks associated with a proposed investment and offers reasonable alternatives and a recommended solution.  Once approved, it provides a baseline to monitor progress and measure results.

Project Charter
A Project Charter is a document that describes the agreement between the organization providing the product or service, and the client organization requesting and receiving the project deliverable.  It is a tool to obtain commitment from all affected groups and individuals within a specific project. It is an agreement between the technical and business groups which defines:

•	Partners and external stakeholders;
•	The project management framework to be used on the project;
•	Roles, responsibilities, accountabilities, and activities of the team members;
•	Management commitments; and
•	The empowerment framework.

Project Management Plan
The Project Management Plan (PMP) is the controlling document to manage an Information Management/Information Technology (IM/IT) project.  The Project Management Plan describes the: 

•	Purpose, scope, and interim and final deliverables of the project;
•	Schedule and budget for the project;
•	Project assumptions and constraints;
•	Managerial and technical processes necessary to develop the project deliverables;
•	Resources required to deliver the project deliverables; and
•	Additional plans required to support the project.

Once approved, the Plan will provide a baseline to monitor progress and measure results.

Scope Statement
The Scope Statement is a summary-level description of a project that includes project justification, project purpose and scope, and high-level work plan and deliverables, in addition to product/service description.

The scope statement provides basic information to prepare a business case, a project management plan, and for developing a common understanding among stakeholders.

Preliminary Project Approval (PPA) Submission 
The Preliminary Project Approval (PPA) Submission is a document to formally ask TB Ministers for authority to proceed with further definition of a project.  

The PPA provides a justification to proceed with the project and identifies the funds required to further define and plan the project. It also provides an indicative estimate of the total cost and preliminary information on the project management plan (approach and milestones), outstanding issues, IM/IT strategy, procurement strategy, human resources impact, communication and policy issues, and risk assessment. Further information is required in the PPA of Major Crown Projects and complex or significant projects.

Effective Project Approval (EPA) Submission
The Effective Project Approval (PPA) Submission is a document to formally ask TB Ministers for authority to implement the project. 

The EPA provides a confirmation that the reasons to undertake the project are still valid and identifies substantive estimates of individual items and total cost. It also includes a formal project management plan and provides updated information on milestones, outstanding issues, IM/IT strategy, procurement strategy, human resources impact, communication and policy issues, and risk assessment and mitigation strategies. Further information is required in the EPA of Major Crown Projects and complex or significant projects.  

Quality Management Plan
A Quality Management Plan describes the activities required to ensure products/deliverables are correct (i.e., function correctly, satisfy specifications) and to ensure that the project’s defined project management and development processes are applied properly so as to ensure the quality of the developed products.

The Quality Management Plan identifies the standards, practices, and methods to be used in the project for performing the quality activities. It also explains how deliverables will be checked, the tracking and reporting of non-conformant items, the process to approve deliverables, and how Technical Reviews and Verification and Validation Audits are to be conducted. 

Test Plan

A Test plan helps organize, schedule, and manage the testing effort and find bugs. The test plan defines the types of testing (e.g. functional, performance, usability) and the test levels (e.g. unit, integration, field testing) to be performed during the planning and implementation phases of the project.

The Test Plan identifies test items, features to be tested, testing tasks and responsibilities, the testing environment and required resources, and the schedule of the intended testing activities. It also lists the individual tests, and the objective, procedures, and expected results of each test.

Risk Management Plan
A Risk Management Plan describes how risks will be managed on the project. It is a subset or a companion element of the Project Management Plan. 

It identifies the involvement of the project team, the supplier, and the client in carrying out risk management activities, the detail and scheduling of each major risk management activity (e.g. identification, analysis, prioritization, monitoring), risks threshold criteria, and reporting formats. 

Communications Plan
The communication plan is a full-scale communications program designed to create awareness among key target audiences of its activities, programs, people, services and products.

A good communications plan: 

•	Will act as a binding agreement. When you inform people you are going to do something, having a communication plan will have given others the opportunity to provide you with input; 
•	Assures that you will take advantage of all opportunities, including ongoing implementation; 
•	Helps keep communication focussed; and 
•	Helps prevent unwanted surprises. 

Performance Plan
A Performance Plan specifies the project parameters (e.g. cost, schedule, risks) and the product/service attributes (size, complexity, sites) that will be used to analyze and report the progress to date and current status of the project, and to forecast future progress and status. It is a subset or companion piece to the Project Management Plan. 

It outlines what raw data will be collected, what kinds of analysis will be done, how the raw data and analysis will be saved, tools which will be used, and types and frequency of performance reports. 

HR (Staffing and Training) Management Plan
The Staffing and Training Plan defines when and how the project resources will be brought in and taken off the project team, and how their performance will be evaluated. In addition, it identifies what training, if any, is required to ensure that the project team posses the requisite knowledge and skill set. Furthermore, when training is determined to be required, it describes how it will be delivered to the team in a timely and cost effective manner.

Configuration Management Plan
The Configuration Management Plan describes the set of activities and tools to ensure that the project has adequate control over all items necessary for creating or supporting the project deliverables.

It defines what types of items will be controlled in the project, how they will be identified and the mechanism for controlling changes to those items. It also describes how baselines will be produced, the configuration reports to be issued, the audits or reviews of the configuration management process or library that will be conducted during the project, and the release procedures. 

Procurement Management Plan
A Procurement Management Plan documents the management process of identifying how project needs can best be met by procuring products and/or services outside the project organization such as:
•	Hardware (e.g., development and/or installation hardware),
•	Software (e.g., COTS, outsourcing some or all of the development); and
•	Services (e.g., management or development contractors/consultants).

It identifies the types of procurement strategies that will be used, outlines the scope of products and/or services to be procured, and identifies responsibilities for the procurement process up to and including contract closeout.

Requirements Management Plan
The Requirements Management Plan describes how the requirements of the project’s products and services will be managed during the project life cycle. 

It describes the steps to develop an understanding with the requirements providers on the meaning of the requirements, to agree upon a set of baseline requirements, to identify and control changes to requirements as they evolve during the project, and to maintain traceability among the requirements and the project plans and project’s products and services. 

Software Development Plan
A Software Development Plan (SDP) details the activities to be performed during the Software Development Life Cycle of a project.

It describes the software development methodology to be used, the design, programming and documentation standards to be observed, the development environment and how it will be established, controlled, and maintained, the approach to be followed for preparing and installing new software for use, and any other applicable software development activities.

Information Management Plan  
An Information Management Plan details the activities to ensure that the information associated to the project’s products and services is managed as a corporate business asset and in accordance with existing legislation, regulations, and policies. 

It describes how client information needs will be identified, the steps to determine the information that will be acquired, used, or produced in relation to the delivery of the project’s products and services, and the information standards to be observed. In addition, the Information Management Plan describes how access to information, privacy, confidentiality, security, and intellectual property provisions, and retention requirements and other life-cycle management of information considerations will be taken into account in the project lifecycle.

Requirements Specification
The Requirements Specification is a document that defines the “boundaries’ for the project and explicitly specifies system/product requirements and features. The Requirements Specification stipulates functional, performance, information, capability, safety, security, ergonomics, operations, maintenance, interface, and qualification requirements. In addition, it defines the type of testing required to accept that a requirement has been met. 

The Requirements Specifications provides a documented reference of the project team’s understanding of the product/system requirements, and the deliverables required to provide the product/system. 

Project Tracking Log(s) (Outstanding Issues, Decisions, Deliverables out for Approval)
Project Tracking Log(s) are a disciplined approach to identify, follow-up, communicate, and bring to a closure important events or situations impacting the successful completion of the project. 

Typical tracking logs include Outstanding Issues Log for items that must be resolved for the project to continue as planned, Decisions Log to record decision requests and client’s decisions, and Deliverables Out For Approval to follow-up the process and the timely review of project deliverables. 

Risk Log
The Risk log is a listing by ranking of the project risks and related risk information in a format that is easy to read, comprehend, and that facilitates periodically reviewing their statuses. 

It provides a statement of each risk, its ranking, the time horizon, probability of occurrence and impact if the risk occurs, the planned response, the person responsible for mitigation actions, and the current status and actions.

Performance and Status Report
A Performance and Status Report provides information on what the project has accomplished to date, where the project stands now, and predicts future project status and progress. 

Typical Performance and Status reports include information on project parameters such as schedule, costs, risks, quality, resource utilization, and scope changes, and on product/service attributes such as size, complexity, sites, function points, and are issued on a regular basis. 
…

Change Request
Changes occur during the project life cycle due to the addition or change to the requirements of the project’s products or services, to an increase or decrease in the estimated complexity of project activities, to an under or over cost or time estimate, or due to changes in the project assumptions or dependencies. 

A Change Request identifies the need to expand or contract the project scope, modify costs or adjust schedule estimates. It describes in a concise manner the reason, scope, and impact of a change, and records the approval to proceed with the change.

Closure Report

A Closure Report summarizes the results of a project and the activities required for the transition of the project’s products and services from “development” to “production” state.  

It identifies the extent to which the project objectives were satisfied and the anticipated benefits realized, the person or group within the client’s organization who will oversee the transition to the “production” state, the lessons learned during the project, the list of project files and the items returned to the client, and if applicable, the support arrangements and warranty period, rules and conditions.  

Project Acceptance
A Project Acceptance formalizes client acceptance of all the deliverables of a project (or a phase) and also confirms that there are no outstanding deliverables.