IT ServicesStaff

Project Delivery

Project Management Framework and Templates

Project Management Framework 

It is designed to:

  • Improve the alignment between the University’s business needs and Technology Projects – i.e. we deliver what is needed
  • Ensure that projects are initiated in a way that increases the likelihood they will be delivered as planned
  • Improve the way in which projects are monitored and controlled as they progress
  • Increase the visibility of projects and our processes to the University community
  • Enable better planning and use of University finances and human resources
  • The PMF assumes a base level of project management knowledge. It is NOT "how to be a Project Manager"

The Project Management Framework shows the stages of the project and within each stage the process steps to be considered.

At the end of each stage, there is a stage boundary (milestone) that must be completed and approved before the project can progress to the next stage.

Benefits of the PMF

The PMF enables a consistent way of delivering technology projects.  Specifically, the benefits of the PMF include:

  • Consistent and  standard methodology within IT Services
  • Adaptable outside of IT Services 
  • Clearly defined roles
  • Consistent clear templates, guidelines and checklists 
  • Increased project controls
  • Provides a basis for continuous improvement
  • Greater degree of certainty for project success

Project Stages

The PMF consists of four stages:

Stage 1 - Initiating (Pre-project) stage 

Milestone 1 – Project Proposal Document (PPD)


Stage 2 - Planning & Elaboration (Initiation) Stage

Milestone 2 – Project Initiation Document (PID) – Medium / Large Projects Only


Stage 3 - Monitoring & Controlling (Delivery) stage

Milestone 3 – Service Acceptance Preparation & Readiness


Stage 4 – Closing (Final delivery) stage

Milestone 4 – Project Closure

Project Classification and Planning

For Simple and Medium projects, the artefacts should be developed pragmatically, and to the degree necessary to benefit the project team and stakeholders. The PMO can provide guidance on the appropriate level of development required.

Projects are classified as:

  • Innovation
  • Service Improvement
  • Small
  • Medium
  • Large

The Project Manager in conjunction with the PMO will determine the projects classification, using the table below as a guide


Definition / Criteria


Service Improvement 





 Staff time only

 Staff time only

< 25k + staff time 

< 50k + staff time 

 >50k + staff time


Time boxed

< 80hrs effort

< 3 Mths ET*

< 9 Mths ET*

 > 9 Mths ET*

Team size 



< 5

< 10

> 10

Third parties

POC permitted ex. contract

 Existing contracts only

 Single supplier

2 – 3 suppliers

 Multiple suppliers

Business risk / criticality




Medium or Mandatory

 High or Mandatory


CBA Potential

Justified CBA


Medium CBA

 High CBA

Technical / Architecture risk


None / Minimal




CBA – Cost Benefit Analysis

ET* - Elapsed Time 

Service Improvements


This approach refers to any development or improvement work which is below the project thresholds set out in the University’s IT project approach.

The approach is intended to provide a set of tools and principles to assist staff carrying out this work rather than a process to be followed each time.


There is no formal approval mechanism required for Service Improvements. The Technical Service Owner should review requests to ensure that they fit with the strategy/roadmap for that service. Requests should be submitted via the IT service management system and assigned to the relevant queue.

Most service improvements can be progressed by the Technical Service Owner without any further approval or discussion.

In those cases where there is a question over the validity of the request, the priority or resourcing the request should be referred to the relevant SLT member for direction. This will typically be for larger pieces of work.

In instances where resources from different teams or the work is particularly high risk or complex a form is available to assist planning.

On occasions when resource or prioritisation conflicts cannot be resolved the matter should be referred to ITPAG using the Service Improvement Planning sheet.

The department has no requirement to record Service Improvement work in departmental resource plans. The team managers should reflect the time taken by Service Improvements by reducing the overall time available for projects.

There may be instances where there is a benefit to team managers in showing the work in the departmental resource plans, but this should be when there is a level of complexity or when there is an impact on planned project work. Where this is the case, it is the responsibility of the SLT member approving to submit the form to the PMO for recording in departmental resource plans.

Project Stages (milestones)

Stage 1 - Initiating (Pre-project) Stage

In this phase we will establish the purpose for starting the project and associated effort to deliver the scope, the primary output will be the Project Proposal Document.



Project Proposal Document (PPD)

The PPD comprises of 3 main sections. The first outlines the business case for doing the proposed project and the benefits to be derived. The second outlines the proposed solution to meet the project scope and objectives. The third outlines the high level project schedule, budget, resource requirements along with any known dependencies and risks.

Note, when adding project resources, consider all of those teams that can be affected by the project e.g. End User Computing, Help Desk, Procurement Team etc. Engage with those teams to confirm expected work and help validate your resources estimates.

The proposed project will then be reviewed in context with the business change governance framework. Alignment to the portfolio strategy and the value (benefits) to be derived. The proposed solution design and delivery plan reviewed to ensure alignment to architecture principals and appropriate project controls are in place for its delivery.

It is important to take account of the University's Procurement Rules, incl. contract value-based minimum competition requirements, where the project involves the purchase of products and/or services from a third party. The Procurement Team should be engaged to advise on the application of the Procurement Rules and will manage the tender exercise where the total estimated contract value is £50k+

Data Governance

During the life of a project, there is often a requirement to engage contractually with third parties and to share personal data for which the University is the Data Controller under the Data Protection Act or successor legislation. In doing this the institution has responsibilities to be transparent to the individuals whose personal data is being shared and to manage the risk with relevant stakeholders consulted and authorisation obtained prior to entering any contractual obligations. 

Projects initiated by the IT Portfolio Board (ITPB) follow the ITS Project Managment Framework. This framework breaks down the delivery of projects into 4 key stages. At each of these stages there is an opportunity to confirm what, when, and how personal data will be shared with third parties, stakeholders, and to apply appropriate governance prior to release. 

Where there is a requirement to share personal data, Registry is to be consulted and their sign-off sought. This will be required as evidence of stage completion and authorisation to move to the next stage within the project lifecycle. Note, where Capex funding is required the OP's process approval process is run in parallel to the project delivery. 

Data Governance Document 

Office 365 Group & Planner for Project Documentation and Collaboration

Once the PPD has been approved by ITPB an Office 365 Group incorporating Microsoft Planner functionality will be setup by the PMO on behalf of the project. The PMO will then initiate a 30 minute meeting with the Project Manager to walkthrough the functionality of Office 365 Groups and Planner, and to agree project deliverables. Further information and training material for Office 365 Groups and Planner can be found HERE

Service Improvement

 The Service Improvement Planning Sheet has been designed to help you plan out small pieces of work that do not require full projects. It is intended to be used when there is a change to an existing service that needs to be co-ordinated and planned. This may be because of the nature of the work being carried out, the dependencies on other work, or a need to book in time across teams. The planning sheet should be developed and agreed with the teams involved in the change.

The form is primarily a planning tool for IT staff, so does not have to be submitted to a specific body for approval. The intention is that as we develop our Service Management capabilities, Service Owners will develop roadmaps and service improvement plans which will be reviewed and approved by the new Service Management Groups. The Service Improvement Planning Sheet is intended to help Service Owners carry out the work detailed in these plans.

Whilst there is no formal approval process for these pieces of work, any changes that come out of the work will be subject to the change management process, so the advice is to get the change in early to get approval in principle for the change before you start work.

The Service Improvement Planning Sheet should be used to set out the work to be done, who is doing it and when. It will also help identify any communications that is required.

High Level Scope

The high level scope is established and mapped to the benefits to be derived.

High Level Plan

A high level plan is drafted, identifying key work packages, resources, costs, dependencies and risks. A project schedule is then formed to provide estimation as to when the project will deliver.

Estimation confidence will be refined as the project progresses through the project lifecycle. As a guide, the following estimation ranges will apply.

Rough order of magnitude (ROM) – minus 25% to plus 75%

Budgetary – minus 10% to plus 25%

Definitive – minus 5% to 10%


Stage 2 - Planning and Elaboration (Initiation) Stage

In this stage we will establish firmly what is to be delivered, by whom and when. We will establish the project controls (risk register, issue list etc.), acceptance criteria and the method by which stakeholders will be engaged. The primary output of this stage will be the Project Initiation Document; it is to be approved before any significant financial commitment is made.



Project Initiation Document (PID)

The PID brings together information that outlines the basis for managing and controlling the delivery of the project scope PID’s will be requested at the ITPB’s discretion.

Project Plan

The project plan will be derived from the requirements catalogue and high level design. It will identify any internal / external constraints (dependencies) and risks. It will expand on the work packages identified during the PPD high level planning exercise to create a comprehensive project schedule.

Requirement Catalogue / RTM

The requirements catalogue and traceability matrix details the functional and non-functional requirements to deliver the project scope identified in the PPD. They should be at a level where each requirement can be tested and verified.

High Level Design 

Building on the outline solution identified in the PPD. It uses the requirements catalogue as an input to determine the high level design and solution architecture. It will take into account the IT Services architecture principals and any known constraints.

 RFP / Tender

Where the project requires the procurement of outside services / technology the institutions Procurement Rules must be adhered to and Procurement Team engaged for assistance where appropriate. Feeding into the process will be the Project Plan, Requirement Catalogue and the High Level Design.

Proof of Concept (POC) 

During the High Level Design and / or Tender process it may be appropriate to develop a Proof of Concept to prove out the proposed scope, solution and affirm vendor capability.

Test Plan 

The test plan outlines the type of tests that will be undertaken to validate delivery of the project scope and its quality criteria.

Cutover Plan 

 In this section we describe how the change is introduced into production e.g. migration, deployment, risk mitigation strategies.

Service Acceptance Plan 

Outlined in this section is the criteria by which the service will be allowed to transition into production e.g. test , cutover sign-off. Further information regarding the service transition process can be found HERE

Stage 3 - Monitoring and Controlling (Delivery) Stage

In this stage we will deliver the project scope per the work packages identified in the project plan. We will assign tasks, monitor progress, deal with issues / risks, report progress to the project board and take corrective actions to ensure that the stage remains within agreed project tolerances.

Depending on the complexity of the project an optional stage boundary, M3a may be employed on completion of the Detailed Requirements and Detailed Design should there be a potential impact to the project scope, cost or schedule.



Detailed Requirements

Depending on project complexity further elaboration of the requirements may be required.

Detailed Design  

Depending on project complexity further elaboration of the detailed design may be required.

Technical Specification

Specifications should be completed outlining how the work package will be translated into a product that fulfils the requirements of that work package.


The product is the end result of the work package; it should be possible to trace the product attributes back to the requirements, scope and benefits of the project.

 Test Plan / Reports

In the previous stage we outlined the test to be undertaken appropriate to the project size and scope. In this stage we create the specific test plans (aligned to the requirements and design) and execute testing. Types of test be undertaken are:

  • Unit
  • System
  • System Integration Testing
  • Performance Testing
  • Operational Acceptance Testing
  • Penetration Testing
  • User Acceptance Testing
  • Regression Testing

 Detailed Cutover Plan

The plan outlined in the PID is refined to a work package / task level and is enacted.

Service Acceptance Preparation & Readiness 

During the stage, progress against the service acceptance criteria is tracked and reported on. Prior to cutover a change request is raised and supporting evidence of acceptance criteria being met is attached for review and sign-off. Where elements of the service acceptance criteria cannot be met as originally planned, waivers must be secured by the appropriate parties.


Stage 4 - Closing (Final Delivery) Stage

The purpose of this stage is to formally close the project and confirm acceptance of the products that the project has produced and recognise that the objectives set during the initiating stage of the project have been met. 



Cutover / Change Request 

Subject to change request approval the physical cutover of the project change is transitioned into production.

User Training 

User training is executed per the cut-over plan, note training could take place pre and post cut over

Lesson Learned 

 Lessons learnt should be captured throughout the project lifecycle. At the end of the project they should be collated and accepted by the team as accurate and true. Where appropriate, the PMO can be used to facilitate a lesson learnt workshop.


It will be agreed as part of the Service Acceptance Criteria if the project should have a warranty period.

This is where the project team remains stood up and provides additional support in the resolution of issues, and supports knowledge transfer to the support teams.

The project will not be permitted to close until warranty period is complete and any issues raised fall within an agreed threshold.

Project Closure

The project closure report will formally close the project, it will outline the scope delivered, acceptance into service, benefits realised and any lessons learnt. It will be approved by the project board, ITPAG and ITPB.


The templates are divided as to the first stage they are required.

They are intended as a guide to the types of information required to support the successful delivery of a project and their use and rigor will depend on the project and needs of the sponsors and stakeholders.

NOTE - tables below are placeholders for templates. Templates will be defined by relevant stakeholders.

Stage 1: Initiating (Pre-Project) Stage



Project Proposal Document (PPD)

Data Governance role definitions for reference 


Service Improvement Document


RAID/Status Report

Project Dashboard

IDM DPIA Risk Assessment 

Risk Assessment





‌Stage 2: Planning & Elaboration (Initiation) Stage



Project Initiation Document (PID)


Project Plan

Project Plan

Service Readiness Assessment

Service Acceptance Preparation & Readiness

Requirement Catalogue / RTM

Requirements Document

RFP / Tender


Test Plan

Test Plan

User Training Plan

Training Plan

Stakeholder Communications

S/H Comms Plan

Stage 3: Monitoring & Controlling (Delivery) Stage



Detailed Requirements

Requirements Document 

EUC Browser Test Template

Test Template

Test Plan / Reports

Test Plan

Service Readiness Assessment

Service Acceptance Preparation & Readiness

Stage Gate Assurance

Project Assurance Checklist

Service Definition 

Definition Document

Service Transition 

Transition Document 

Stage 4:Closing (Final Delivery) Stage



Project Change Request

 Change Request 

Project Closure

 Closure Report

Other Templates



Highlight Report

 Highlight Report