<Project Name> DRAFT Stage Gate 1 Review – Feasibility to Delivery (Detailed Design & Planning) Revision History Date Version Author Description Project Information Project Name Project Manager Project Executive Business Owner Project Objective Gate Approval Date [Project Name] – Stage Gate 1 Review Report Page 1 of 10 [Project Name] – Stage Gate 1 Review Report How to use this document: (when complete, delete this guidance text) The Stage Gate Description in section 1 below describes the overall purpose of this gate review, and the artefacts that may be required. The Project Manager or Team Leader should use the appendix, Review Gate Considerations, as a checklist to assist in preparing for the gate review. When the Project Manager or Team Leader has completed the checklist, the PMO will review it and provide feedback and questions, helping to ensure that appropriate planning has been done for the next phase of the project. Evidence of review activities may be requested and must be accessible if required. The PMO will complete section 3, providing a recommendation based on the review, with details in an Executive Summary. This recommendation will be one of the following: Approved to advance to the next phase, Not approved to advance to the next phase, or Conditionally approved to advance to the next phase, when the action items provided are cleared. The Project Manager or Team Leader will be advised of the results of the review, and should share this with their Project Board and other governance groups. Page 2 of 10 [Project Name] – Stage Gate 1 Review Report 1. Stage Gate Description The primary function of Stage Gate 1 – Feasibility Assessment is where formal approval is given for the Business Case. Once this gate is successfully passed, the project will proceed into the Delivery phase, starting with the Detailed Design and Planning Stage. This gate approves funding for the entire project, however the Project Manager will only be given control of the funds for Detailed Design and Planning. The remainder will stay in the control of the Technology Portfolio Review Board. 1.1. Stage Artefacts (as applicable) Document Description Business Case The business case is justification for the project. It details all options considered to deliver the outcome, with a recommendation for the option that should be selected. It focuses on cost, business benefits, risks and timeframes. The Business Case will be referenced at each Stage Gate to ensure its on-going viability. The Business Case must be approved by the Project Board before submission to Stage Gate 1. Solution Architecture This document will be created by the Solution Architect, referring to the architectural principles approved by the University ICT Architecture Committee. It must be endorsed by the Technical Design Authority, to ensure consistency with the approved architecture, before Stage Gate 1. Business Requirements This document details the requirements as set out by the users of the final product(s). At this stage, requirements will be in business terms, not technical. Draft Project Initiation Document (PID) The PID is the document used to guide progress and delivery of the project. It is a deliverable for Gate 2, but is recommended to have a draft version available by the time Gate 1 is passed. At this stage, it will contain mostly details about what will be delivered (scope) and when (schedule), as well as the governance structures to be employed. Details of how the project will be delivered will be added later, during the Planning phase. Proof of Concept Report If a Proof of Concept approach was approved at Gate 0, this document will provide details of the outcomes from the Proof of Concept. It should be of sufficient detail to enable the board to determine if the chosen solution going to satisfy the needs of the users. Benefits Framework This may form part of the PID. There must be an indication at Gate 1 of what benefits the project will deliver to the business, and how these benefits will be measured. Page 3 of 10 [Project Name] – Stage Gate 1 Review Report 2. Approval Signatures Approval of the Project Review Gate indicates an understanding and formal agreement that the project is ready to proceed to the next phase. By signing this deliverable, the relevant parties agree that the project should proceed from the Feasibility phase to the Detailed Design phase. Approver Name Title Signature Date PMO Manager Page 4 of 10 [Project Name] – Stage Gate 1 Review Report 3. Review Gate Checklist Item Question Response 1 Has the project demonstrated that it is aligned with business needs and University strategy? Yes No 2 Is this project still a priority for the University? Yes No 3 Has the project demonstrated that it meets the University’s preferred technical architecture (if appropriate)? Yes No 4 Have the key risks been assessed adequately? Yes No 5 Has the project met planned milestones and deliverables to date? Yes No Gate Review Executive Summary It is recommended that progress to the Detailed Design and Planning phase for this project be: Approved Not Approved Conditionally Approved This recommendation is based on.... Page 5 of 10 4. Open Issues Describe any open issues and plans for resolution within the context of formally approving the Project Implementation Review Gate. Issue [Project Name] – Stage Gate 1 Review Report Planned Resolution Page 6 of 10 [Project Name] – Stage Gate 1 Review Report Appendix: Review Gate Considerations Consideration Artefact Complete Comments/Reference Problem Definition: High level scope statement Scope clearly defines boundaries of the project, with inclusions and exclusions. Business Case Key deliverables and success criteria Clearly states the main objectives of the project at a high level, as well any quality criteria. Business Case Known constraints and assumptions Boundaries and limitations affecting successful delivery are identified. Business Case Functional requirements High level functional requirements are identified, along with the source of the requirement. Business Case, User Requirements Benefits analysis Expected benefits, both tangible and intangible, are identified and quantified where possible. Business Case Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Solution Definition: N/A Proof of Concept If required. The POC Report should indicate the likelihood of successful implementation, as well as identifying potential risks and opportunities. POC Report Options analysis Should identify the options for delivery of scope, including doing nothing, and a comparative analysis of benefits, costs, and risks. Recommended option is identified. Business Case Impact assessment Should identify user groups and systems that Business Case Page 7 of 10 [Project Name] – Stage Gate 1 Review Report will be impacted by the scoped change, and the type and level of impact. Overview of proposed system functionality High level description and diagrams of as-is and to-be systems. Solution Architecture Yes No Security considerations Identifies any security implications, including highest sensitivity of system data, potential new risks, and implications for other systems. Solution Architecture Yes No Data migration requirements Describe how any legacy data will be handled, including data cleansing, format changes, and archiving. Solution Architecture Yes No Yes No Yes No Yes No Yes No Yes No Delivery Planning: Key stakeholder analysis Identifies key stakeholders and groups by roles and names, how they are interested, and influence on the project. PID Dependencies Identifies dependencies on external events and deliverables, including dates, contact point/owner, potential impact, and mitigation plan. Dependencies should be tracked as risks. PID High level schedule/milestones High level identification of project milestones and dates. Business Case, PID, Project Schedule Communication plan Identifies type of communication or meeting, sender, recipients, media, frequency, and content. PID Governance plan Identifies lines of reporting and escalation, reviewers, approvers, and decision makers for each deliverable or decision point. PID Page 8 of 10 [Project Name] – Stage Gate 1 Review Report Risks and Issues logs Identifies risks and issues, owners, dates, likelihood, impact, mitigation plan, and status. Should be current. PID, R&I Logs Work breakdown structure (WBS) Breaks the scope of work down to a work package level for the next phase. Work packages include estimates of time and resources to complete work. PID, Project Schedule Resource estimates Resource requirements based on WBS work packages. Budget Rough order of magnitude estimate based on preferred option, past experience, and high level requirements for internal and external/vendor resources. PID Business Case, PID Project organisation and roles Contains an organisational chart for the project, along with responsibilities for each role. PID Quality plan Describes how a high standard of deliverables will be ensured. May include a quality matrix and high level testing strategy. PID Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Business change management (BCM) plan Contains methods for assessing potential impacts to the business and appetite for change, and for addressing information and training needs to positively influence delivery success. PID Controls: Business Case is signed off Project Board approval provided. Business Case High level user requirements signed off Project Board approval provided. User Requirements Page 9 of 10 [Project Name] – Stage Gate 1 Review Report Technical Approach Approach documented and signed off by appropriate technical authority. POC signed off Project Board approval provided. N/A Solution Architecture POC Report Yes No Yes No Page 10 of 10