Project methodology

‌‌‌‌‌‌Projects at University of Bristol are run using the PRINCE2 Project Management methodology.

The following templates support the methodology used:

Project deliverables timeline Project Deliverables Timeline (Office document, 78kB) This is a diagram showing the project deliverables timeline.
Project Control
Outline Proposal Outline Proposal (Office document, 24kB) An initial two page paper explaining the rationale of an initiative (potential future project). This is taken to the Ways of Working Portfolio Board to obtain initial views on the potential project, prior to Business Case work.
Business Case (Stage 0)

Stage 0 business case (Office document, 107kB)

Business Case Documentation (Office document, 88kB)

The Business Case contains information that describes the justification for setting up and continuing a PRINCE2 project. A Stage 0 Business Case is an outline case that is submitted to the Ways of Working Portfolio Board. If approved, a more detailed Stage 1 Business case is developed.
Business Case (Stage 1)

Stage 1 business case (Office document, 462kB)

Business Case Documentation (Office document, 88kB)

This is the full Business Case which is submitted to the Ways of Working Portfolio Board.  If approved the project can be initiated. The Business Case should be updated throughout the project's history.
Executive Summary Executive summary and checklist (Office document, 107kB) For all business cases (Stage 0 and Stage 1) an Executive Summary must be provided, detailing the key points of the business case in brief.
Master End Benefits Master list of end benefits (Office document, 12kB) Each business case must be mapped to up to three Master End Benefits, which reflect the priorities in the University's published Strategy and Vision.
Business Case Financial Template Business case financial template (Office document, 50kB) The Financial Template is a required appendix to the Business Case (Stage 0 and Stage 1), which financially quantifies the costs (and benefits) of the next stage of the project.
Statement of Requirements (SOR) Statement of requirements (Office document, 54kB) The SOR summarises the business requirements of a required system. It is not a system solution, but a guideline of the required system's functionality.
Service Level Requirements Service level requirements (Office document, 64kB) This Service Level Requirements documents information that describes the anticipated operational needs of an IT service.  It is initially produced to inform the development or procurement of a system solution.
Service Roles and Responsibilities Service roles and responsibilities (Office document, 31kB) This document outlines roles and responsibilities to be used in defining who will be accountable and responsible for a service once it goes live.
Functional Specification Functional specification (Office document, 112kB)

Details of the new or amended functions required in the system solution(s) that has been identified in order to meet the business requirements selected.

New Service Go Live Checklist New Service Process IT Services requires completion of a 'New Service Go Live Checklist' to ensure, as far as is possible, that the service is ready to go live before it does so. For more information, visit the New Service Process webpage.
Project Initiation Document (PID) Project Initiation Document (PID) (Office document, 65kB) Forms the document that brings together all of the key information acquired through the early stages of the project, including the Business Case, the Risk and Issues Log and a high level plan.
Project Initiation Document (Reduced) Project Initiation Document (Reduced) (Office document, 61kB) Forms the document that brings together all of the key information acquired through the early stages of the project, including the Business Case, the Risk and Issues Log and a high level plan. This template is specifically for small projects in discussion with the Senior Project Manager.
Weekly / Fortnightly Project Report Weekly-Fortnightly Report (Office document, 41kB) A progress report of the current position of the project and its respective workstreams. 
Checkpoint Report Checkpoint report (Office document, 51kB) A progress report of the information gathered at a checkpoint meeting, which is given by a team to the Project Manager and provides reporting data as defined in the Work Package.
Highlight Report Highlight report (Office document, 149kB) A highlight report provides the Project Board with a summary of the status of a project at agreed stages and is used to monitor progress. The Project manager uses the Highlight report to alert the Board to any potential problems or areas where the Board can help.
End Stage Report End Stage Report (Office document, 104kB) The end stage report is used to give a summary of progress to date, the overall project situation, and sufficient information to ask for a Project Board decision on what to do next with the project. It may be used for a project that is being paused.
Project Workbook Project Workbook (Office document, 174kB) Contains the forms to log: actions, issues, risks and decisions.
Exception Report

Exception report (Office document, 57kB)

An Exception Report is produced when costs and/or timescale for an approved Stage Plan are forecast to exceed the tolerance levels set. It is sent by the Project Manager in order to appraise the Project Board of the adverse situation.
Project Completion
Lessons Learned Report Lessons learned report (Office document, 50kB) At the close of a project, the Lessons Learned report is intended to be a summary of any lessons learned during the project that can be usefully applied to other projects. 
Project Closure Report Project closure report (Office document, 64kB) Is the final document produced for the project and is used by senior management to assess the success of the project, identify best practices for future projects, resolve all open issues, and formally close the project. 
Post Implementation Project Review Post Implementation Review (Office document, 60kB)

The Post Implementation Review takes place some time after a project has been closed, and is used by senior management to assess the success of a project once new processes and systems have been operational for enough time to be able to judge the impact of the changes.