Stage Gate 1 Review - University of Adelaide

advertisement
<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
Download