Clinical Dashboard Implementation
Toolkit
(Trust Name) Dashboard –
Project Initiation Document (PID) and Data
Quality Plan
It should be noted that this template is based on the Clinical Dashboard pilot
programme implementations and references to NHS Connecting for Health and the
Supplier are specific to the pilot implementation.
NHS Trusts using this template as a guide are advised to tailor the document in line
with their local approach to the implementation of Clinical Dashboards.
Author:
Version:
Created:
Updated:
Document Control
Version
Date
Amendment History
Reviewers:
This document must be reviewed by the following:
Name
Signature
Title / Responsibility
Senior Project Manager,
Supplier
Trust Project Sponsor
Trust Project Manager
CfH Implementation
Manager
Supplier Programme
Manager,
Page 2 of 29
Date
Version
Approvals:
This document must be approved by the following:
Name
Signature
Title / Responsibility
Date
Version
Distribution:
This is a controlled document.
Whilst this document may be printed, the electronic version should be a controlled
document located in an agreed document store. Any printed copies of this document
are not controlled.
Related Documents:
This document is one of a series of documents which together comprise the Clinical
Dashboard Implementation Toolkit.
The following Toolkit documents may be
referenced by or used in conjunction with this PID:
Ref
No.
Doc Reference Number
Title
Page 3 of 29
Version
Contents
Distribution:................................................................................................................3
Related Documents: ..................................................................................................3
About this document..................................................................................................... 6
Document Purpose ....................................................................................................6
Document Sign-Off ....................................................................................................7
1. Executive Summary .............................................................................................. 8
1.1. Introduction ........................................................................................................8
1.2. Scope ................................................................................................................8
1.3. Deployment Planning .........................................................................................8
1.4. Project Organisation ..........................................................................................9
1.5. Project Resourcing ...........................................................................................10
1.6. Indicative Costs................................................................................................10
1.7. Benefits ............................................................................................................10
1.7.1. End User benefits ..................................................................................... 10
1.7.2. Business benefits...................................................................................... 11
1.8. Issues and Risks ..............................................................................................11
1.9. Assumptions ....................................................................................................11
1.10.
Principal Project Responsibilities ...............................................................12
2. Deployment Workstreams ................................................................................... 13
2.1. Project Support and Planning...........................................................................13
2.1.1. Project Planning Approach ....................................................................... 13
2.1.2. Project Initiation Approach ........................................................................ 14
2.1.3. Stakeholder Engagement and Communications ....................................... 16
2.2. Dashboard Design and Business Change ........................................................16
2.2.1. Business Change Approach ..................................................................... 17
2.2.2. Benefits of Business Change .................................................................... 17
2.2.3. Business Change Activities ....................................................................... 18
2.2.4. Responsibilities ......................................................................................... 18
2.3. Technical Enablement......................................................................................18
2.3.1. Technical Enablement Approach .............................................................. 18
2.3.2. Responsibilities ......................................................................................... 19
2.4. Data Feed Definition and Design .....................................................................20
2.4.1. Data Feed Definition ................................................................................. 20
2.4.2. Data Feed Design ..................................................................................... 20
2.5. Training ............................................................................................................20
2.5.1. Training Approach .................................................................................... 20
2.5.2. Responsibilities ......................................................................................... 21
2.6. Testing and Verification....................................................................................21
2.6.1. Test Approach .......................................................................................... 21
2.6.2. Deployment Testing Activities ................................................................... 22
2.6.3. Responsibilities ......................................................................................... 22
2.7. Transition phase ..............................................................................................22
2.7.1. Transition Approach.................................................................................. 22
2.7.2. Responsibilities ......................................................................................... 23
3. Project Management ........................................................................................... 24
3.1. Project Governance .........................................................................................24
3.1.1. Project Board ............................................................................................ 24
Page 4 of 29
3.1.2. Decision Makers ....................................................................................... 25
3.1.3. Project Delivery Tolerances ...................................................................... 25
3.2. Quality Plan and Management .........................................................................26
3.2.1. Process .................................................................................................... 26
3.3. Project Dates ...................................................................................................26
4. Other ................................................................................................................... 27
4.1. Risk & Issue Management Approach ...............................................................27
APPENDICES ............................................................................................................ 28
Local Appendices ....................................................................................................28
APPENDIX A – Detailed Project Plan .................................................................. 28
APPENDIX B – Trust Stakeholder Engagement and Communications Strategy .. 28
APPENDIX C – Trust Business Case .................................................................. 28
APPENDIX D– Job Descriptions ......................................................................... 28
Page 5 of 29
About this document
Document Purpose
The Project Initiation Document (PID) is the means by which the Clinical
Dashboard Pilot Project for (Clinical Areas) at (Trust Name) Trust is
documented and presented for approval by the Project Board. It draws together
the preparation and initialisation work and is a key document in the Project
Toolkit, providing a reference for future activity.
Once agreed and Signed Off by all relevant parties the PID becomes a
Controlled Document. Any subsequent changes to, or deviation from, the PID
are subject to formal Change Control Procedures, involving further formal
approval and sign-off.
The PID is a key deliverable and is required by Connecting for Health (CfH) as
a part of the documentation package supporting the work-order for the Project.
Formulation of and agreement to the PID involves all Trust stakeholders
(Operations; Clinical; IM&T; Training; Finance; Risk Management; Information
Governance; etc), and the supplier. Once signed off it indicates commitment to
resourcing and outlines the approaches to be followed in delivering the project
and provides commitment to proceed on behalf of the Trust and CfH.
The PID aims to:
 Build upon the outline set out in the Project Brief at a greater level of
detail;
 Demonstrate that the project has a sound overall basis from which to
proceed;
 List the agreed project objectives and scope as described in the
requirement;
 Act as a base document against which the Project Board and respective
Project Managers can assess progress;
 Agree and document the responsibilities and authority of the parties
involved in the project;
 Show the Project stages, tasks, milestones and deliverables
(supplemented with a detailed project plan).
 List the agreed resources required by all parties including the costs of the
design, development and delivery by the supplier.
 Once signed off, formally initiate the Project;
Until the PID is approved, project teams will not be formally mobilised beyond
the appointment of a single Project Manager. Once the PID has been signed
off by CfH, the Trusts and the supplier, the project may move into the next
Stage.
The PID includes Local Appendices containing further detailed information
specific to the implementation, for example the detailed local Project Plan,
Page 6 of 29
agreed dashboard requirements, xxx.
Document Sign-Off
Sign-off will signify that the Project Board has confidence that the project is
properly prepared and initiated and that project plans, resources and
management processes are in place for work to commence and continue
successfully to project closure.
Additionally, it will give the project team the confidence that they are working to
a clearly defined set of objectives with all of the required resources and support.
Sign-off is typically by:




CfH Project Sponsor
Trust Project Executive
Trust Chief Executive
Supplier Programme Sponsor
Page 7 of 29
1. Executive Summary
1.1. Introduction
A Clinical Dashboards prototype project was conducted by NHS Connecting for
Health (NHS CfH). Following the encouraging success of the first prototypes,
the Clinical Dashboard Programme has been established within NHS
Connecting for Health, and this has initiated a Pilot Clinical Dashboard (PCD)
programme, which will extend the reach of Clinical Dashboards to a broader
community of clinical teams across multiple Strategic Health Authorities (SHAs).
The Clinical Dashboard represents a change in focus to enhance support for
NHS Clinicians in the delivery of improved quality of care to patients. This
direction is set out in the Darzi Next Stage Report and the Health Informatics
Review.
Clinical Dashboards present management information visually to clinical teams
regarding a diversity of key measures including, but not limited to:
- quality of patient care
- performance monitoring for clinical engagement
- operational effectiveness
- clinical outcomes
- patient experience.
Each dashboard is tailored to the requirements of the local clinical teams and
will also gather important information that when analysed will support improved
patient safety.
1.2. Scope
This scope of this project is limited to the provision of (Add detail of relevant
dashboards to be deployed) Clinical Dashboards to (Add Trust Name) Trust
to support the following clinical areas:

(List Clinical Areas)
The dashboard will consist of a number of screens as detailed in the metrics
requirements specification documents embedded below:
Embed metrics requirements specifications here
1.3. Deployment Planning
The deployment plan is illustrated below:
Page 8 of 29
Go Live is defined as being when the first Dashboard is used by trained End
User staff following a go-live decision by the Project Board.
Go Live is scheduled to commence on the following dates after completion and
sign-off of User Acceptance Testing and agreement of the Ready for Go-live
Milestone.
Clinical Department
Go-live date
The contracted deliverables are deemed to be complete when the Dashboards
have been technically enabled, at least two users have been trained to use the
system and live use has commenced.
1.4. Project Organisation
The following organisational structure has been set up in order to deploy the
solution.
Organisation Exec Sponsor:
(Add Details)
Organisation Project Manager:
(Add Details)
Organisation Clinical Lead:
(Add Details)
Organisation Information Governance
Lead:
(Add Details)
Organisation IT Lead:
(Add Details)
Supplier Programme Manager:
(Add Details)
Supplier Dashboard Consultant:
(Add Details)
CfH Implementation Manager:
(Add Details)
Page 9 of 29
1.5. Project Resourcing
OCT
SEP
AUG
JUL
JUN
MAY
RESOURCE
(HOURS)
NHS Business Change
NHS Trainer
NHS Project Manager
NHS Clinical Lead
NHS IT Department
NHS Clinical Support
NHS PSO/AUDIT/INFO
NHS TOTAL (DAYS)
Supplier Dashboard
Consultant
Supplier Technical Team
APR
Below is the predicted resource requirements in man / days for both the NHS
and the supplier aggregated into total man days. The SUPPLIER days stated
are as agreed in the Work Order with CfH.
Total
(Days)
OTHER TOTAL (DAYS)
Total (Days)
The table has been constructed as a baseline for the project and does not take
account of operational pressures.
1.6. Indicative Costs
Indicative budgetary costs should be entered here - for completion by CfH
1.7. Benefits
Formal Benefits Realisation will be carried out by the Trust and CfH to ensure
all objectives have been met. Project Assurance will ensure that the project is
delivered to the required quality expectations and presented to the Project
Board for formal sign-off at the end of each stage. This section highlights the
key immediate and potential benefits of that project that will be delivered.
Further details will be included in the separate Benefits Realisation Plan.
1.7.1. End User benefits
•
•
•
•
•
It must support users’ tasks & informational needs
It must be easy to learn and to use
It must increase productivity and reduce errors
It is consistent and aesthetically pleasing throughout
It will have useful and understandable information and help
Page 10 of 29
•
•
It will appear trustworthy, secure and reliable
It will provide access to relevant information appropriate to all authorized
users
1.7.2. Business benefits
•
•
•
•
It is USED by the target user population
It meets business requirements and expectations
It can assist in achieving planned organisational transformation
It maintains and enhances the Trust’s reputation
1.8. Issues and Risks
The key issues and risks affecting the project are noted below.
Key Risks
The Risk Log is maintained as part of the weekly Checkpoint Report. The
following is extracted from the current report valid on (Date).
Insert Risk Log Here
Key Issues
There are no issues currently identified. These will be recorded in the Issues log
which forms part of the weekly Checkpoint Report as and when they are raised.
1.9. Assumptions
The Key assumptions for the project are noted below.
Workstream
Area
Assumption
All
Resources identified as being critical to the project can be made available
from the Trust, CfH, supplier and other NHS teams for training and
implementation tasks. The plan assumes that there is constant NHS
resourcing from PID sign off through to transition to services.
Clinicians will be engaged as necessary to support the project
Project facilities and accommodation will be provided as needed for the
respective project teams
The Trust local Networks are capable of supporting the solution.
Resources
Resources
Technical
Readiness
Technical
Readiness
Technical
Readiness
Training
Installation,
Configuration and
The NHS team will provide all necessary technical infrastructure, including
IT hardware.
A suitably trained and qualified Trust first-line helpdesk environment will be
available to provide on-going support for the solution.
All training facilities and materials will be provided in sufficient time for all
training activities
The (insert Trust Name) Trust team will provide any required interfaces
between the Trust data systems and Clinical Dashboard.
Page 11 of 29
Integration
Installation,
Configuration and
Integration
The supplier is not responsible for approving or recommending the clinical
content within the solution. Any change to clinical content, clinical practice
or guidance is the responsibility of the (Trust Name) Trust. Requirements
identified to be incorporated into the system will be agreed at Project level.
No new functionality will be included unless they have been through the
approval process within the Project Structure.
1.10. Principal Project Responsibilities
Requirement
Deployment of the Dashboard solution to (insert Trust Name) Trust
Training staff in sufficient time for Go Live including handover and administrative
responsibilities.
Project communications
Provision of appropriate hardware & local infrastructure (e.g., PCs, Printers,
etc.) to meet the requirements of the Dashboard.
Mapping of staff to user roles
Confirmation that First Level Helpdesk provision
Project Management
Business Change
Page 12 of 29
Responsibility
NHS
SUPPLIER









2. Deployment Workstreams
The management approach for this project will be structured as follows. The
workstreams will be discussed further in this section.

Project Support Office (PSO)/Stakeholder Communications and
Engagement

Data Feeds

Business Change

Training

Technical Enablement

Testing & Verification

Transition to Service Delivery
2.1. Project Support and Planning
2.1.1. Project Planning Approach
This project will implement the Dashboard into X Clinical Department(s) at the
location identified in 1.2 above whilst equipping the Trust with the methodology,
knowledge and tools to continue the roll-out at a pace and time of its choosing.
Go Live dates are shown in the following table. The system will be available to
a maximum of (insert max no of end users) End Users.
Clinical Department
Go- Live date
The plan converges the following workstreams to allow End User Training to
commence on (Add dates as relevant).
WORKSTREAM / PHASE
PROJECT SUPPORT OFFICE AND
STAKEHOLDER ENGAGEMENT
DATA FEED DEFINITION
BUSINESS CHANGE
TECHNICAL ENABLEMENT
TRAINING
TESTING AND VERIFICATION
TRANSITION
Initiation
Page 13 of 29
Development
Implementation
Transition
Project Team meetings have been scheduled to occur on a weekly basis, with
Project Board meetings scheduled monthly.
This deployment option reflects thinking and agreements at the time of writing. If
the project circumstances change then this may be subject to adjustment in
later stages of the project. Scoping decisions for subsequent deployments of
the Clinical Dashboard solution will be determined by the Trust.
The Detailed Project Plan is available in Appendix A.
2.1.2. Project Initiation Approach
Project Organisation
The CfH team mobilised to date includes an Implementation Manager and
support resource. From the Trust, it includes a Project Manager and a Business
Change Lead. When the PID is signed off, the CfH and NHS teams will mobilise
to meet the resource requirements documented in the project plan.
Resources must be identified by name by the Trust Project Manager as soon as
possible and no later than three weeks prior to their planned start date as per
the project plan. If resources are not identified and committed in a timely
manner it is likely that subsequent activities and the Go Live date will be
delayed.
NHS Roles and Resources
Resource
Workstream
Role Identified
Description
Planning &
Mobilisation
(Trust Name)
Project Manager
Responsible for the day to day
management of the NHS project team
and the project delivery.
Design and
Business
Change
Trust Business
Change Lead
Management of the Communications
Plan
Management of the Business Change
Plan
Management of the Delivery of Business
Change
Work with CfH to document the Local
Impact Assessment
Work with CfH to create the Business
Change and Cultural Recommendations
Execute the Business Change Plan
Design and
Business
Change
Trust Clinical
Champions
Help Design the Clinical Dashboard to be
delivered.
Help define the anticipated changes
Communicate and encourage new ways
of working required by the change
Becomes the primary point of contact for
the peer group
Page 14 of 29
Resource name
Resource
Workstream
Role Identified
Description
Resource name
Support training of peer group
Training
Training Lead
Management of all aspects of Training:
Training Delivery Schedule, Ensuring the
NHS Trainers are trained, Training the
End Users and Post Go-live Performance
Support.
Training
Trainers
Delivering Dashboard application training
to NHS end users.
Technical
Enablement
Trust Installation, IT management of network and
Configuration and infrastructure deployment and support.
Integration Lead Management of all integration activity for
the Dashboard solution and the local
environment
Technical
Enablement
Trust
Configuration
Specialist
Provide requirements for local
configuration
Technical
Enablement
Trust Data Lead
Provide requirements for local data feeds
requirements that are presented to the
CfH/supplier Data lead.
Deployment
Test &
Verification
Trust Deployment Work with the Installation, Configuration
Test and
and Integration and Data Migration teams
Verification Lead to plan the component and deployment
tests
Management of the Verification Period
post Go Live
Service Model Trust Transition to Review and implement changes to the
Services Manager current IT Service Processes, i.e.
Release Management, Change Request
Management etc.
Supplier and CFH Roles and Resources
Resource
Role Identified
Workstream
Planning and CfH
Mobilisation Implementation
Manager
Solution
Design
Business
Change
Description
Responsible for the overall management
of the Local Service Provider (LSP)
project team and the project delivery.
Dashboard
Consultant
Main responsibilities of the SUPPLIER
Dashboard Consultant include:
Help Design and to document the
Dashboard to be delivered.
Work with the Trust to complete
Requirements and Design and
subsequent detailed implementation plans
Monitor and manage the design,
development and deployment of the
dashboard solution with the Trust
CfH Clinical SME Main tasks include: attendance at
requirements assessment workshops,
assist in detailed functional requirement,
Page 15 of 29
Resource name
Resource
Workstream
Training
Technical
Enablement
Technical
Enablement
Technical
Enablement
Deployment
Test &
Verification
Role Identified
Description
support business change activities,
support communications activities
Supplier Training The main responsibilities of the
SUPPLIER Central Trainer include:
Lead
Responsible for facilitating NHS training
sessions and to deliver general training
skills to trainers.
Supplier Technical Responsible for designing the Dashboard
together with Data Load and Presentation
Lead
layers.
CfH Technical
Responsible for establishing the
supporting environment, application and
Lead
interface servers, creating the database
and providing the application installation
Supplier Testing Responsible for managing all site-based
deployment testing and supporting go-live
Lead
activities
CfH Test Manager Responsible for creating draft and final
verification reports, gaining feedback and
establishing lessons learned and benefits
realised.
Resource name
SUPPLIER
Team
Central
SUPPLIER
Team
Central
SUPPLIER
Team
Central
SUPPLIER
Team
Central
CfH Team
Project Accommodation and Facilities
Desk space and facilities for members of the project team will be provided by
the Trust. This will be at Trust premises in ? or other such locations as are
agreed from time to time.
2.1.3. Stakeholder Engagement and Communications
It is essential that proper communications are present in order to ensure that
Stakeholders are engaged at the appropriate time and continue to be informed
of progress and developments.
A Stakeholder Engagement and Communications strategy is included as
Appendix B of this PID.
2.2. Dashboard Design and Business Change
Business Change is an NHS responsibility with CfH providing a supporting and
advisory capacity. This will be lead by [Add appropriate details], the Trust
Business Change Lead. Full engagement and cooperation with the Trust will be
paramount in order for the project to deliver benefit to patients through Service
Improvements.
This is achieved through the Design Workshops that have taken place and have
resulted in agreed design documentation (Metrics Design and Definition).
Page 16 of 29
2.2.1. Business Change Approach
Business Change activities are key to the delivery of a successful deployment
of the Clinical Dashboard. The primary aim of these activities is to ensure the
Dashboard Design and the reasons behind the choice and presentation of
individual Metrics is agreed by all participants. The Business Change
workstream will be required to ensure that the system implementation
supports the Trust’s business objectives and meets the satisfaction of end users
after Go Live.
The term Business Change in the context of this deployment refers to the nontechnical activities to be undertaken to address the impacts of a new
information system implementation on the Trust’s operating processes and
staff. It minimises implementation risks by identifying and analysing potential
process changes and defining the best approach to deal with them in advance
of Go-Live. More specifically, Business Change activities are important in:

Ensuring ownership of new business processes and Benefits Realisation

Ensuring a high state of readiness is achieved before Go Live.

Minimising disruption to Trust operations before and after Go Live.

Maximising the Trust’s performance in using the Clinical Dashboard
solution.

Engaging and involving all key stakeholders.
2.2.2. Benefits of Business Change
Trusts obtain tangible benefit from well directed Business Change activities.
The identified benefits include:
Improve Performance: Business Change can help to focus on how the Trust
can improve performance in certain areas of the business and streamline
working processes.
Time Saving: The new Clinical Dashboard solution has functionality that the
Trust can use to reduce the time it takes to report on and identify situations that
require attention.
More Effective Training: The output of the Business Change activities will also
feed into the Dashboard training that the Trust receives. It will help staff to
receive training that is tailored according to local needs.
Reduce Negative Impact: Ultimately, effective Business Change will help to
reduce any adverse impact amongst staff that the introduction of a new system
can have.
Page 17 of 29
2.2.3. Business Change Activities
The following is a summary of initial business change activities.

Align the Dashboard implementation with the vision of the organisation
and the anticipated outcomes at an early stage.

The business change team seeks to understand current ways of working
to develop a “Current State” process map. It is useful to have these
maps developed prior to metrics definition workshops.

Workshops are held to establish benefits that the system will deliver, in
accordance with the Design of the Dashboard, and to assign owners to
those benefits so they can be tracked and measured.

A Business Change Plan will be documented with all the business
changes. This plan will be signed off by the business change lead and
all major stakeholders.

On-going communication activities will be maintained to ensure buy-in
and ownership at all levels of the organisation.
2.2.4. Responsibilities
Requirement
Provide guidance, toolkit and methodologies to manage, perform and
complete BC activities
Map Current State business processes
Define high level benefits plan
Develop and execute a communications plan
Analyse and gather templates and reports from the Trust for workshops
Run Local Impact Assessment Workshops
Map Future State business processes
Identify changes and confirm benefits management plan with key
stakeholders
Develop Business Change Plan
Execute Business Change Plan
Plan and execute pre and post go-live testing and document BC Issues
Responsibility
Trust
CfH/Supplier











*
*
*
*
2.3. Technical Enablement
2.3.1. Technical Enablement Approach
The Technical Enablement, Configuration and Integration workstream is
concerned with:

Connectivity and Networking
*
Whilst Business Change is a Trust responsibility, CfH will provide assistance in a supporting
and advisory capacity.
Page 18 of 29

Database and Web Server Installation

Database Configuration, DBA and SharePoint Configuration

Terminal Device configuration
Connectivity and Network
This activity ensures the various networks are configured to allow the
application to function in respect to;

Domain Management

System Access and Security

Active Directory configuration and integration.
Server Installation
The Technical Enablement Team must ensure that the two Dashboard Servers
are delivered in good time to commence implementation and the configuration
aspects.
Database Configuration
Database configuration will be carried out upon installation of the software.
Security and permissions are agreed early on in the process and documented
so the transition to site management where applicable can take place.
Peripheral Device Configuration
This activity relates to the identification of existing compliant peripheral
hardware in areas where the Dashboard will be deployed and the roll-out of new
devices where necessary. The following components may be needed to
support the Dashboard Solution:
 Desktop PCs

Local Network devices

Patient Area viewing screens (if required)
2.3.2. Responsibilities
Requirement
Ensure NHS Network (N3) connectivity at sites
Set up central configuration
Determine local configuration
Set up Local Device Configuration
Deploy Dashboard Solution application to end-user devices
Page 19 of 29
Responsibility
Trust
CfH/Supp
lier







2.4. Data Feed Definition and Design
2.4.1. Data Feed Definition
A key area of development arising from the Dashboard Design and the Metrics
contained therein is that of Data provision. The Trust has identified what data
feeds are available to provide the data items that will be presented on the
Dashboard at the relevant and agreed intervals.
This is defined as part of the Metrics Data Feed Definitions and is provided as a
series of test data files that are examples of the specifications of data that the
Trust will provide, or already provides, in the agreed format (text file,
spreadsheet, database, etc).
2.4.2. Data Feed Design
The design of the method used to upload the Data Feeds is carried out as the
first part of the Development Phase. The design is carried out by the supplier
and describes what process stages are involved, where the data is stored at
each stage and what processing is required to handle it (for instance, the
production of data cubes) and the stored procedures required to supply the
Metrics that are displayed by the Dashboard.
2.5. Training
2.5.1. Training Approach
Before using the Dashboard application, end users will need adequate training
that meets their local needs. The supplier will provide training for all Trust
trainers together with training materials that can be tailored as necessary to fit
local requirements.
Users can start to access and use the Dashboard as soon as it goes live with
the local data feeds, so the imperative for a ‘big bang’ go live is avoided.
However, the introduction will be most effective where users are brought on
stream within a short period of time. It is recommended to train end users no
sooner than two weeks before go-live to ensure that the new skills remain fresh.
Senior managers must be involved to help release and ensure attendance of
staff to aid the training programme.
Based on the baseline assessment information, a maximum of {Add relevant
user number limit} users will need Dashboard training. Considering current
training experience, the total number of training sessions should include:
 20% contingency for the users who do not attend (DNA) and have to be
rescheduled

10% for re-training personnel needing additional time to master the
technology and/or working practices changes
The Training Plan should be based on no less than 2 training slots with a
maximum of 12 people on each course.
Page 20 of 29
End-user training will require approximately 3 hours in the classroom.
Trust training facilities that will be used include training rooms in the following
locations:
Facilities
Max No. of students
per Classroom
Enter details of the available training facilities in the table above
The training timeframe can be fulfilled by having the following resources:
1 full-time classroom
3 full-time trainers
Template training materials will be provided by the supplier. The NHS may tailor
this material to fit local requirements.
2.5.2. Responsibilities
Requirement
Responsibility
TRUST
Provide Trainers with suitable experience
Make available the necessary training facilities
Provide training materials
Tailor training materials to fit local needs
Schedule and train end users
CfH/Supplier



2.6. Testing and Verification
2.6.1. Test Approach
The test phases are composed of a series of pre-determined scripts that are run
to confirm that the hardware and software are installed and working together in
the manner expected.
System Testing is a rigorous testing of the Dashboard software for defects to
ensure that when delivered to the Trust the software behaves as designed.
This, and the subsequent Integration Testing, is performed by the supplier. The
Trust takes delivery of the Dashboard and carries out Acceptance and Ready
for Operations Testing. The most important deliverable of the testing process is
the Test Summary Report which lists condition metrics, incidents encountered
and results. This must be signed off before the Trust can move into the Go Live
phase. As part of this, a detailed ‘Work-off’ plan will be prepared for issues
Page 21 of 29



deemed serious enough to be outstanding at go-live. The Work-Off plan must
be agreed by the Trust, CfH and the supplier prior to submission.
Detailed Testing activities will be set out in the Test Plan and Test Specification.
2.6.2. Deployment Testing Activities
The areas that will be covered during Deployment Testing include:

Data Loads

Testing Data Load Processes

Validating Data Loads

Testing PCs

Testing User Access

Testing Security
These will be defined within the Test Plan and Test Specification, together with
Success/Fail criteria.
The key output of the deployment test will be the Test Report; this will be
presented to the Project Board for sign-off. When approved a Go Live
Authorisation will be issued and the project will proceed to go live.
2.6.3. Responsibilities
Requirement
Producing deployment test documentation (Test Plan, Test Specification)
“Localisation” of test documentation to reflect the [ TRUST ] project
Assisting and managing deployment testing activities
System Testing and Report
Integration Testing and Report
Acceptance Testing and Report
Ready for Operations Testing and Report
Responsibility
TRUST CFH/Supplier









2.7. Transition phase
2.7.1. Transition Approach
Transition activities mostly concern the handover of responsibility for the
operational management of the Dashboard application and ensuring that Trust
IM&T staff have the required capability and knowledge to proceed post Go Live.
Arrangements for help desk support are also documented and discussed to
ensure the efficient resolution of support calls.
Page 22 of 29
2.7.2. Responsibilities
Requirement
Responsibility
TRUST

Helpdesk processes, tools and people
Helpdesk training
Level 1 Helpdesk Support
Level 2 support
CFH/Supplie
r




Page 23 of 29
3. Project Management
3.1. Project Governance
The Project Team will report, through the Project Manager, to the Project Board.
The Project Board has a Sponsor {insert name of Sponsor} and has a
responsibility to the Programme Board at CfH level.
The Project Manager and Project Board will agree what levels of issues can be
resolved at local level and what issues require escalation.
3.1.1. Project Board
Project Board
Principal Role
Name
Organisation Position
Status
Project Executive
Trust
Trust Project
Assurance
Senior User –
Primary
Business Change
Trust
Director of Clinical Member
Services
Director of IT
Member
Trust
Medical Advisor
Trust
Project
Management
Office
Trust Technical
Support
CfH
Implementation
Manager
Senior Supplier –
Primary
Trust
Business Change Attendee
Manager
?
Attendee
Trust
IT Department
Attendee
CfH
CIO /
representative
Member
Supplier
Programme
Manager
Member
Member
The Project Board has overall responsibility for the project, including:

Monitoring project status and resolving issues that cannot be resolved at
Project level.

Agreeing changes to agreed milestones.

Agreeing changes to local project costs beyond tolerance levels.

Agreeing requests for additional services.
Project Management
The Trust Project Manager for the Clinical Dashboard Project will have the
following responsibilities:
Page 24 of 29

Monitoring project status and resolving issues that cannot be resolved at
Project Team level

Completing a weekly joint checkpoint report in conjunction with the
supplier project manager/dashboard consultant for distribution to the
Trust Board, CfH programme management and Supplier programme
management.

Escalating issues to the Trust Project Board

Ensuring necessary resources for the project are available and
committing to project resources at each stage of the plan

Reviewing each completed Stage and approval to proceed to the next
stage by signing End Stage reports
3.1.2. Decision Makers
The following table summarises the proposed decision-making process for
activities within the project.
Actions
Approving Project
Plans & PID
Approving Project
Board Composition
Agreeing Changes
to Interim
Milestones
Agreeing End of
Stage criteria have
been met and
Approval to
Proceed
Agreeing Changes
to go-live date
(extending or
bringing back)
Agreeing Changes
to local Project
Costs
Programme
Board
Monitors
Project Board
Monitors
Approves
Project Team
Approves
Approves
Proposes
Approves
Proposes
Monitors
Approves
Proposes
Monitors
Approves
Proposes
3.1.3. Project Delivery Tolerances
Timescales for any activity in the project plan will be adhered to ± one week
tolerance level. Any deviation or likelihood of deviation, to the project timescales
that exceeds this tolerance should be communicated to the Trust Project Board
by means of a Status Report and resolved where possible to stay on schedule.
If not resolved within the outlined project tolerances then the Project Manager
should report to the Project Board by means of an Exception Report. A change
Page 25 of 29
request may then be required for additional resources, budget and change in
schedule or method of delivery. However, every effort will be made to achieve
initial deployment delivery within the agreed timeframe.
3.2. Quality Plan and Management
Quality Management aims to ensure that the defined quality objectives are met,
stakeholders’ and sponsor’s expectations are fulfilled and each individual and
team apply the approved quality principles, standards and methods in a
consistent manner.
The Project Board will agree an approach to how Quality will be assessed and
maintained throughout the Project.
3.2.1. Process
Statements should be completed against the following topics:







Decide overall Project Assurance approach (Project Structure,
assessment of documentation etc).
Agree expectations and Acceptance Criteria (i.e. the project’s overall
success factors for the Dashboard delivery).
Agree the approach for the control of changes.
Agree the use of any existing Quality structures or systems within the
Trust or related Quality Standards that are adhered to.
Establish any Data Quality assurance needs for each of the project
outputs or documents.
Identify Quality role responsibilities.
Agree that the content of the above constitutes a Quality Plan.
3.3. Project Dates
Actions
Agree Project Brief
Agree PID
Prepare for Go Live
Go Live
Date
Page 26 of 29
4. Other
4.1. Risk & Issue Management Approach
Risks and Issues should be determined, documented and managed.
Risks and issues will be raised, escalated and managed as follows:





Risks and Issues will be owned by individual members of the relevant
work streams.
Risks and Issues will be maintained and itemised as a part of the joint
project weekly checkpoint report.
Risk owners will give updates on any of their risks and issues where
applicable at the weekly Project Team meetings (formal standing agenda
item for meeting). New risks and issues are raised and allocated to
individuals for resolution.
If the risk or issue cannot be resolved by the Project Team, it is escalated
to the Project Manager.
If the risk or issue cannot be resolved by the Project Manager then it is
escalated through to the Project Board.
Page 27 of 29
APPENDICES
Local Appendices
The accompanying project plan is a live, active and working document which
was accurate at the time of issue of this PID. Later changes will not be
reflected here but are available through Trust Project Support Office.
APPENDIX A – Detailed Project Plan
A copy of the Detailed Project Plan should be attached here
APPENDIX B – Trust Stakeholder Engagement and Communications
Strategy
A copy of the Trust’s Stakeholder Engagement and Communications Strategy should be
attached here
APPENDIX C – Trust Business Case
A copy of the Trust’s Business Case (OBC, or, if available, FBC, should be attached here
APPENDIX D– Job Descriptions
Project Sponsor
The Project Sponsor will be a senior director member of the Trust or Trusts
reflecting the importance of this project to the Trust’s on-going business. It will
not be a full-time role, but it will require regular involvement in terms of senior
engagement with NHS CfH and the supplier.
Project Manager
The project will be managed by a full time Project Manager who will coordinate,
manage and report on all aspects of the Project, ensuring that workstreams are
engaged and all stakeholders are informed of progress.
Dashboard Consultant
This role will form the mainstay of the supplier’s customer-facing team. It
requires individuals who understand healthcare information requirements,
relating them to the medium of the clinical dashboard, and working with Trusts
to define and agree their local needs from project scoping right through to golive. A critical and dedicated role, the Dashboard Consultants will be full-time
and will be involved in more than one pilot depending upon their particular
specialities, and more than one Dashboard Consultant will be involved in each
site.
In addition to their product-related work, Dashboard Consultants will be in a
good position to carry out any project management activities that are required to
support NHS CfH project management colleagues, e.g. ensuring that the
outputs, deliverables and milestones of their respective pilot projects are
achieved in accordance with the plan agreed during project scoping, and
production and maintenance of all project documentation together with
Page 28 of 29
preparation of materials required by the programme for the on-going
development of the Dashboard toolkits.
Test/training Lead
This combined role has been formulated following success of individuals
working on data warehouse and dashboard implementations, where
complementary skills have shown that it can be an effective way of promoting
progress for on-site staff. The requirement for the supplier to deliver end-user
training as well as technical training of the Trust’s information and IT user team
has added a significant level of staff time to this category, so their further
involvement in site-level testing will help to provide consistence and a good
customer relationship focus. The Test/Training leads will also be required to
actively participate in programme-level work in support of the requirement for
schedule 4.2-compliant testing.
Technical Implementer
The technical implementer’s role will be to work with the IT specialists across all
parties to specify the technical platform and ensure that, once it has been
installed and commissioned across local networks, the solution software can be
deployed and configured. It will requires the ability to liaise with and instruct
Trust IM&T staff and to assist with the resolution of technical network and other
difficulties encountered at local level, as well as direct involvement with the
supplier staff in the development and deployment teams.
Development Lead
A Development Lead will be required to participate in project scoping and
initiation discussions to assist in the development of the project scope and PID.
This will help to ensure that development issues or difficulties can be identified
and address as early as possible and that there is a minimum of to-and-fro
between teams who might otherwise operate separately.
Page 29 of 29