• Home
  • Login
  • Welcome to the Staff Intranet


A standard set of templates will be used throughout a project's lifecycle.  These can be found here:


Project Brief - the idea



  • Document from business owner/ sponsor that sets out initial expectations of project along with key dates and deliverables  and indicative budget
  • Gives authority to the assigned Project Manager to start scoping and planning the project
  • Aim is to ensure that what the Project Sponsor gives to the PM is fully understood (not ambiguous!) and these requirements are agreed prior to any investigation occurring.
  • Allows PM to review at post project review stage what was delivered against what was originally requested
  • OWNER - Project Sponsor

Project Initiation Document (PID) - Why are we doing it?



Authorisation - Provides the overall justification to commence:

  • Control - Provides the basis of control (i.e. baseline)
  • Ongoing Viability - Ensures ongoing viability to be conducted against original assumptions
  • Dynamic document  - Changes as project progress
  • Agreed and owned by Project Sponsor
  • Agreed with all Project Stakeholders

It should detail the following:

  • Benefits - why are we doing it
  • Objectives - what are trying to achieve (SMART)
  • Critical Success Factors (Enablers)
  • High Level Deliverables (Stage & Gate)
  • Review the different Options


Project Plan - How are we going to do it?




The Project Plan:

  • Converts PID into a Project
  • Provides the base set of documents against which the project management team can assess progress, control change and ensure the ongoing viability of the project
  • OWNER - Project Manager

It should detail the following:

  • What is the project aiming to achieve?
  • Why is the project being done?
  • When is the project scheduled?
  • How is the project going to be executed?
  • Where is the project going to be done?
  • Who is going to be working on the project?
  • How much money has been allocated to the project?


Project Highlight Report




Regular status report:

  • Aim is to be a summary report that easily shows the status of project, current issues, risks and changes and status of work packages.
  • This report will feed into an overall Department Project Report which will be distributed to the Project Team and Board and available for all to view in Project Folder
  • OWNER - Project Manager


Project Close Report



Lessons learned document that reviews entire project:

  • Review original Project Brief, PID, Project Plans and logs and compare what was implemented against what was originally requested.
  • Aim to receive an unbiased account from the Project team on how well the project ran, what went well, what went wrong and where things can be improved.
  • This will then feed into an overall post project review presentation which will be given to the project board prior to completion of the project.
  • OWNER - Project Manager


Test Plan


  • User Acceptance Test Document that details the different system and business testing scenarios that will be done during the final stages of the project
  • Aim is to ensure that all functions documented are thoroughly tested and that there is no impact onto other functions prior to go-live.
  • Go-live will only occur with full testing and agreement from testers and team with final authority given from Project Manager
  • OWNER - Project Team Member


Gantt Chart - the schedule


  Project Plan Template


  • Detailed Gantt Chart that records all the work packages, duration and resources assigned to the project during its lifecycle
  • Gantt chart must be baselined once the project has been initiated to allow post-project analysis
  • Aim is to give a graphical representation of all the tasks, dependencies and resources that will allow easy tracking and updating of project
  • OWNER - Project Manager


Functional Requirements


  • Detailed document that defines the features that System/ product must do.
  • Filters into Project Plan and Test Plan
  • Aim is to accurately define the scope and prevent changes to the project once implemented
  • Not mandatory but highly recommended
  • OWNER - Project Team member

Issue Log


  Issue Log Template


  • Unique Identity Number
  • Spreadsheet or SPS List that summarises the issues, their analysis, actions and status
  • Aim is to regularly track issues and increase visibility of all open issues/ actions/ changes and risks
  • OWNER - Project Manager


Risk Log


  Risk Log Template


  • Unique Identity Number
  • Spreadsheet or SPS List that records all project risks, their contingencies, containments  impact, likelihood, owner, status and costs
  • Aim is to highlight risks to the Project Board and team and ensure that sufficient investigation and analysis has been done to minimise the impact of the risk onto the project
  • Should be reviewed regularly both by the Project Team and the Project Board
  • OWNER - Project Manager


Change Log


  Change Log Template


  • Unique Identity Number
  • Spreadsheet or SPS List detailing all changes that have been requested during the course of the project.
  • Details the change, impact, cost and current status
  • Aim is to track changes and ensure that changes are managed
  • OWNER - Project Manager


Work Package


  • Document that defines the work that is required to be completed by team to produce products for the project.
  • All Work Packages are to be registered by the PMO
  • Owned by Team Manager who will liaise with Project Manager to define the start and end dates
  • All tasks on work package will be delegated by Team Manager to their team.

 It will contain the following:  

  • Unique Identity Number
  • Objective
  • Requirements
  • Pre-requisites
  • Deliverables
  • Dependencies
  • Change to working practice
  • Tasks
  • Start and End dates