Becoming a chief information officer in the NHS is a big step. To recognise this, the Health CIO Network is putting together a handbook for health CIOs. If you would like to contribute to a chapter, or have a great idea for one, then contact Digital Health managing editor Lyn Whitfield.
So, you’ve been put in charge of a large information technology project, but I bet everyone is saying: “This isn’t an IT project, it’s a business change project”. I like to think these are two sides of the same coin. You can’t do one without the other. So a successful project that has technology at its heart needs to have:
As a chief information officer, you’ve got to be the translator between these two groups. You also need to take into account several key considerations at each stage of the project.
I see a lot of projects in which a project initiation document– which is one of the key tools in PRINCE project management methodology – is written as an afterthought, often in time for a review or audit. This isn’t a good idea.
If you write a proper PID at the beginning of a project, and get senior management and stakeholder agreement to the PID before you start, it will make life much easier as the project goes on.
What should be in a good PID? The key point to remember is that it doesn’t need to be some lengthy, complicated and abstract theoretical work. It needs to be the start of a good story – one which will become the basis for the business case later on.
It should:
Then get everyone – and I mean everyone, including all executive board members as well as service managers, general managers and clinical directors – to sign up to the PID. IT projects are disruptive and most people don’t like disruption and change. Getting their buy-in before you start will be a real help down the line.
You can then start preparing an outline business case, which will look at all the options available and make a more accurate assessment on the economic value of each option taking risks, benefits and costs into account. You may find it helpful to use the government’s 5 Case model toolkit to help you with this.
The OBC will identify the “preferred option” – in other words, the one that provides the best value for money once all the factors have been taken into consideration.
Once the outline business case has been approved you can start the procurement phase. Even before then you should start what is known as “soft market engagement”.
This lets you talk to potential suppliers in an informal way prior to the start of a formal procurement, which will help you shape your requirements and check likely costs of the project. The sort of questions you need to be asking during this phase are:
To start the procurement, you will need to select your procurement route. The value of a large IT project will almost certainly require you to conform to the European rules on public sector procurement. Despite Brexit there are no current changes to these rules.
The Mills & Reeve procurement portal is a really useful tool to explain the various types of OJEU (Official Journal of the European Union) procurement.
On the surface it appears complex and time consuming. However, if you have clearly specified the requirements and have agreed how you will evaluate the bids then your procurement and legal advisors will be able to help you through the process.
You should always look to see if there is government framework contract in place – check Government Digital Marketplace – as this can significantly reduce timescales as well as procurement and legal contractual effort. It will also save money.
It is really important to avoid writing a specification which has thousands of lines saying “the system must do this” or “the system must do that”.
Firstly, you and your users are unlikely to be experts in system specification and most users will tend to describe what they do at the moment, so you will lose a valuable opportunity to introduce process change, efficiencies and standardisation.
Secondly, if you write a detailed specification along these lines, the suppliers will have to respond in detail and you will have to evaluate and score each response. On the whole suppliers will say “yes” to everything and you will have little opportunity to differentiate between supplier solutions.
Instead, you should set out your requirements so that suppliers have to demonstrate how they will support the business in achieving its aims and outputs. For example: “describe how your system will help us drive patient safety” or “show how your system can help clinical staff with appraisal and clinical revalidation”.
Ask suppliers to demonstrate their systems against tightly scripted scenarios that you have devised and which will help you score and differentiate between solutions. Don’t just let them show you what they want to demonstrate. Your evaluation team(s) should include clinical and admin staff as well as IT staff.
The system you choose should be configurable, so that you can tailor it to your needs. Make sure that the supplier is prepared to train your staff so that you don’t need to go back to them each time you need configuration changes in the future - for which they will charge.
Above all, resist the assertions from users that “we are special”; “we do things differently here”; “we need bespoke development”. In the main you will be buying applications which have been developed by specialist suppliers and are in use in hospitals and clinics throughout the UK and the rest of the world.
Apply the 80/20 rule and use commercial off-the-shelf applications whenever you can – it will be more cost effective to implement and make it easier to introduce standardisation.
Use external consultants and contractors sparsely – they are expensive and once the project is finished they will move on with little residual transfer of expertise. Staff seconded from clinical and admin posts also have the advantage of understanding existing organisational processes and having good contacts with their colleagues.
That said, most organisations are reluctant to let good frontline staff be allocated to project work. This is short-sighted and I suggest arguing strongly to have the best and most competent staff.
Don’t just take staff who are given to you but implement some formal recruitment and interview process. This is an investment for the organisation’s future. Do not expect staff to take on project work in addition to their day job – this always ends in tears.
Make sure you have strong project communications during the deployment phase. Use all communications tools – email, newsletters, posters, social media – but don’t forget the importance of face-to-face communication. Make sure you get your project on the agenda of lots of regular departmental and clinical meetings and make time to brief clinical colleagues and operational managers personally.
Involve everyone in the implementation phase and use techniques such as appointing super-users, carrying out dress rehearsals, and conducting formal go-live readiness assessments.
It goes without saying that training is essential – and you need to work with your HR department to find ways to make training mandatory. It’s often useful to retain a portion of your training budget for after go-live – users don’t always pay attention until reality hits!
You also need to make sure that all your user accounts and passwords are set up accurately for the various roles in the new system – being unable to access the new system accounts for many of the help desk queries in the early days.
The old joke goes that the NHS has more pilots than the RAF. There is no right or wrong answer to the pilot or big bang question. It is a common misconception that introducing a system slowly minimises the risks.
If a system is rolled out in a phased approach, there will be considerable effort in ensuring that interfaces to other systems, whether electronic or paper based, are maintained, and all staff have access to the most up-to-date and relevant information.
Running systems in parallel creates issues for reporting, can lead to duplication of data entry, creates additional data migration risks and may result in a fragmented patient record.
A big bang approach means everyone is on the same system at the same time, following the same business change processes. But there can be disruption to clinical activity during the go-live period and challenges in releasing staff for training in a short timescale.
In short, there is no risk-free implementation for IT in the NHS. Your job is to identify the risks associated with whichever route you choose and then put mitigation strategies in place.
This is probably the most difficult part of any project – and the part that often gets lost in the final stages of the project after the excitement of go-live.
Essentially, from the very beginning of the project you should have worked with users and managers to identify benefits as part of the business case. Once the system is live, you need to close the project and hand over the management of the system to business-as-usual.
Part of this handover should include the realisation of benefits – which means agreeing baseline measurements for the monitoring of benefits prior to the system implementation. For example, if your business case had predicted staff savings you should make sure that everyone has agreed the baseline figures and the methodology for monitoring savings in the future.
Do make sure that you do a proper project closure report, which is signed-off by your project board and which includes any lessons learned which may be useful for future projects.
There is no doubt that managing a large scale IT project is a daunting project. But by taking it step by step, the chances of success are greatly increased.
Carrie Armitage is an experienced programme director, business case author and health service electronic patient record specialist. She was programme director of the Cambridge eHospital project that brought the Epic EPR to the UK, and has worked for the NHS in national and local roles for more than 15 years.
