Poor systems and implementation issues are often blamed for the failure of NHS IT projects, but the real reasons are often more complicated, says Colin Lewry
A lot has been written about what makes a successful project and why IT projects fail. The biggest problem, though, is not the systems or poor technical implementations, but what happens around them.
So assuming that the developers have built a good system and the project managers are up to the job of bringing in the IT, let’s look at 10 ways to realise the benefits from the effective implementation of a good IT system.
1. Work out in advance what benefits you expect from the system
For best results, the benefits can be divided into two groups: financial benefits and non-financial benefits. Only by knowing how we expect to gain can we check that we’ve realised most of the benefits. Those with financial benefits attached normally get into the finance director’s sights, giving an increased chance that there will be a governance framework to help drive it through. Making links to business and user needs will help gain buy-in.
2. Sort out your bad processes
If we don’t change existing processes we run the risk of simply automating bad ones. New systems demand new processes and these need to be mapped and designed in consultation with users before implementation.
Electronic nurse rostering is a good example of where trusts perceive that ward based rostering could be improved with an electronic system to give them full visibility and control, but fail to help ward sisters change the way they work. I’ve seen nurses continue to run paper rotas and then transfer them to the computer, and managers struggling to get the computer to roster nurses that still have old, restrictive work patterns.
3. Redesign the workforce
If the aim of an IT system is to automate processes and reduce the need for people to do tasks, then people’s jobs are going to change. The trouble is, these changes will almost certainly only impact on a part of someone’s job − so the person is still needed, and financial benefits are often not realised. This needs to be understood and planned for from the outset.
‘One way to realise the benefits is to put in a suite of systems that will have a more fundamental impact – and then redesign the workforce requirements more completely’
This was typical in picture archiving and communications system implementations, where substantial potential staff cost reductions didn’t materialise because film filing costs made up a little bit of lots of people’s jobs. One way to realise the benefits is to put in a suite of systems that will have a more fundamental impact − and then redesign the workforce requirements more completely. And make sure they have the tools to deliver the automated processes.
PACS implementations that made doctors walk back and forward to a terminal when they were used to looking at film at the bedside were depressingly familiar. Most people love a mobile device and this will sweeten the change.
4. Pilot for implementation
The NHS is beset with pilot projects that never go anywhere. I know of one voice recognition pilot that has been going for 18 months − the team like it, they keep using it, but it has never been rolled out. When you pilot a system, see it as part of the implementation of a system, not as a project in itself.
By all means run pilot projects − they are useful, and the learning means that you can avoid costly mistakes, or cancel the project before you spend too much. But the best pilots result when we understand what we want to learn, when and how we are going to evaluate it, and what the next steps are. Otherwise they can run on or fizzle out.
5. Find a co-pilot but stay in the driving seat
Systems developers are as keen as you to road test their software and are often happy to work on projects together. Make use of this and find a partner with whom your teams can collaborate.
For example, there are some interesting new systems around at the moment for helping control agency spend, many of which need good pilot sites. If you get a partner with something invested, then you have an ally also wanting the project to succeed − and wanting evidence of benefits for the write-up, or someone to complete a reference study as part of the project. But you need to stay in control as such collaborations take effort to avoid two people struggling with the controls.
6. Get the right external team
When implementing a system, you are inviting a team from a software developer into your organisation and relying on their expertise to get the implementation right. The trouble is that demand for developers’ services is variable, and sometimes their teams might get a bit stretched.
‘Too many projects are signed off with high expected financial benefits − and then deliver late or not at all while people shake their heads’
So if you are buying in support to implement a soon to be popular system, which can touch on a large percentage of the processes of the organisation, make sure you are getting in the right people. Do not go just on the company’s reputation but find the right individuals (if necessary wait until the right people are available). When contracting, make the level of support you expect very clear, and hold suppliers to it.
7. Get it governed
Significant effort is spent on putting together business cases and getting the project agreed − but then what? One stands a better chance of realising benefits if someone independent is checking that the project is on track.
Too many projects are signed off with high expected financial benefits − and then deliver late or not at all, while others shake their heads about another “failed IT implementation” without knowing what to do about it. If you are running the project, governance should be welcomed if it gives you the chance of an executive audience to unlock issues.
8. Change management
It’s another one we all know, but one that is so important. Let’s take the example of an electronic patient record. If a trust is going to eliminate paper notes it will need the support of practically everyone. Engaging affected staff, especially clinicians and the administrators at the front line with a planned change management approach, is the only way to minimise workarounds and other resistance, and maximise benefits from its use. Difficult projects that change people’s lives, like EPR implementations, not only require but also deserve investment in change management, and the results will pay dividends.
9. Buy intelligently
Overstretched procurement teams and complicated rules mean that the buying part can seem unbearably long. It might be worth working with and challenging the procurement team to optimise the process and try to minimise the burden on it.
For example, where possible, don’t rely on tick-box exercises to procure IT systems. They are generally copied from someone else’s, suppliers take days to respond to and they rarely help you to find the right partner. Instead, spend time with suppliers to explore your requirements (their systems will do things you have not thought of) and how they can meet them. Then go as light as you are allowed and makes sense in the formal procurement.
10. Come back around
It is a great practice to submit a benefits evaluation at the end, before a project was closed. This focuses the mind for the project sponsor, allows the business to learn and give the investment committee some great feedback. The committee is more willing to invest in those projects sponsored by someone with a better track record. This is not done much at the NHS trusts, but its cultural impact would be significant.
Colin Lewry is a director at Finnamore