Issues of Change Management in the Implementation of E-health Projects
Dr. Ghulam Muhammadα & Dr. Fahed Mohammed Albejaidiσ
Background: Weaknesses at the implementation level of an eHealth project can nullify all the hallmark efforts undertaken during system analysis, design and development phases. Most of the information system (IS) failures such as correspondence, interaction, and process occur at some stage of the project implementation. It is however, argued that the most challenging aspect of implementation is the ‘resistance to change’ and thus ‘change management’ of an eHealth project.
Methods: Since, study was qualitative in nature, so discourse, hermeneutics and heuristic analysis techniques were used. Data analysis was done by a computer based software Atlas.ti.
Results: Problems faced during the implementation of eHealth projects stem from the personal, cultural and political interests of the participants. If emphasis is not placed on the understanding of these, the problems may turn into potential serious resistance to change.
Conclusions: It was hypothesized that there is need to change the patterns of change management by replacing the old technical stance with a ‘people-centric’ attitude towards managing IT-related changes from inception to the completion of a project. The analyses and results suggest that parallel importance must be given to techno-centric as well as people-centric problem during eHealth project analysis, design and implementation to manage the change successfully.
Keywords: E-health project, change management, techno-centric problems, people- centric problems, information systems analysis, design and implementation.
The digital boom and IT is though new to the psyche of the developing countries however, all the countries whether developed or developing are facing with challenges that comes out of IT implementation in their organizational structures. This technology is handy and effective to enhance the organizational performance and productivity (Kundi et al., 2008) however, introduction of IT in the human settings is not simple rather a complex and complicated job. Therefore, the repercussions of which could not be afforded as it influences not only the whole realm of organizational life in general but also the users in particular.
Like all other machines, IT is introduced to rescue the organizational members from the worries of data collection, processing and dissemination, however, in the same way it poses threats to the social and economic status of the organizational participants besides the physical and psychological harm on the human body (Kundi, 2010), so mostly it is taken negatively thus, resistance appears in the form of underuse and intentional distortions in the output of the IT. This is way instead of contributing towards betterment, it eats budget and resources (Kundi, 2010, Kundi et al., 2012).
Research indicates that implementation is the most difficult phase and can be “distinctly traumatic” (Sauer, 1993:69). Although the challenges begin with the very conception of an eHealth project however, “the real test of success or otherwise is during the implementation stage (Glass, 1998).” This stage of an eHealth project is also “the longest and the most resource intensive part of the development of the system (Mengiste, 2010).”
This study was intended to examine and analyze the factors causing resistance to change in the background of eHealth -project implementation and to recommend way-out i.e. how to make change management more effective in order to minimize the intensity of resistance.
This section presents analysis of the research carried out earlier to investigate and understand the phenomenon understudy.
3.1 Implementation of an eHealth Project
Implementation involves the preparations for the beginning of the new IS operation, implies, conversion of existing data files and programs to those suitable for the new system, final tests for the acceptance of the system by the sponsor organization; employees’ training for the new tasks and procedures; and, finally introduction of the new system into operation (Kundi et al., 2008; Kundi et al., 2012). It is at this stage that resources are expended to promote novel behaviors, to diminish opposing forces and to otherwise ensure that expected benefits from investments in new technologies are realized (Mengiste, 2010).
Thus, if we look into detail, we can find that implementation has many different meanings in the literature (Friedman, 2002). However, simply, it is the “transition stage” (Alvarez, 2004) between development and operation. During implementation of eHealth projects in particular, organization are facing with multiple challenges and issues both technical and social, which needs careful diagnose and analysis before execution of the project.
3.2 Techno-Centric Problems
The major area of the concern for the researchers is that whether to play-down the human aspect of eHealth project in favor of technical dimensions or not. Or which aspect may be given priority as both having multiple faces and effects on the success or otherwise failure of the system. Mostly, system development is done by the technical IT-professionals who may have less understanding of the organizational dimensions ‘orgware and peopleware’ (Kundi et al., 2012; Kundi, 2010). Therefore, they opt for better, sophisticated system instead of keeping the human dimensions of the organizations. This technical focus could become dangerous when it come to the stage of implementation as systems are developed to be used by the people who have socio-political, behavioral, psychological emotional sentiments and feelings with regard to their work and working conditions.
Thus, misalignment between the user and the system could occur and leads towards resistance and ultimately to the failure. The technical problems include testing of the new system, implementation strategy, and maintenance of the system.
3.3 Testing of New System
It is reported that some well-known failed information systems were found to have been implemented without proper testing (Flowers, 1996, 1997). Testing is like getting final approval from the users (Kundi et al., 2012). Technical testing aims at checking whether the computer’s performance is consistent with the design and analysis specifications, ‘acceptance testing’ aims at making sure that everything is in place for the system to begin operations, that is, acceptable to those who will use it. Testing at this stage is the final check of feasibility (Avgerou & Cornford, 1993). Therefore, researchers in IS asserts that before final usage of the system, it must undergo some sort of testing, which could be done through different mechanisms.
This helps the developers to understand and rectify the deficiencies that may be the result of miscommunication between the users and developers, and between the systems and the developers during the analysis, or design stages. Thus, it is wise to test before putting the new system in place to further avoid complications and failure.
3.4 Implementation Strategy
Implementation strategy is concerned with the choice of the most appropriate modes of implementation to meet the situation requirements.
The most commonly available options include: 1. Parallel running which is perhaps the safest method that allows for testing the IS in a real environment and comparing its performance with the existing system; 2. Modular implementation is a cautious approach, whereby the change implied by a new system is extended incrementally in manageable steps; 3. Pilot implementation provides a way to test the system in practice (at pilot sites) and to commit the organization gradually to the new system (Hussein, 2007).
Likewise, the terminal or cut-over strategy is also suggested by some experts, yet the cut-over implementation is the most risky way. To make this choice one must have made certain that the new system will stand the test of real practice. Otherwise it may be necessary to resolve quite unexpected problems in emergency situations (Kimaro & Titlestad, 2008).
3.5 Maintenance of the System
Maintenance is the long process covering the ‘use’ phase of a system. A system moves from implementation to the stage of review and maintenance. Maintenance is a life-long process and needs continuous management so that periodical updates are made as and when required. Most of the system development methods seek to contribute in some ways to improving the maintainability of the resulting systems (Kundi et al., 2008). For example, some methods for information requirements determination and systems analysis seek to forecast the organizational changes which will necessitate changes of the IS, and they try to provide adequate flexibility to meet them (Fitzgerald, 2006).
To keep pace with the changing technological and social environments, it is not possible to consider initial implementation as the end of the development of the system. Maintenance consists of activities triggered by the identification of problems and is directed at their resolution. However, at some point in time, the systems become too expensive to maintain or ceases to provide adequate business support, and at that time the life cycle starts again (Avison & Shah, 1997).
Thus, the maintenance accounts for a substantial proportion of the total system analysis and programming resources of organizations (Hussein, 2007). Information systems require corrections and, more importantly, enhancements to meet the continuous changes occurring in their environment. Maintenance is practiced in two modes (Avgerou & Cornford, 1993):
- Adaptive Maintenance: which deals with system changes to satisfy changing organizational requirements and to follow technological advances, and
- Perfective Maintenance: which deals with the requests to further improve an operational IS, enhance its functions, or add new features. The experience of working with a system creates new ideas for expanding or refining it.
This upholds that implementation is the stage where failures in use can occur or system use problems start emerging which needs to be addressed carefully.
All types of systems like eHealth systems are vulnerable to failure unless a well thought-out strategy is devised particularly for the management of human resources since users are not a homogeneous group of individuals, instead, according to Checkland & Scholes (1990) they come from various managerial and operational backgrounds and levels, and they may all have different opinions about an information system and its outcomes.
3.6 People-Centric Problems
Besides, the above discussed issues emerged from the technical dimensions of the eHealth project, below are the problem that occur because of the ignorance of the human aspect of the system.
3.7 Training of Users
Training of users for the best possible use of new systems is critical since training generates familiarity among the users thereby reducing the dangers of novelty (Alvarez, 2004). It can be the most costly single part of an IS project. The cost for training and organizational preparation for IS changes in large organizations may well exceed all other costs for system development (Kimaro & Titlestad, 2008).
Therefore, Land et al. (1992) advocates that training of users is essential because the knowledge, skills, and attitudes of users determine the level of the implementation success. Users steeped in the practice of an old system, unaware of the new facilities or their advantages, or skeptical about their benefits may cause the failure of the new system (Kundi et al., 2012; Davies et al., 1989). Some IS development methodologies come with a training package (De Grace & Stahl, 1990). For successful implementation training should go beyond just learning command structures (Hussein, 2007).
3.8 Resistance to Change
Often managers and IS developers anticipate resistance to change at implementation, almost as a natural phenomenon of human nature and general reluctance to accept change, and they prepare their strategy for breaking the resistance and pushing the system through (Hussein, 2007; Kundi et al., 2008). However, this attitude bears the risk of ignoring genuine signs of dissatisfaction which, unlike the resistance to the new and unknown, will not disappear with time, training, or incentives, but will lead to poor performance or problematic situations if a new system is forced into operation (Avgerou & Cornford, 1993).
There are several contextual factors in the implementation of ICTs in healthcare systems for example, the 'implementation style, number of project tools and user involvement. The implementation style is assumed to mediate the relationship between implementation characteristics (for example, the size and type of the implementation) and implementation effects (for example, negative or positive effects on employees and the organization) (Alvarez, 2004), similarly, the implementation style needs to be aligned with the contextual factors. The effects of the organizational context of system design are well researched (Davies et al., 1989).
3.9 Change Management
As information systems evolve, the practitioners like de Michelis (1998) may find the best way to handle continual changes is to employ a cohesive approach that recognizes an array of factors.
Dealing with change is one of the most fundamental challenges facing IS professionals today. Business process restructuring, shifting alliances and new competitors, deregulation and globalization, legacy system migration, and new technology adoption, are but a few of the economical, organizational, and technological forces contributing to the persuasiveness of change in the IT environment (Kundi et al., 2012). Flexible and adaptable IS can be powerful enablers for organizational and business innovations, whereas rigid, inflexible systems are serious obstacles to organizational effectiveness and success (Kimaro & Titlestad, 2008).
The computing field has responded to the challenge of change and the need for flexibility in a number of ways. For example, systems and software architectures have been developed to offer various notions of independence at many levels of abstraction (such as data independence and orthogonal persistence in databases, distribution transparency in distributed systems, and code mobility in programming languages like Java). Richer conceptual models are now used to support traceability in requirements and in design, and new kinds of systems based on email, GroupWare, and shared intranet workspaces have gained wide acceptance (Davies et al., 1989)
However, conceptual cohesion among these efforts is still missing. Experts argue that to deal effectively with change, one need to adopt a comprehensive approach that recognizes the many types of system evolution and their interdependencies. Recognizing that various areas of computing, public administration, and social sciences have made substantial advances in understanding and dealing with change from their respective viewpoints, researchers advocate a strategy that builds on these advances and practices.
Review of the existing literature was carried out to understand the dynamics of the topic, mechanism and role of the dependent and independent variables i.e. eHealth project, change management issues i.e. techno-centric and people-centric. After exhausting the relevant sources of literature, in subsequent step, computer based software ATLAS.ti was used for qualitative data analysis. The main concepts and variables of the study were entered into ATLAS.ti for coding, extraction of quotes and memos creation.
Moreover, as recommended by scientists of qualitative research, the researchers also examined, categorized, tabulated and recombined the data for the purpose of analysis by employing hermeneutics (James, 1992), discourse (Max, 1990) and heuristic (Moustakas, 1990) analyses techniques as study was qualitative in nature. Below schematic diagram of theoretical framework shows association between DV and IV in the background of issues of change management in the implementation of eHealth projects.
Figure-1: Schematic Diagram of the Theoretical Framework
V. DISCUSSION: PEOPLE-CENTRIC APPROACH
Research identifies several issues and problems in effective implementation including human, organizational and environmental problems (Kundi et al., 2008; Kundi, 2010). Major issues discussed relate to the testing, choice of implementation strategies, training and maintenance of the system. Problems faced during the performance of these functions stem from the personal, cultural and political interests of the participants (Kundi et al., 2012). If emphasis is not placed on the understanding of these, the problems may turn into potential serious resistance to change.
Most of the organizations address this problem through training. But people issues go beyond this, to feelings, to atmosphere in a project, resistance in meetings and the interaction between people. The predominant technical focus has meant that personal skills have not been sufficiently valued by either side (Kundi et al., 2012; Markus & Robey, 1988). The skills and time needed to manage people well in any change project are too often underestimated. These skills can be learned. Health departments need to select suppliers for both their technical and their people skills. There is then a better chance to develop a partnership (Alvarez, 2004).
People resist since they see their roles and relationships being changed and their work re-organized and thus they feel threatened (Kimaro & Titlestad, 2008). Moreover, they don’t imagine that one technical expert is just like another, thus it needs to consider the personality and range of behavior needed on the project as when they listen to project managers when they say the deadline cannot be met with the resources available. They set a climate of joint responsibility; you both want it to work. Don’t just tell each other what you think, but also listen actively, too. Make sure your team has communication, influencing and negotiating skills so that difficulties can be confronted constructively and with skill, and the partnership works smoothly. Regularly review the overall climate because the disclose fears and confront anxieties may also occur to develop resistance (Kundi, 2010). Likewise, there should be a culture to admit mistakes or lack of knowledge (Kundi et al., 2012). However, if the culture is one of blame, be aware that the project manager will get blamed if things go wrong (Kundi, 2010; Alvarez, 2004). Similarly, the manager should learn from mistakes and use them to improve the next project and last but not the least, formally close projects down and value the learning gained from them (Dann et al., 1998).
In the context of understanding and managing change, several studies propose to group the issues under three interacting facets. This article aims at gaining broader understanding of the change management problem, rather than offer a comprehensive solution that why are so many people disappointed by the results of eHealth projects? As end-user and client expectations start very high but as project proceeds they have to gradually reduce their dreams, and often there is sourness around (Kundi et al., 2008; Kundi et al., 2012). The reason according to (Mengiste, 2010) and de Michelis et al. (1998) is that people aspect is still not recognized as crucial to success.
CONCLUSIONS AND RECOMMENDATIONS
Researchers have had identified enough of IS project failures and sees the answer in a different approach – an approach which questions just what is meant by an ‘eHealth project’. Survey after survey reveals that most IS projects fail. To be precise they fail to make their organizations more effective: indeed, they typically cause new organizational problems and eat budget. If we are to break the pattern of eHealth project failure, we must break the mould and cognitive maps wherefrom these failures are result. That mould is essentially a technological one. We need to jettison it for an organizational one: the business project.
IS projects treat technology as an end itself, whereas a business project is not technophobic? It simply regards technology as an issue of effective use. In general an eHealth project aims to deliver a new system which better serves those who use it. But without an appreciation of the organization being served, these new computer systems do not form an effective part of a new business system. What does the work ‘system’ mean to eHealth project staff?-A collection of hardware, software and networks? a set of functions? a group of programs?
E-health projects aim to solve problems by exploring the organization’s own understanding and then planning for new system. Here a system means a human activity system which these days typically include technology. How do we decide? First we must communicate to each other our own understanding of how things currently operate in the organization. At the dawn of IS projects machine code was the dominant communication mechanism. In the 1960s and 1970s higher level languages emerged. The late 1970s and early 1980s brought us structured analysis and design. But for many end-users a data model still baffled the brain as much as several column inches of DDL. In the late 1980s object-orientation stuck a shiny class grille on the front of the structured vehicle and asked end-users to test-drive that instead. There should have been no surprise when these object-oriented models turned out to have no better handling than the corresponding structured analysis ones: that is exactly where they came from.
All this upholds that parallel importance must be given to Techno-centric as well as People-centric problem during eHealth project analysis, design and implementation of the eHealth project to manage the change successfully in implementation of the eHealth project.
IS: Information System
DV: Dependent Variable
IVs: Independent Variables
IT: Information Technology
eHealth: Electronic Health
We are thankful to our colleagues Dr. Allah Nawaz and Robina Akhtar for their feedback. Though this study is not funded by any organization however, we acknowledge the Qassim University, Kingdom of Saudi Arabia for providing is us space in schedule to devote more time to our research project.
This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/ by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made. The Creative Commons Public Domain Dedication waiver (http://creative commons.org/publicdomain/zero/1.0/) applies to the data made available in this article, unless otherwise stated.
The authors declare that they have no competing interests.
- Alvarez AJS. Challenges of information systems implementation in organizational change management: Insights from the health sector in Ecuador. Electronic Journal on Information Systems in developing Countries. 2004; 16(6): 1-16.
- Avgerou C, Cornford T. A review of methodologies movement. Journal of Information Technology. 1998; 5: 277-286.
- Avison DE, Shah H. The information systems development life cycle: A first course in information systems. The McGraw-Hill Companies. 1997. New York.
- Checkland P, Scholes J. An application of SSM in the NHS: An SSM in action. Wiley, Chichester. 1990.
- Dann J, Broome A, Joyce W. Human barriers to project success. The Computer Bulletin. May 1998.
- Davies FD, Bagozzi RP, Warshaw PR. User acceptance of computer technology: A comparison of two theoretical models. Communications of the ACM. 1989; 3(5): 982-1003.
- De Michelis. A three-facet information. Communications of the ACM. 1998; 41(12): 64-70
- Fitzgerald, G. Effective technical and human implementation of computer-based system (ETHICS) in Information system development: Methodologies, techniques and tools. Berkshire, UK; 2006. The McGraw-Hill Companies.
- Flowers S. Toward predicting information systems failure. In: Avison, D. E. (Ed.). Proceedings of the 2nd UKAIS Conference on ‘Key issues in information systems. University of Southampton Publisher. 1997. 2-4 April.
- Friedman LT. The lexus and the olive tree. New York: Anchor Books. 2002.
- Glass RL. Software runaways: Lesson learned from massive software project failure. Prentice-Hall Co. and Yourdon Press. 1998.
- Hussein R, Mohamed N, Shahriza N, Karim A, Ahlan AR. The influence of organizational factors on information systems success in e-government agencies in Malaysia, The Electronic Journal on Information Systems in Developing. 2007; 2(4): 21-34.
- James P. Gee. (1992). Discourse analysis. In: LeCompte, M. et al. (2001). The handbook of qualitative research in education ((Eds). chapter 6). 1992. San Diego, Academic Press, USA.
- Kimaro HC, Titlestad OH. Challenges of user participation in the design of a computer based system: The possibility of participatory customization in low income countries. Journal of Health Informatics in Developing Countries. 2008; 2(1): 77-89.
- Kundi GM, Bartoli Jacques-Andre, Bail Serge. E-Local government: Implementation barriers in Pakistan. Post-Doctoral Research, Lap- Lambert Academic Publishing. 2012. Germany.
- Kundi GM, Shah B, Nawaz A. Digital Pakistan: Opportunities and challenges. JISTEM, Revista de Gestao da Technologia e Sistemas de Informacao Journal of Information Systems and Technology Management, Sao Polo, Brazil. 2008; 5(2): 365-390, ISSN online: 1807-1775.
- Kundi GM. E-Business in Pakistan: Opportunities and Threats. PhD thesis, Lap-Lambert Academic Publishing. 2010. Germany.
- Markus ML, Robey D. Information technology and organizational change: Causal structure in theory and research. Management Science. 1988; 34 (5): 583-598.
- Max V Manen. Hermeneutical Analysis: Researching lived experience. State University of New York Press. 1990. USA.
- Mengiste SA. Analyzing the challenges of IS implementation in public health institutions of a developing country: The need for flexible strategies. Journal of Health Informatics in Developing Countries. 2010; 4(2): 22-36.
- Moustakas C. Heuristic research. Academic Press, Newbury Park. 1990. USA.
- Sauer Chris. Why information systems fail: A case study approach. Alfred Walker, Henley-on-Thames. 1993. Oxford shire.
- Smith Ian. A new mould for IT projects. The Computer Bulletin. 1998. January.