Building acceptance for ELN implementation: step-wise strategies can overcome the resistance barrier.
In the article "Change Management and ELN," which appeared in the May/ June issue of Scientific Computing, I discussed how managing change was one of the biggest challenges for any informatics project. "General resistance to change" is cited by both users and non-users alike as the primary reason why there could be (or is) resistance to the deployment of ELN. I also described several frameworks for change management and how a merging of several methodologies can be directly applied to ELN. The formula Q x D x V x CS > R illustrates how levels of resistance (R) are overcome by a combination of factors: the quality of the solution (Q), the level of dissatisfaction with the current state (D), the project's vision (V), and the beneficial and tangible concrete steps taken toward vision realization (CS). Furthermore, personality types impact the levels of resistance; the more technology-conservative the users are, the higher the bar.
This article will discuss ELN implementation and how step-wise and time-boxed methodologies can be employed to demonstrate short-term successes necessary to build acceptance from pragmatic and conservative users. In terms of the formula described earlier, these stages fulfill the "CS," building a growing foundation of successful deployments. Companies with high rates of user acceptance take a methodical approach to implementation and change management. These best-practice organizations, whether implementing at the departmental or corporate level, have learned that an iterative approach facilitates the greatest adoption.
[FIGURE 1 OMITTED]
There are several methodologies in information technology to design, build and deploy systems. One such model is the Waterfall Methodology. The model illustrated in Figure 1 is a cascade from requirements to design, design to implementation, implementation to verification, and verification to maintenance. Each stage is sequential and is rigid in its approach. The basic concept is that, through a detailed understanding of the requirements and design upfront, the later stages will be simpler.
A major challenge with the waterfall model is the assumption that you truly know all the requirements and all the points of dissatisfaction with the current state. There is little chance to revisit the requirements as the implementation progresses.
In the world of research, this is a very dangerous assumption. First, users, for the most part, have never used an ELN before. Their world revolves around documentation in a paper notebook, binder, or through a loose collection of Excel spreadsheets. "They know what they know, and know what they do not know" in that their world is framed by their current practices and realities. They would define the specific design of the ELN based on the pluses and minuses of their current world. Second, in a large deployment with changing scientific demands, you run the risk that the requirements are so onerous that they are obsolete by the time you start configuring the system. The waterfall method also tends to take longer to implement--users do not see the "concrete steps" toward the vision and lose interest and become more skeptical. In essence this raises, rather than lowers, their level of resistance to the project. As Albert Einstein once famously said, "Problems cannot be solved by the same level of thinking that created them."
Like experience with LIMS in the early 80s, users' perceptions about technology change once they use it in a real-life setting. What was once important may now not be. What wasn't important is now critical. New ways of thinking arise when they have tangible experiences in which to observe alternative solutions to a problem.
KOLB LEARNING CYCLE
In 1984, David Kolb documented his "Experiential Learning Theory." Kolb wrote that he believed there are four intertwined styles that make a learning cycle. Shown in Figure 2, Kolb postulated that tangible experiences shape the way people sense and feel about a particular topic. Put another way, the experiences with paper notebooks flame beliefs about what an ELN is or is not. Through a process of experiencing the technology, the user begins to reflect and observe about what might be possible, which is this case allows them to conceptualize the technology in a different light. For example, ELN as a broad data management platform rather than just an intellectual property protection system or a system "to go paperless."
[FIGURE 2 OMITTED]
These early designs, put into real life practice by the ELN implementer in the form of prototypes, allow for experimentation by the user to gain new concrete experiences and sense that the vision can be realized. From these new experiences, they learn and reflect on possible changes to the prototype, which is refined by the implementer. The cycle continues until the majority of needs are met. This experiential learning model enables the ELN project team to put designs into practice with small groups, minimizing both risk and costs and demonstrating benefits to both the early adopter and skeptics alike.
Due to the learning cycle, best practice companies have generally used one of the Agile methodologies in the deployment of research ELNs. Agile is a collection of models having similar considerations, a few of which are:
* Voice of the Customer principles to "find the need behind the need" (i.e., pain points and dissatisfaction with the current state)
* an iterative process of working with groups of users through a series of prototypes and pilots
* a "people" approach with close interaction, cooperation, and communication with users. An emphasis of people over technology
* rapid development and execution
* adapting the vision as needed to changing realities
A fundamental concept is the iterative approach. This perspective is one of incremental development versus the waterfall method of a one-time event. Time boxes are created to define, plan, develop and deploy in collaboration with users within a fixed period of time (weeks, not years), avoiding the extended period between user interaction and deployment. The iterative perspective takes advantage of Kolb's Learning Cycle; as users experience the technology, they can refine the requirements and how the technology can be used. Functionality is delivered in blocks or "slices" for review and consensus.
This philosophy incorporates kaizen principles. Kaizen (Japanese for "improvement") is a fundamental mode of operation applying the concepts of continuous improvement. Kaizen teaches a belief in experimentation using the basic scientific method. Users, through their experimentation with prototypes, look for ways they may improve or simplify their work life using ELN. Adjustments are made to processes, the system and performance is measured to evaluate further improvements through key performance indicators (KPIs).
Agile is particularly useful for early discovery laboratories where processes are commonly not well-defined. Baby steps are often needed to exhibit the benefits of moving away from the ubiquitous spreadsheet.
Agile has its foundation in the Spiral Model. The Spiral Model, defined by Barry Boehm of TRW in 1998, is also an iterative process combining the waterfall method with prototyping. Compared to Agile methods, Spiral has more structure than the freewheeling prototypes or rapid application development. This model focuses on the advantages of Agile (speed, prototypes, kaizen, user interaction) plus the overall "big picture," risk assessment and requirements definition advantages of the waterfall method. In development, regulated and quality assurance laboratories, the Spiral Model can be particularly helpful, as it does provide a bit more structure. The exposure is higher (especially in a regulated laboratory), so risk management is an essential component to consider.
[FIGURE 3 OMITTED]
Spiral is still a time-boxed methodology, where cycles of the spiral should only take two to six weeks. Cumulative time is based upon the number of cycles and the time for movement of a prototype/pilot through four stages. As users recommend changes and risks are analyzed, decisions are made whether to move forward. In this manner, not only are risks managed more effectively, but costs also are controlled through decisions whether to move onto the next phase of the project. A Spiral Model for ELN is shown in Figure 3.
Before the selection of a system, the spiral starts with use cases and functional requirements. An area is selected for an initial prototype--often early adopter volunteers--that will be taken through the quadrants:
* In the upper left quadrant, requirements for a prototype are developed and alternative approaches are researched.
* In the upper right quadrant, the suggested modifications and alternatives are evaluated for risks. Changes are implemented into the prototype and deployed to users.
* In the lower right quadrant, the team evaluates results from the group of users. Through this analysis, they determine the goals and objectives for the next revolution of the cycle.
* Next, the process flows to the lower left quadrant where new or modified capabilities are defined. The cycle moves to the upper left quadrant tailoring the system to meet the new objectives.
The use of ELN can dramatically alter laboratories' processes, which will involve change management at multiple levels. Iterative, time-based implementation methodologies can help the implementer manage risk, demonstrate success and, most importantly, exceed the users' resistance barrier.
Michael H. Elliott is CEO of Atrium Research & Consulting. He may be reached at editor@ScientificComputing.com.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||ELN; electronic lab notebook|
|Author:||Elliott, Michael H.|
|Date:||Jul 1, 2010|
|Previous Article:||Global Biotech: 2010 BIO International Convention: an updated look at the business end of biotechnology.|
|Next Article:||Quo vadis CDS? As CDS users, we need to think about what we want from these systems in the present and future.|