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.

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.)?

In the age of the sub-second Google screen flip, expectations are much higher than five to 10 years ago. Usability is a broad and important topic. In our current age of consumerism, (i.e. everyone can easily and safely do common things by themselves), the expectations of the quality of ‘Homework’ are considerably higher than much of the legacy-level of usability that's in common use today. The simple test here is the speed and relevance of each screen flip, and again, modern Web sites provide ample examples.

In the healthcare context, viewing or entering information about the drug Coumadin is a great test. Without asking, it should be easy for the user to know that patient's relevant labs (e.g. INR), relevant related orders and results (e.g. patient education, prior doses, therapeutic goals for levels, timelines, etc), and signs of toxicity. Relevance is not rocket science either, but the standard has evolved beyond commonly available, mature solution sets (products, services, and related methodologies).

Elaboration of fairness

That brings us to Fairness. I said that, in short, it needs to be fair and reasonable to ask users to embrace the system. Notice, I said “ask” and not “tell.” There is often honest and objective work that needs to be addressed between the ask and tell. For example, monitoring users post go-live for several months, to ensure that they are using the system reasonably efficiently, is important work. It's also work that is usually not done as carefully and systematically as the earlier pre-go-live work. This is the most common cause for adoption to level off well below desired and perhaps necessary levels.

Fairness is relative to the users being asked to work with the system. This is often called adoption, which is defined in terms of a subset of the population using the new system for some or all of its work. In contrast to Homework, which needs to be reasonably complete to hand-in, Fairness is a deliberate campaign for distinct sub-populations, rather than the organization as a whole. The first population is test users during a phase when the usability and result validity of the new system is being tested and validated, before any providers or patients could be injured by the inevitable deficiencies and bugs that will be found.

The Fairness work continues through each new ‘on-boarded’ population (group of users), from beta testers, earlier adopters, and what is often ‘care unit’ by ‘care unit roll-out.’ Doing this adequately is very resource-intensive. This work is often done after a go-live victory has been declared. Perhaps not surprisingly, it is common for non-savvy senior executives to interpret ‘go-live’ as an opportunity to throttle back funding.

So, the next level of failure is what the Advisory Board calls “perceiving go-live as an end-state.” (“Unlocking the Value of Clinical Information Technology — Best Practices for Designing, Deploying, and Managing Clinical Systems,” The Advisory Board, Washington, D.C.) It's only after a system is live that the technology-enabling changes can be vetted and stabilized in the real world. And yet, according to their extensive review, this failure to recognize and invest in the Fairness phase is one of the four most common, reasons for failure. The other three, by the way, are failure to establish metrics of success, failure to design for optimal end-user workflows, and settling for partial adoption and co-existence of multiple platforms. Sound familiar?

Note that each of these three management failures would be averted with adequate completion of what I'm calling Homework. Put more generously, the probability of success can be predicted by the quality of the Homework effort.

The functionality chosen for go-live is usually and appropriately very basic. The functionality that excited people during the demos or on site visits to reference sites often requires additional work post initial go-live — work that needs to be budgeted, staffed and managed. As we all know, it's frequently the case that the management team does not or cannot plan and protect a multiyear information system project. A more involved, multiyear, post-go-live plan is most commonly referred to as “Knowledge Management,” or it contains significant principles thereof.

Instead of maintaining the project staff or growing it, or even recognizing the new work, organizations almost always cut back staff and other resources here. The result is that adoption is limited and peters off, and functionality freezes at a very basic level. This is a large cause for project failure. Failure to execute an explicit Knowledge Management plan is a large cause for enabling technology to fall short of its potential.

It's very understandable why this happens, even to the most seasoned and astute CIOs and associated executives. Reasons for failure include: budgeting cycles, competing initiatives, revenue shortfalls, leadership changes (whether primary or secondary to the project's momentum), and internal civil wars (within or between nurses, pharmacists, physicians and the CXOs). These are all part of the predictable and inevitable drama of any organizational project. Conflict will happen. It's actually a positive and healthy sign of change occurring. However, when the conflict is avoided, the death of the project will inexorably follow. Fairness cannot be achieved without explicit work; work that follows the basic investments in communication, making respectful confrontation safe.

So, let's briefly recap. It's critical in any clinical transformation project to do the Homework. In short, it's creating organizational awareness, acceptance and commitment to address a clearly defined need. Part of that involves elaborating the potential solutions, and that usually involves interaction with vendors and consultants. The Homework step ends with some appropriate new system being brought live. That represents a piece of a larger vision, and the go-live accomplishment fulfills the critical need of building confidence and trust.

Elaboration of intolerance

Once the end users have explicitly recognized and agreed that the Homework has been adequately done and the usage proposition is reasonable (Fairness has been demonstrated), a campaign of Intolerance must be launched. Since the word ‘Intolerance’ often has a negative connotation, let's clarify with a context: It is sometimes highly appropriate and necessary to be intolerant; for example, when immoral and illegal behaviors create clear harm (such as hate crimes, murder, and child abuse), and where rage, violence and other such behaviors often compound recognizing and dealing with simpler, wrong behavior.

Once the Fairness phase has been achieved, intolerance needs to be socially motivated for those behaviors which are incompatible with establishing the safe and effective delivery of healthcare. For example, printing lab results, vital signs and medication lists to paper, in an environment that adequately supports electronic access, is unsafe. Many people have observed ‘paper kills.’ A quick Google search shows this notion is in common use, from Newt Gingrich (former House Speaker) to David Roberts (HIMSS) and well beyond, including book titles and multiple articles by different authors. Indeed, paper does kill.

Mandating other process-related behaviors is central to improving medication safety. It ends up touching everyone in the process: requiring patients and providers to wear bar codes; physicians to enter orders electronically, and many other processes. It is inarguable that better legibility and decision support require this step. It's perhaps less apparent that reduction in delays to get drugs to patients also demands these changes. Similar examples of the role for Intolerance of less effective processes can easily be elaborated for pharmacists, nurses, doctors, therapists, and allied care providers.

For people working in healthcare information technology for a decade or more, the concept of this kind of necessary Intolerance is neither new nor argued. I will acknowledge that, for some organizations, the idea of planning for a campaign of Intolerance is simplistic and absurd. I would argue that the real issue is almost always investment in and achievement of Fairness that needs to be the initial goal.

Special issues, often not discussed in public

There are special issues, such as black holes, that are worth attention. These are areas of the organization that cannot be integrated, either immediately or potentially ever. Sometimes, that includes the small physician offices that are completely on paper or office-billing systems that are stand-alone by design. It often includes parts of labor and delivery that have very low interaction with the medical and surgical services which often dominate the central EMR project.

There are many venues within an integrated care delivery system where information integration is difficult and produces little or no value. Like the black holes where matter goes, never to re-appear, such are the information black holes of a healthcare delivery system. Where they legitimately exist, they need to be acknowledged, at least at the private level.

It's important to acknowledge these black holes to avoid low-value, energy-depleting arguments and distracting design sessions. In short, it is okay to have and acknowledge some black holes. But, instead of focusing on the negative, let's flip that. Let's call attention to the opposite of black holes, ubiquitous light.

There needs to be ubiquitous light for patient's identity, and unambiguous access to the information to take safe care of that patient. That means there should be a reliable process to find a patient within a community of cooperating care providers, and that process should extend to a societally agreed-upon set of information. The most obvious example of this comes from 2006, with the Joint Commission mandate requiring medication reconciliation (electronic or otherwise), to be explicitly documented. So, all EMR projects need to be paperless for these information elements to ensure safe healthcare.

Failure is optional

In summary, the most common, avoidable causes of project failure are neglecting to create a fair deal to users. This usually stems from inadequate or faulty Homework in understanding what that deal should be.

Another common cause is proceeding from an emotionally frustrated stance, being prematurely intolerant of users who refuse to adopt the system ‘as is.’ This is usually arrived at through innocent behaviors that are effectively naïve to the challenges outlined in this article.

The combination of proceeding sequentially through Homework, Fairness, and Intolerance characterizes the most successful transformations (dozens) I have seen, and in some cases participated in directly. On the other hand, attempting to skip or concurrently do all three phases generally leads to frustration and project failure.

Analysis of competing approaches, such as ‘accelerated, scripted implementation strategies designed to rapidly design, build and test’ new systems are showing very high failure rates, according to presentation delivered at HIMSS 2008 by David Classen entitled, ‘Evaluation of Implemented EHRs.’ Poorly planned and executed projects often leave irreparable and long-lasting relationship damage. Homework, Fairness, and then Intolerance are crucial to successful clinical transformation initiatives.