Many clinical transformation initiatives get derailed. I offer a brief guide to avoiding some extremely common pitfalls to this complex undertaking. Our intrinsic human nature, combined with basic economic forces, ensures constant pressures to do the wrong things in the short term. I explicitly outline those common pitfalls in this article, in part by recognizing the laws of these three distinct phases.
Organizational projects are always challenging. Doing healthcare informatics projects is both socially and technically challenging. Implementation has been compared to a series of battles in a great, unending war. Indeed, it's been described best as a war of attrition.
Against this challenge, executives try to apply traditional change management approaches, such as explicit campaigns to create awareness, acceptance and commitment to address those challenges. (See “Managing at the Speed of Change,” by Daryl Conner for one useful framework.) The outcome of these efforts often fails to meet our expectations. And, too often, the planning focus goes up to system go-live, then effectively stops. A better planning focus might include striving to achieve three deliberate, disciplined and successful phases of 1) Homework, 2) Fairness, and then 3) Intolerance.
Each phase has distinct work and influence strategies relative to the other phases. Failure to do the appropriate in each phase leads to failure to truly achieve the phase's milestone. In the interest of brevity, let's get on with it.
Elaboration of homework
The base of the approach is to deliver simple tools that work to address the defined problem or predicament. That's the Homework. Homework needs to be done largely before the majority of the effected workers are impacted by the project. Evidence that this has been done is the existence of a written project charter, which explicitly elaborates the goals and accurately summarizes the critical success factors. Perhaps not surprisingly, this is often not done. Common excuses include absence of time (e.g. “the ship has left the dock and our high-level plans call for being done in three months”); reluctance to bring representatives of the key stakeholders together to do the work; and, perhaps most commonly, underestimating the minimal, necessary work to achieve success.
The ‘Homework’ phase is not rocket science, but it does require creating clarity on three parts — the vision, the current state, and the options on closing the gap between the two. In any vision, the basic operation of a desired system needs to be as usable as, or more usable than, the system it replaces. That usability needs to be considered from several perspectives, two of which are: 1) the system is safer (highly reliable to have fewer opportunities for delays and errors), and 2) the intended target users, often doctors and nurses, find the system compatible with getting their work done.
Aside from inherent product functionality and end-user training, there's often critical build work and iteration that is not included in many go-live plans, with predictable consequences. The build work here refers to creating ‘easy to understand and use menus,’ information display screens, and possibly entry screens (e.g. for entering admission assessments or basic medication order entry.) Organizations commonly get into trouble here because they use, as input for their planning processes, two very misleading sets of information.
First, their knowledge of the ‘solutions’ is based in part from seeing some combination of a vendor's demonstration environment, reference clients, and prototypes. Each was developed for a different purpose than to support delivery of care in their institution, coming from where the organization is in its current state. The only solution to this trap is including strong and adequately diverse experience (i.e. people) to the process of getting effectively through the Homework.
The result of successfully completing one's Homework includes a meaningful definition of charter and go-live, with the requisite work planned, and an achievable, organizationally agreed-upon approach to staffing that plan. In my experience, the majority of failed implementations (not achieving timeline and budget) have woefully understaffed their plans. Sometimes the understaffing is out of ignorance; more often, however, it's a political compromise, discordant with any probability of success. By way of metaphor, if you don't have enough gas for the trip, clever driving won't make up for an empty tank.
What happens when Homework is completed and the assignment is due? Organizations achieve go-live, on time and on budget, as defined by a written project charter/scope document with adequate staffing. Failure to complete Homework as described here is the first, most common avoidable cause of project failure.
One simple test of success is whether, when a nurse or physician logs on, they can reliably see all critical results and tasks, without keystrokes, clicks, training, or IT intervention. If this isn't the case, the system is objectively not organizationally safe. It's also far from ‘Fair’ to ask the community of users to embrace such a system. There are other tests as well, for example: is the system reasonably fast (e.g. fast to log on, fast to open a patient's chart, etc.)?