January 19, 2009

Rethink EHR Project Timelines
By Sue Newell, PhD, and Gary C. David, PhD
For The Record
Vol. 21 No. 2 P. 16

By making the end the beginning, healthcare organizations may have a better chance to succeed.

There is a growing nationwide mandate for healthcare organizations to adopt enterprise systems such as electronic health records (EHRs) and electronic medical records (EMRs). These systems are developed based on so-called best practices—those practices deemed most effective for fulfilling particular processes such as patient record organization and workflow in the case of a healthcare-based enterprise system.

The fundamental aspect of an EHR system is that a single and unified database of patient information is created from which individuals can draw and input further data in a common format that allows them to be utilized by others according to standard workflow templates. This creates the potential for great access to up-to-date information from anywhere in the enterprise, as well as better exchange (or interoperability) of information within and between organizations that are using the system. So important is the implementation of an EHR framework that presidential candidates John McCain and Barack Obama both agreed to include a nationwide system as part of their healthcare policy. This follows on the heels of President George W. Bush’s executive order to implement a nationwide EHR system by 2014, a declaration that was further supported by the Office of the National Coordinator for Health Information Technology in its strategic plan. All these views are built on claims that the presence of such systems will result in better, cheaper, and more efficient healthcare.

But delivering on this promise is proving to be more difficult. According to a 2001 Standish Group study, it is estimated that between one half and two thirds of all IT projects fail, and enterprise systems (which is a generic term that can include EHR systems) are at the higher end of this estimate because of their highly integrated nature. However, in most of these cases, it is not a total failure, meaning only a small number of IT projects are abandoned prior to implementation. Rather, many IT projects “fail” in the sense that they are delivered late, over budget or, more importantly, without the anticipated benefits.

In a 2006 report, Erica Wagner, PhD, and Sue Newell, PhD, found the latter point to be especially salient considering that most organizations struggle to deploy all the functionality that is available in these powerful enterprise systems. In other words, most organizations do not reap the full benefit of these software tools and are unable to recoup the gains needed to justify their sizeable investments. This is because an enterprise system is not just a technical system; rather, it is a sociotechnical system that depends on people changing their work practices in order to do things differently. Thus, enterprise system implementation projects are as much about organizational change as they are about making technical adjustments.

In trying to do things differently, it is often easy to lose track of what is being done well during implementation. Organizations favor opting for packaged software because it is much cheaper to implement complex, integrated EHR systems compared with designing a bespoke system for each unique healthcare system. Organizations implementing such systems are thus advised to configure but not customize (change the source code) the software in order to reduce costs and ensure they are able to accommodate the inevitable software upgrades that vendors will produce in their attempts to enhance functionality and usability.

Furthermore, some vendors prefer not to support customized enterprise systems given that they diverge from the systems they build and sell. This can compel an organization to wrestle with massive organizational change when, in fact, all they needed was upgraded functionality. In the end, this shift in focus can cause massive disruptions to the organizational work. When dealing with industries that manufacture goods, this may result in a disruption to supply and distribution. A disruption in healthcare service can produce more serious consequences.

Ultimately for many organizations, including those in healthcare, project success is defined as the technological implementation of the system and subsequent meeting of the go-live date. However, there are a number of reasons why it is virtually impossible to design a system up front that will be implemented on time and on budget and fully utilized once it is implemented.

First, it is extremely difficult to maintain all the critical success factors that we know are associated with IT success:

• Project champion and project team: We know having a project champion is important, but an enterprise system project often takes several years, during which time an organization will experience some employee turnover. Members of the initial project team may not stay for the project’s duration, and when new members join, they may not buy-in to the same extent. Projects often begin with a lot of fanfare (after all, they typically involve a significant investment that needs to be justified), and time is spent creating a shared vision. However, individuals getting involved after start-up may not share this vision.

• Technical activities: It is possible to plan resources for the various technical jobs that need to be done, such as configuring tables, cleaning data, and testing. However, it is nearly inevitable that these plans will not be accurate. For example, scrubbing data so that each patient has only one record in the integrated database is likely to be more time consuming than anticipated because it is not possible to determine the exact quality of the existing records at the start of the project.

• Organizational change effort: While most implementation plans include communication and educational resources for the organizational change program, our research demonstrates that those resources are often reallocated to the inevitable technical problems that will occur.

Second, to improve the chances of buy-in and ensure the system meets user needs, many organizations encourage associates to participate during the design phase. However, this strategy can fail for the following reasons:

• Legacy thinking: When dealing with concepts and hard-to-understand technology, it is difficult for users to think outside the box and anticipate how they might do things differently.

• Vanilla implementation: If users do provide design suggestions but they don’t fit the software package’s configuration options, they are likely to be ignored, resulting in delays and resistance.

• Motivation: At the design stage, it may be difficult to motivate users to get involved because they are likely to be busy with their current responsibilities and because the new system is not salient in their minds at this stage (think about how much attention you pay to car adverts when you are considering buying a new car vs. the rest of the time).

Third, it is extremely difficult for any of those involved to fully understand how things may be done differently. This includes not only the ultimate system users but also those involved in the project team. One way of looking at this is to realize that an enterprise system will have “affordances” that cannot be anticipated in advance; it will allow certain things to be done differently once other things are first done differently. For example, once an EHR system is implemented, it may be possible to automatically schedule checkups for people with particular conditions, thus freeing up administrative support costs, which can then be spent on putting on special clinics for seniors, which in turn improves preventive care, and so on.

All these factors mean that few organizations are going to be able to design the perfect system up front. Indeed, we would argue that there is never a perfect system because this would assume a static world and full agreement across all stakeholders. Our research indicates that most organizations invest heavily in the enterprise system project until it goes live. Some organizations do invest in a help desk for a limited duration to get users through the initial teething problems. However, few organizations recognize the importance of investing in postimplementation, failing to see that this phase can provide support for experiential learning and help users understand how they can do their jobs better through using the functionality that is now available.

We advocate a reorientation of perceptions about what is involved in an enterprise system implementation, one that deviates from an exclusive focus on design and implementation and instead concentrates on iterative cycles of design/implementation/analysis/assessment/recommendation/and (re)design. Based on users’ live experiences, there are often opportunities in the postimplementation period to modify (or even customize) the configuration to realize more benefits. Thus, rather than seeing user resistance at go-live and limited system use subsequently as an indication of failure, those involved should recognize this as inevitable and part of the process.

Instead, based on our research, we advocate the following:

1. Make the end the beginning. View implementation as an ongoing and iterative process rather than a single cycle (see Figure 1). This involves continuous evaluation and discovering users’ needs as they work with the system; there will always be opportunities to improve processes that can help efficiency and/or quality. The initial implementation is therefore the start and not the end of the process. Here, vendor upgrades can be seen as an opportunity, not a nuisance. Thus, organizations can select when to upgrade based on their own needs to add, or merely encourage the use of, some new functionality that could be helpful. Likewise, organizations need to advocate for their needs when developing a system that not only supports their process but also their workplace practice.

2. Enterprise in legacy clothing. Try to initially configure and customize the software so that it allows users to work as they did in their legacy environment—with the added potential to do a lot more. This can significantly help reduce user resistance and may be a price worth paying even if it means some customizations are necessary.

3. Achieve buy-in through listening. Recognizing that it is difficult and problematic to engage users during the initial design and implementation phases of an enterprise system project, encourage user participation during the postimplementation and subsequent iterations of the ongoing cycle of exploitation. Encouraging the emergence of communities of practice (a place where users can share stories about their EHR use) can be a powerful learning mechanism. This goes for users at all levels.

Research conducted by one of the authors demonstrates that medical transcriptionists are seldom, if ever, consulted when choosing a new system even though they are one of the primary users in the creation of healthcare documentation. This approach misses a crucial opportunity to engage with those who are part of the medical record chain and leverage their expertise and experience.

4. Provide an enterprise “sandbox.” Give users an opportunity to experiment and play with the EHR system, so they can begin to understand the technology and its potential. Training on an EHR system is typically restricted to a set of instructions that tell a user exactly what to do in order to complete a particular transaction. It does not provide the user with an understanding of what is happening on the system when they complete the transaction—where the data have come from and where they are going. These integrated systems are too complex to fully understand, especially in the limited amount of time that is often available for training. Moreover, users may have to stick to following these detailed instructions because they realize that if they “experiment” on the live system, they may well corrupt the database and/or the workflow. However, if users are given access to a nonlive version of the software, it gives them a worry-free chance to understand how the system can support their work.

5. Vive le resistance! See resistance as a source of ideas and not merely as a source of irritation. Recognizing that users have different (rather than inferior) needs, perceptions, and values is the first step toward creating a system that can meet various stakeholder interests. In many cases, those involved in the project may have in mind a particular version of what is best practice, often based on the software-embedded best practices.

However, best practice is context specific. This suggests that there are going to be areas where compromise is necessary, since it is not going to be possible to create a unified system that is best for everyone. Giving a little in one area, however, can encourage others to give a little elsewhere, so that a system is designed that is “good enough” for all, albeit not perfect for anyone.

6. Tending to “the field.” How a system is said to perform can be quite different from how it actually works. Therefore, it is important to pay attention to how the system integrates and is used as an everyday work tool. By getting to “the field,” or the site where work is performed, managers can develop a better idea for and appreciation of how the system is impacting the organization from the ground up. Plus, this can also create better buy-in from users, who feel they are being heard and appreciated. It is important here that such observations are not seen as an evaluation of the users but rather as an examination of the system and its integration into the workplace.

EHRs and EMRs will eventually be commonplace in healthcare. However, their presence does not automatically translate into the delivery of their promise. Rather, it will take an active engagement across organizational levels to unleash their potential and achieve the hoped-for change. Ultimately, any technology is just a tool; it is in the use of the tool that its potential is realized. And by examining its use, organizations will be in a better position to fashion a tool that is best suited to their tasks. Recognizing that this will be an ongoing process rather than a one-off creation will be a vital step on the road to success.

— Sue Newell, PhD, is the Cammarata Professor of Management at Bentley University in Waltham, Mass.

— Gary C. David, PhD, is an associate professor of sociology at Bentley University.

Behind the Research
Understanding the source of IT implementation failures can be akin to an episode of CSI: There are multiple clues but not necessarily a singular cause. Unraveling the factors that contribute to these failures relies on using a variety of approaches, each of which provides some insight.

Previous research conducted by Sue Newell, PhD, and Gary C. David, PhD, has used various approaches, but it has primarily relied on conducting ethnographic research in workplaces where implementations have occurred. Typically, this includes talking with the people who are part of the organization’s implementation team, the consultants vending the product, and the users who ultimately integrate the technology. Observing these principals becomes an important next step in discovering the impact of enterprise system implementations. Because it can be difficult for people to fully articulate how it is they do their work, these observations can become the missing information in piecing together how a new system becomes part of the organization’s everyday activities. Coupled with more quantitative approaches such as surveys, a more multidimensional understanding of the implementation successes and challenges comes into view.

Newell’s corporate consulting experience includes engagements in several industries, including healthcare, pharmaceuticals, and manufacturing. She has written on knowledge management and the evolving workplace in two books, Managing Knowledge Work and Creating the Healthy Organization: Well-Being, Diversity & Ethics at Work.

David’s research focuses on the role that interpersonal interactions play in the formation of intergroup relations and the role that communication technologies play in that process. He also researches the impact of new technologies on workplace activities. Present projects include examining the nature of collaborative activity in multicultural work sites, the impact of speech recognition technology and electronic medical records on healthcare, the implementation of enterprise systems on workplaces, and how coworkers build a collaborative relationship through engaging in workplace practices.