|Deliverable||Purpose||Begin Draft||Finalize Deliverable||Area of Resp.|
|Application Build Book||The Application Build Book will be used as an install and base configuration guide for Applications. This guide will assist in creating and installing an application in the event that the application were to fail and had to be rebuilt and installed from scratch.||Execute||Implement||AIMS|
|Application Quality Assurance Checklist||The Application Quality Assurance Checklist is intended to ensure “Custom-Built” applications adhere to development practices that promote quality solutions. It is recommended that the project team familiarize themselves with this checklist during the Design stage to ensure the developed application meets the quality standards when reviewed in the Execute stage.||Design||Implement||AIMS|
|Business Case||The business case will outline the business rationale for undertaking the project.||Concept||Concept||Client|
|Business Process Definition||The business process definition will outline the business management controls & processes followed by the client department to manage and support the non-financial business associated with the project.||Analysis||Implement||Projects|
|Business Requirements Document (BRD)||The Business Requirements Document (BRD) clearly states the functions and capabilities that the application and/or system must provide for the project to be successful (what the system and/or application must do). All known constraints, assumptions and dependencies must also be clearly defined.
The BRD is the basis for all subsequent project planning, design and coding. It should describe as completely as known at this time, the system’s behaviours under various conditions. The BRD does NOT contain design information or anything related to how the system will provide the functionality.
The BRD may be modified after the Analysis phase if a COTS or Cloud solution is proposed.
|Chart of Authorities||The Chart of Authorities form defines the authorities associated with supporting the operation of a computer application within the Office of the Chief Information Officer and also identifies the name of the business owner and/or the alternate business owner for this application.
It also identifies the names of individuals who (on behalf of the business owner), approve various types of changes associated with the operation and support of the application.
|Client Acceptance Form||The Client Acceptance form signifies sign-off of the delivered solution, it verifies what deliverables are being turned over to the client and that the client has accepted / approved those deliverables. This form would be completed during the Close phase of a project where the project team is handing over a solution/deliverable to the client.||Implement||Close||Projects|
|Client Test Strategy||This document identifies the overall approach for the client to test the overall solution as delivered by the vendor for a project, to ensure the client’s requirements have been met.||Design||Execute||Client|
|Copy of Production Data||This form was designed to facilitate the process of obtaining a copy of Production data that will be delivered to an external source outside of the current production system.||Execute||Implement||AIMS|
|Data Migration/ Conversion Plan
(No template available)
|This plan describes the overall approach, assumptions, and processes that will be used in the data conversion. It includes an inventory and cross reference of source and target data elements, schema, metadata and all self-describing files; process for data extraction, transformation and loading for each data source; tools needed to execute the conversion; and strategy for data quality assurance and control. PMs can use their own template for the Data Migration / Conversion Plan.
Note: when copying data from source to target system, please refer to the Copy of Production Data deliverable.
|Database Build Book||The Database Build Book will be used as an installation and database configuration guide. This guide will assist in creating and installing an application in the event that the database were to fail and had to be rebuilt and installed from scratch.||Execute||Implement||AIMS|
|Detailed Architecture Design (DAD)||This document captures a proposed system architecture, which ensures adherence to the OCIO’s technical standards. It allows for an assessment of the proposed design for suitability, stability, availability, security, and supportability.
A response to this document from the Enterprise Architecture division will provide feedback to project teams on areas of architectural design suitability or deficiency, and will include recommendations for improvement.
|Design||Design||Operations and Support|
|Disaster Recovery Plan||The Disaster Recovery (DR) Plan outlines the detailed steps required to recover the infrastructure and application in the event of a disaster.
In the Plan-for-Design stage, the PM should include tasks to meet with the DR Team and discuss the delivery and content of the DR Plan.It is recommended that the PM engage the DR Analyst to obtain guidance on the DR Plan completion
|Financial Management and Business Process Definition
(Check with the PMO for a copy of this template)
The purpose of this document is to provide information relating to the financial management and business process definition that support the project and receive acceptance from the Department (including the project team), the Office of the Comptroller General (OCG), and the Office of the Chief Information Officer (OCIO).
|Go / No-Go Checkpoint – End of Analysis||This is the output of the Go/No-Go decision Checkpoint – End of Analysis meeting.It must be completed in full and signed off before the project can proceed to the Plan-for-Design stage.||Analysis||Analysis||Projects|
|Go Live Communication||The purpose of the Go Live Communication is to ensure project stakeholders are aware of the project’s Go Live and Transition to Application Services and Operations. The communication informs the targeted audience of the specific dates for project Go Live and Transition (start and end) to Operations and Application Services.||Implement||Implement||Projects|
(No Template available at this time)
|The implementation plan describes how the IT solution will be installed, deployed and transitioned into an operational/production environment. The plan contains an overview of the system, a brief description of the major tasks involved in the implementation, confirms roles, responsibilities, and timelines for all resources (Application and Information Management Services / Operations and Support teams, project team, client users, etc.) involved in the implementation.||Design||Execute||AIMSO&S|
|Information Management (IM) Assessment||The Information Management (IM) Assessment is completed by an IM Advisory Services Analyst for each new OCIO project. Instances where an IM Assessment is determined not to be applicable, this will be also be reported in this document.||Analysis||Analysis||IM / IP|
|Internal Security Assessment Report – Response
(Contact Enterprise Architecture to complete this deliverable)
|An Internal Security Assessment (ISA) is required prior to implementation.The result of this assessment will be the ISA Report – Response. All issues noted in this report must be addressed (i.e. resolved, mitigated, or a deviation noted). Any mitigations or deviations must be approved by AIMS and/or Operations and Support & Security branches and approved before the implement stage can proceed; the next step will be either (a) the project can proceed to VA (if a VA has been mandated) or (b) the project can Go-Live.||Implement||Implement||Projects – Enterprise Architecture|
|Operational Procedure Manual (OPM)||An Internal Security Assessment (ISA) is required prior to implementation. The result of this assessment will be the ISA Report – Response. All issues noted in this report must be addressed (i.e. resolved, mitigated, or a deviation noted). Any mitigations or deviations must be approved by AIMS and/or Operations and Support & Security branches and approved before the implement stage can proceed; the next step will be either (a) the project can proceed to VA (if a VA has been mandated) or (b) the project can Go-Live.||Execute||Implement||AIMS|
|Post Implementation Support Plan||A Support Plan is an integral part of the software development life cycle. The purpose of the Post Implementation Support Plan is to describe the support process, roles, and responsibilities of all parties required for the continued operation of the application after Go Live.||Design||Implement||AIMS|
|Preliminary Privacy Impact Assessment Checklist (PPIA)||This checklist is to be completed by public bodies and submitted to the ATIPP Office electronically. If you need assistance completing this PPIA, please contact the Senior Privacy Analyst assigned to your public body.||Analysis||Analysis||Projects|
|Preliminary Scope Document||Projects are required to have a preliminary scope document to identify the high-level project objectives and boundaries.||Concept||Concept||Client|
|Privacy Impact Report||The Privacy Impact Report is one of the outputs of the IM / IP/ ATIPP engagement. The ATIPP Analyst produces it once the PPIA checklist review is completed and the analyst has reached a determination around this project. It will identify any privacy issues and indicated if a full Privacy Impact Assessment is recommended.||Analysis||Analysis||ATIPP Office (Office of Public Engagement)|
|Project Charter||The Project Charter provides a statement of the background, scope, objectives, key deliverables, conditions for success and financial information for projects. The Project Charter is required for all projects and must be completed using the OCIO Project Charter template. The PM is responsible for completing ALL sections of the charter.||Plan-for-Analysis||Plan-for-Anaysis||Client|
|Project Closure Report||The Project Closure Report signifies the project handover to Application & Information Management Services (AIMS) and Operations & Security (O&S) for application and infrastructure support purposes. This report will be completed at the end of a project and filed in PPM.||Implement||Close||Projects|
|Project Initiation Document (PID)||The Project Initiation Document (PID) provides a common understanding of the project to help manage expectations and identify resources required to complete the project. It provides senior management and stakeholders with the information to enable them to commit to the resources and timelines proposed. The PID provides high level project planning tasks, objectives, benefits, outcomes, expectations, scope, timeframes, and key information on the project’s stakeholders.||Initiate||Initiate||Projects|
|Project Plan (Schedule)
(No Template available)
|The project schedule serves as a management-reporting tool as well as an implementation tool to help get the work done on time. The schedule contains activity durations, interdependencies and constraints that help to identify conflicts and bottlenecks. When completed, the schedule should produce a realistic and achievable timetable for executing the work, given the constraints and limitations.||Plan-for-Analysis||Close||Projects|
|Request for Decommissioning||The purpose of this form is to act as part of the package for decommissioning activities. This form verifies information collected for each application in consideration for decommissioning.||Design||Execute||AIMS|
|Risk Assessment Workbook
(OCIO IP Division will complete the Risk Assessment Workbook )
|At the conclusion of this IM / IP / ATIPPP engagement, the PM will receive a Risk Assessment Workbook that contains (i) the Information Security Classification and (ii) Pre-TRA Checklist and a Privacy Impact Report.The Information Security Classification ranks the sensitivity and criticality of government information and guides the process to place appropriate levels of security and protection around information assets.The PRE-TRA Checklist is a checklist that determines the need for any additional risk assessments:(i) Vulnerability Assessment (VA)(ii) Security Design Review(iii) a full Threat Risk Assessment (TRA). The need for additional risk assessments is determined based on the underlying Information Security Classification and the exposure of the system.The PM will initiate the IM / IP / ATIPP engagement by completing the ‘Request for Service: IM / IP Engagement” form. The PM must allow 2-3 weeks, from the date the request is submitted for the response. The PM is responsible to ensure that they allocate enough time in the project plan to conduct the follow-on activities coming out of this Risk Assessment Workbook / Privacy Impact Report.||Analysis||Plan-for-Anaysis||CIMS|
|Security Design Review –Report Response and Deviations
(Contact Enterprise Architecture to complete this deliverable)
| The Risk Assessment Workbook will indicate if a Security Design Review is required. Documentation and delivery of the Security Design Review Report is the responsibility of the independent security assessor. If required for a project, the Information Protection (IP) Division – Independent Security Assessor is prime for this deliverable.
A Security Design Review assesses a solution’s proposed design from a security perspective, based on threats or risks that may occur at the architecture/design level; they are often recommended when building ‘environments’ or deploying ‘enterprise’ technologies. Identifying potential threats or vulnerabilities at the Design stage can avoid costly environment rebuilds after deployment to address unforeseen risks and vulnerabilities. The output from this review is the Security Design Review – Report Response and Deviations Document.
|Plan-for-Design||Design||IP & S|
|Server Build Book (for vendor support)
(Request from EA SDI or Operations and Security Prime)
|The server build book is used to provide the the Operations and Support Team with an accurate account of all configurations modifications to get the server to its production state. It will be required if the server is being transitioned to an outside vendor for support.||Execute||Implement||O&S|
|Service Desk Support Guide||The Service Desk Support Guide must be written for each application. The OCIO Service Desk uses this information to populate the Service Desk knowledgebase.||Execute||Implement||O&S|
|Source Code Handover
(No template available)
This deliverable applies to custom build application or COTS applications that have been configured. Handover of source code will be included as part of the “Go Live” Request for Change (RFC).
|System Design Document
(No template available)
|The system design document should define the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. There is no PMO template for this document.||Design||Design||Projects|
(Contact EA to obtain a copy of this template)
|The technical requirements document is created to ensure solutions acquired and implemented are procured according to a set of guiding technology principles.
This document will ensure that the solution being procured aligns with the OCIO’s guiding principles and best practices as outlined in the OCIO Guidelines and Best Practices for Government Technology Solutions document. The concepts presented in that document reflect the views of the OCIO and standards that are actively reviewed as part of the solution architecture.
|Test Cases / Test Plan
(No template available)
|For large and extra-large projects, a formal test plan with test cases is highly recommended.This test plan should cover unit, system, integration, user acceptance testing, regression testing, stress testing and performance testing.||Analysis||Design||Projects|
|Threat Risk Assessment (TRA – Full) Report – Response.
(OS & P will provide info on this deliverable)
|A Risk Assessment Workbook will determine if a Threat Risk Assessment (TRA- Full) is required. The Information Protection (IP) Division – Independent Security Assessor is prime for this deliverable. The output from the TRA assessment is the Threat Risk Assessment Report – Response. If required, the PM is responsible to ensure this assessment is conducted and the report-response is addressed in a timely manner.||Plan-for-Design||Design||Operations Support & Security|
|Training Plan||The Training Plan as well as the training material should be reviewed and confirmed by each resource’s manager (OCIO, client, etc.) where the resource is impacted by training activities. The training plan should include training for end users, super users and support resources, and should also outline how the training will be delivered, such as train the trainer, CBT’s, on site or offsite.||Design||Execute||AIMS/Client|
|Transition Agreement||The purpose of the Transition Agreement is to ensure that the documentation (deliverables) required by Application & Information Management Services(AIMS) and Operations & Security (O&S) to support the solution are agreed upon early in the Design Phase.
Finalization and approval of the Transition Agreement will occur at the end of the SDLC Design stage; however, the document can be amended throughout the Project Life Cycle.
(No template available)
|This objective of the User Documentation is to assist users with the functionality and use of the delivered application. The PM should ensure that client department completes user documentation with assistance from the project team as needed. When implementing a COTS solution, the PM should investigate to determine if the software vendor has already provided a user manual which may be used in part or in full to satisfy this requirement.||Design||Implement||Client|