At HTN: Electronic Patient records, we were joined by Rod Gamble, Director of Implementation Services for Ideal Health.
Rod joined us to discuss the total cost of EPR ownership, with a focus on getting it right from the beginning to reduce implementation costs.
Getting it right from the start
To begin, Rod shared a diagram illustrating the cycle of an EPR programme: aligning goals and benefits, procurement, implementation, transition to business-as-usual (BAU), and then BAU itself.
“A lot of people recognise the elements here, but they don’t realise the connection between getting the right benefits, the implementation, and the BAU,” he said. “There’s a good reason for that – the time between aligning goals and going into BAU can be three, four, five years. It’s often, literally, the furthest thing from our mind in this entire cycle when we are in the aligning goals phase.”
Implementation
“Implementation and procurement are the phases most of us focus on,” Rod said. “We focus on getting the right vendor to meet the most needs, contracting them, getting the best price. Then we focus on the implementation itself and march to go-live.”
The cost of implementation often takes precedence, he added. “A typical approach to this involves starting the project with as few resources as we can, and then we sprinkle them in, adding more as necessary. This has serious deleterious effects.”
Rod moved on to examine the implementation in more detail, looking firstly at the role of communication in the team.
“In software engineering, communications form a lot of what we do,” Rod said. “We’re not picking vegetables; when you’re picking vegetables, you don’t have to have a discussion about how to do it. You simply double your output by doubling your team. When we’re in one of these EPR programmes, everyone needs to talk to everyone.”
He demonstrated how communication channels work in a team through a graph, available to view below at 7:05. The graph charts exponential growth of communication channels in relation to the number of team members or stakeholders involved in the programme. This doesn’t “just involve the people you hire temporarily from a partner,” Rod pointed out, “but rather all of the people who are behind that partner; the people you need to work with to get more people, or to improve performance of the existing team. It includes the trust and all of the stakeholders. The number of people involved gets very large, very fast. Using this formula, a team of four has six communication channels, but a more typical team of 50 is going to have 1,225 communication channels.
Picking up on his earlier point around the typical approach to adding more resources as necessary, Rod said: “The problem here is Tucker’s model – forming, storming, norming, performing. Each time we add someone to the project and our effort, we re-start this cycle over again. We push the team into a state of turmoil over and over again. People are not software and since everyone needs to talk to everyone, we are increasing our communication channels further every time we do that.
Next, Rod shared some software engineering concepts. “What we’re doing on an EPR project is not full-blown software development, but it is configuration management on a large scale,” he said. “We make tens of thousands – maybe hundreds of thousands – of decisions on a project in order to configure it correctly so that we can get it to go live. That requires a lot of communication. The typical measure in software engineering is that if your project is running three months late and you double the number of resources on it, it will run six months late.” This concept, Rod added, is covered in the book ‘The Mythical Man-Month: Essays on Software Engineering’.
Rod displayed another graph at 10:58 illustrating the relationship between cost of change and stakeholder influence. “At the beginning of the project, in design mode, stakeholders have the biggest voice because they can most easily make changes to the system,” he explained. “As we move through time, the cost of that change increases precipitously, and therefore the stakeholder influence for further changes drops off. If you need to make a change just before go-live, that change requires redesigning, rebuilding and retesting. We end up with resistance to change the further the project goes along.”
Therefore, Rod said, it is important to get as “solid and as hardened a design as we can at the beginning, when stakeholder influence is highest and the cost of change is lowest.”
Rod also highlighted that dealing with fewer partners decreases the communications channels, decreases the amount of work going into anything other than the necessary work, and increases overall effectiveness of implementation.
Transition to BAU
“Most projects spend the majority of time in BAU,” Rod pointed out. “If we have a 1o-year programme, we’re going to be working on making it live for the first 24 months or so. After that, we’re going into BAU and we’ll spend the rest of the programme’s life there.”
He noted that often organisations focus the majority of their efforts on those early phases, and after that plans get thinner with BAU expected to take care of itself.
“When we include a BAU strategy in the original full business case and contracting, we assure continuity for the entire programme, thus allowing us to minimise our total cost of ownership for the entire cycle,” Rod said.
On partnering, Rod explained that there are three types of resources required for EPR programmes:
- Full-time: these staff members will be involved in the programme throughout its cycle and should be identified in the BAU strategy, hired from just before the start of the project
- Temporary (such as Ideal): these resources are needed full-time, but not through the full cycle; they come on secondment from the trust itself and from managed service partner, combining operational knowledge and a mature methodology born of lessons learned
- Part-time: specialised experts needed at crucial junctures in the programme, typically staff members from the trust with specialised clinical or operational knowledge
In terms of organising these resources, Rod said: “Each workstream should have a lead, a junior project manager. In a perfect world, this lead comes from the trust and has some experience as a project manager, but they also have experience in a specific operational area. Other people will report to that team lead – the part-time subject matter experts, bringing the specialised knowledge that we can’t expect the team lead to carry round in their head all the time.
“Next we need someone who has done it before, seen the problems and experienced success anyway. They can prevent the trust from recreating the wheel and recreating problems that they have seen in the past. This would be an Ideal expert analyst.”
Lastly, Rod said, we need a vendor analyst who can bring the vendor’s best practices. “This is part of what is being paid for in the contract with the vendor and it’s basically the best way to solve real-life clinical problems with that particular vendor’s software,” he said.
Ultimately he said, this is about combing knowledge about the vendor’s lessons learned, the real-life lessons learned, and operational knowledge throughout the trust.
The discussion then moved onto the mindset required to make the transition to BAU work: beginning with the end in mind. Rod shared some examples of how this helps.
“During the initial phases of the programme, we can skimp on design, dribble in more resources as we go and make a weak design that needs increased work later, creating a myriad of post go-live issues. Or we can spend the right amount of time, energy and money during that early phase so that at go-live, it’s really just optimisation work,” he said.
Similarly, the BAU team can be staffed with new recruits or it can be staffed with existing staff who are already used to working together, collaborating on a programme that they know, where they recognise opportunities for advancement and improvements.
Failing to plan for the BAU team leads to the vendor being required to stay on-site providing support for months after go-live; if the proper planning has gone into the process, however, this allows for rapid transition to the BAU team. “My record is 10 days,” said Rod. “After 10 days, the operational staff were ready for us to leave because they were fine with the system and didn’t need us on-hand anymore.”
The BAU team can either face uncertainty about what is happening next – which then leads to an increase in the amount of time spend replacing members on the team – or they will feel confident and prepared to work on optimisation and next steps.
If programmes move forward without the end phase in mind and do end up requiring this additional work, Rod added, it comes on top of existing duties. “You’re painting a moving train. Redesign, rebuild, retest, retrain – all of those things need to be done with the burden of patient care on you as well.”
The keys to minimising total cost of ownership
Rod concluded his session by re-emphasising the key factors that should be taken into consideration:
- Make sure you’ve got a hardened design – put time, energy and resources into that very early phase of implementation.
- Partner with a group like Ideal that will provide you with mature resources, with a track record of doing this work previously.
- Have a single partner within your structure, so that everything is optimised and you’re not dealing with competition and conflict.
- Create and implement a BAU strategy so that you know exactly how you will transition later in the programme.
Many thanks to Rod for taking the time to join us.
