IT ServicesStaff

Services

Project Management Framework

The Project Management Framework is a high level framework, supported by a Project Management Methodology, in this case Prince 2, project stage boundaries (milestones) as well as supporting tools and templates to enable projects to be started and justified and then managed through to successful delivery of business benefits.

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

Innovation

Service Improvement 

Small

Medium 

Large

Cost 

 Staff time only

 Staff time only

< 25k + staff time 

< 50k + staff time 

 >50k + staff time

Schedule

Time boxed

< 80hrs effort

< 3 Mths ET*

< 9 Mths ET*

 > 9 Mths ET*

Team size 

1-3

1-3

< 5

< 10

> 10

Third parties

POC permitted ex. contract

 Existing contracts only

 Single supplier

2 – 3 suppliers

 Multiple suppliers

Business risk / criticality

Low

Low

Low

Medium or Mandatory

 High or Mandatory

Justification

CBA Potential

Justified CBA

Low CBA

Medium CBA

 High CBA

Technical / Architecture risk

TBD

None / Mininmal

Low

Medium

 High

CBA – Cost Benefit Analysis

ET* - Elapsed Time 

Service Improvements

Service Improvements

Scope

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.

Approach

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.

 

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.

Artefacts

Brief

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 effected by the project e.g. End User Computing, Help Desk 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.

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%

 

M1 - Project portfolio Document (PPD)

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.

Artefacts

Brief

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 policy must be adhered to and Procurement 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

M2 – Project Initiation Document (PID) - Template

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.

Artefacts

Brief

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.

Products

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.

M3 – Service Acceptance Preparation & Readiness

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. 

Artefact

Brief 

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.

Warranty 

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.

 M4 – Project Closure - Template