The graveyard of healthcare IT is littered with technically functional systems that nobody uses. The EHR that clinicians route around by printing paper forms. The clinical decision support tool that generates alerts nobody reads. The patient portal that launched with fanfare and now has a 3% activation rate. In most of these cases, the technology worked as designed. The project failed because the people side of the change was handled inadequately — or not at all. This guide addresses why that happens and what to do about it.
Why Technology Projects Fail Despite Good Technology
Healthcare IT projects fail for a predictable set of reasons that have little to do with the software itself.
Resistance to workflow disruption is the most common cause. Clinical staff have developed workflows over years, often with paper or legacy systems, that they know reliably. A new system, even a better one, requires them to change those workflows. During the transition, they are slower, less confident, and more likely to make mistakes. This creates genuine risk and genuine frustration. Staff who were not consulted in system design often discover that the new system does not accommodate workflows the project team never knew existed.
Poor communication leaves staff feeling that change is being done to them rather than with them. When the first time a nurse hears about a new medication system is the week before go-live, the resulting anxiety and resentment creates resistance that takes months to overcome.
Inadequate training is endemic in healthcare IT projects. Training is typically treated as an activity to be completed — a box to tick — rather than as a learning experience that builds genuine competence. One-size-fits-all classroom training delivered two weeks before go-live, covering features rather than workflows, is standard practice. It is also reliably ineffective.
Insufficient go-live support abandons staff at the moment they are most vulnerable. Organisations that provide intensive at-the-elbow support during the first two weeks after go-live have significantly better adoption outcomes than those that consider training complete before the system goes live.
Change Management Frameworks Applied to Healthcare
Two frameworks are widely used in healthcare IT change management.
Kotter's 8-Step Model emphasises the importance of creating urgency and building a guiding coalition before change begins. In healthcare, this translates to ensuring that clinical leadership genuinely understands and advocates for why the change is necessary — not just that leadership has approved the project. Kotter's model also emphasises creating short-term wins: early, visible improvements that demonstrate the change is delivering value and build momentum for deeper adoption.
Prosci's ADKAR Model takes an individual-focused approach, recognising that organisational change happens one person at a time. ADKAR stands for Awareness, Desire, Knowledge, Ability, and Reinforcement. The model asks: does each affected person know the change is coming and why? Do they want to support it? Do they have the knowledge to change? Do they have the ability to demonstrate the new skills? Is the change reinforced so it does not regress?
The ADKAR model is particularly useful in healthcare because it helps identify where specific individuals or groups are struggling. A department that has Awareness and Desire but lacks Ability needs hands-on training. A department that has all four but still shows regression needs Reinforcement — supervisor accountability, peer recognition, or workflow adjustments.
Stakeholder Analysis
Before designing a change management approach, map your stakeholders. For a major clinical system implementation, this includes:
- Clinicians who will use the system at point of care (doctors, nurses, allied health)
- Administrative staff whose workflows are affected
- Department managers who will oversee the transition
- Senior clinical leadership whose endorsement is essential
- IT staff who will support the system
- Patients, if the change affects how they interact with the organisation
For each group, assess their current level of awareness and support, their influence on others' adoption behaviour, and the specific changes the new system requires of their workflows. Groups that are high-influence and currently resistant require targeted attention — their behaviour will shape the response of the wider clinical community.
Clinical Champions
Clinical champions are the most powerful accelerant of healthcare IT adoption. A clinical champion is a respected clinician — typically a doctor or senior nurse — who understands the system, believes in its value, and actively advocates for adoption among peers. They bridge the gap between IT teams and clinical staff in a way that no project manager or vendor trainer can.
Identifying, recruiting, and supporting clinical champions is one of the most important investments a healthcare IT project can make. Champions need sufficient time to develop their own competence before go-live, a clear role during and after go-live, recognition for their contribution, and a channel to feed clinical feedback back to the project team. They are not unpaid extras in someone else's project — they are essential members of the implementation team.
Communication Planning
A communication plan for a major healthcare IT implementation should start six to twelve months before go-live and continue for at least three months after. The plan should specify:
- What messages need to be delivered, and when
- Which channels are appropriate for each audience (clinical briefings, email, intranet, team huddles, posters in clinical areas)
- Who delivers each message (IT project manager, Chief Medical Officer, department head, clinical champion)
- How feedback from staff is collected and responded to
The tone of communication matters. Messages that focus on the benefits to patients and to clinical practice, rather than on the technical features of the system, resonate better with clinical audiences. Messages that acknowledge the disruption of transition, and that describe what support is available, reduce anxiety.
Training Design for Clinical Staff
Effective training for clinical staff is workflow-based, not feature-based. Instead of teaching users where every button is, training should walk through the workflows staff will actually perform and show how those workflows are completed in the new system.
Role-based training is more effective than generic training. What a ward nurse needs to know differs from what a pharmacy technician or an emergency doctor needs to know. Training programmes that recognise this design appropriate curricula for each role rather than delivering the same session to everyone.
Timing matters. Training delivered too early is forgotten. Training delivered too close to go-live leaves no time to practise. A two-to-four-week window before go-live, with at-the-elbow practice available in a test environment, is generally effective.
Superusers — staff members from each department who receive extended training and serve as first-line support for their colleagues — reduce the burden on the central IT helpdesk and provide peer-to-peer support that is trusted and accessible.
Go-Live Support
The go-live period — typically the first two to four weeks after a system launches — is when adoption either takes hold or collapses. Intensive at-the-elbow support from project team members, vendor consultants, superusers, and clinical champions during this period has a disproportionate impact on long-term adoption.
Go-live support should be physically present in clinical areas during peak activity periods. Support staff should be empowered to escalate genuine system issues rapidly and to distinguish between problems that need system fixes and problems that need additional training.
Sustaining Adoption Post-Launch
Change management does not end at go-live. Adoption metrics — system usage rates, data quality indicators, helpdesk call volumes — should be monitored for at least six months after launch. Departments or individuals showing low adoption should receive targeted follow-up, not general communications.
Regular reviews of clinical feedback identify workflow issues that were not apparent before go-live and should drive system configuration changes. Systems that improve in response to clinical feedback sustain adoption; systems that ignore feedback lose it.
FZ Consulting LLP provides change management advisory services for healthcare IT implementations. Contact us to discuss how we can support your next clinical system transition.