Next Article in Journal
The Design of an Intelligent Lightweight Stock Trading System Using Deep Learning Models: Employing Technical Analysis Methods
Previous Article in Journal
Fundamental Prerequisites of Operational Readiness, Activation, and Transition: Case Study of Istanbul Grand Airport
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

How to Apply and Manage Critical Success Factors in Healthcare Information Systems Development? †

1
Department of Engineering Science, University West, Gustava Melins Gata 2, 46132 Trollhättan, Sweden
2
School of Informatics, University of Skövde, Box 408, 54128 Skövde, Sweden
3
School of Business Economics and IT, University West, Gustava Melins Gata 2, 46132 Trollhättan, Sweden
*
Author to whom correspondence should be addressed.
This paper is an extended version of our paper published in 20th European Conference on Information Systems, Barcelona, Spain, 10–13 June 2012.
Systems 2023, 11(9), 469; https://doi.org/10.3390/systems11090469
Submission received: 6 August 2023 / Revised: 1 September 2023 / Accepted: 5 September 2023 / Published: 12 September 2023

Abstract

:
Studies on Critical Success Factors (CSFs) in Healthcare Information Systems (HIS) development projects have traditionally often been limited to retrospectively identifying CSFs in a finished project. In this paper, we focus on how to prospectively apply and manage CSFs in HIS projects. Based on a holistic perspective and systems thinking, an inductive research strategy was applied and a single in-depth case study was conducted. The findings include detailed descriptions that contribute to further understanding of how to prospectively apply and manage CSFs in HIS projects. The analysis reveals that CSFs must be applied differently and managed on various system levels. Furthermore, it shows how interactions exist between different system levels, both in the case of a specific CSF and between different CSFs on various system levels. Our analysis framework and findings indicate new directions for future research: how to prospectively apply and manage CSFs in HIS development projects can now be investigated both in a more holistic way and more in detail. Finally, healthcare practitioners can use the descriptions as practical checklists for guiding them in how to realize situational adaptation of CSFs in HIS projects across different system levels.

1. Introduction

Digital transformation in healthcare is required due to the demographic changes in the Western world, where the population grows older, with more complex diseases [1,2] The development of Information Systems (IS) has proved to be challenging, both in general, e.g., [3,4], and in healthcare specifically, e.g., [5,6]. The underlying cause for development and implementation difficulties and failures is the inherent complexity when technological, social, and organizational factors interact [3,7]. Healthcare Information Systems (HIS) are complex, emerging from the many interconnected and interdependent elements and their feedback structures, but also the relations with multiple independent elements in the surrounding environment [8]. The need to include the entire HIS in the development, not just the information technology (IT) is obvious, e.g., [9,10]. HIS are a precondition for secure and effective healthcare as they are an integral part of care processes and documentation processes [11], as well as learning processes [12].
Understanding and applying Critical Success Factors (CSFs) is one way to improve Information System Development (ISD). Applying CSFs contributes to success when designing and performing an ISD project [13,14]. CSFs can be described as “the conditions that need to be met to assure success of the system” [15] (p. 395) and should consist of a limited number of factors [16]. Researchers have since the beginning of the 1960s been doing research on CSFs [17]. Despite differences between organizational contexts, technological applications, countries, ISD life cycle phases, and differences on many other dimensions, common CSFs for ISD can be identified [18]. However, even if CSF is both a mature and active area of research, IS projects still have a high failure rate [17]. “Project failure factors that originate from the way the project is being managed before, during and when nearing completion are widely represented in the literature” [19] (p. 15). Moreover, there also exists a lack of depth and detail in the description of CSFs [17].
CSF research has traditionally often been limited to retrospectively identifying CSFs in a finished project [20,21,22], i.e., identifying “what” these CSFs were for the project. Studies seldom discuss “how” to apply and manage CSFs prospectively. “It is not always easy for project managers to know how to implement and apply CSFs in practice” [23] (p. 16). How to apply and manage CSFs should more effectively be included in the risk management of ISD projects to meet expected project benefits [24]. Warren et al. [17] conclude that the goal of identifying a generic list of CSFs for project management has been achieved and that there is a need to change from “what are the CSFs” to “how these CSFs can be of benefit to project managers”. Furthermore, Cyrus et al. [24] claim that most studies missed the importance of CSFs’ interrelations. This means that there is a major challenge for the research community to change from descriptions of what these CSFs are, to interpretive explanations of how these CSFs can be of benefit to project managers [17], when designing and implementing an IS. Therefore, there is a need to explore and describe how CSFs need to be applied and managed in a more elaborate way. The goal of this paper is to further understand how to prospectively apply and manage CSFs in HIS projects. To achieve this goal an inductive research strategy has been applied and a single in-depth case study has been conducted. The findings show how CSFs are managed on different system levels and reveal interactions between CSFs and between different system levels, which to the best of our knowledge is a perspective that is missing in current CSF research.
The research background for the study consists of systems thinking as well as earlier work concerning CSFs (Section 2). To achieve the goal, empirical data from a successful HIS development project has been analyzed using a qualitative thematic analysis method (Section 3). The core of the paper is the rich descriptions of how four overarching CSFs have been applied and managed on various system levels in a HIS development project (Section 4). The implications of the findings for researchers and practitioners are discussed (Section 5) and three main contributions are summarized (Section 6). Finally, suggestions for future research are given (Section 7).

2. Research Background

A holistic perspective and system thinking have been used as an underlying theoretical foundation for this study. A system is “an assembly of elements related in an organized whole” [25] (p. 7), which in turn relates to other systems [26]. The degree of complexity increases with the number of elements, relations, and levels as well as when people are included in the system. Systems thinking is a way to understand and manage complexity by adopting a holistic approach. This includes studying and understanding things from the three levels of inquiry (why, what, how) as described by Van Gigch [27]. Although features such as the complexity of the organization, the diversity of stakeholder interests, and the autonomy of the workforce may not be unique for healthcare organizations, the combination, volume, and extremeness of these features make healthcare a more challenging environment for ISD than most other service organizations [28].
CSFs describe various critical variables containing actions that must be carried out in order for an organization to achieve its objectives in a project [29]. They should consist of a limited number of factors [16]. When too many CSFs are selected (e.g., more than four to six), they are probably too detailed, and not all of them may be critical [26]. In an extensive literature study of CSFs in ISD four overarching CSFs were identified from a large number of more detailed CSFs [30], see below. More recent studies confirm that these four CSFs still are relevant and current, e.g., [24,29,31,32,33,34].
The four overarching CSFs are as follows:
  • CSF1: To learn from failed projects: Organizations must learn from their own experiences and not make the same mistakes over and over again ([35,36]. This relates to Axelsson et al. (2011) [37] stating that adaptation to context is important. Also, ref. [33] highlights that a process for learning from previous mistakes should be institutionalized from the project start. Anantatmula and Rad [38] also claim that learning from past projects is critical to attaining project management maturity. It is also important to understand the earlier experiences and the organizational culture to be able to understand where important and suitable project champions can be found [39];
  • CSF2: To define the system’s boundary, for the whole system and for relevant subsystems: The system’s boundary concerns the business border. It constrains what needs to be considered and what can be left outside [27]. Only if the organization as a whole is clear about its aim and works on a principle of shared values can small units be allowed to take responsibility for running themselves [40]. The system needs to fit the organizational context, and the project manager needs to be fully aware of how well the system matches the organization and its boundaries. A project is more likely to succeed if the change is limited to its boundaries, as the level of risk will be reduced [24];
  • CSF3: To have a well-defined and accepted objective aligned with the business objectives: A successful IS should meet agreed-upon business objectives [35,41]. An organization should be examined from different perspectives [42] which in turn is a prerequisite for defining the objective. Commitment from management is crucial if the project affects a large part of the organization [41]. Nasri and Sahibuddin [32] define the related factor of clear and frozen requirements as critical to software projects. Already in 1983, Markus and Robey [43] stressed the importance of the organizational context for the IS. The project manager has to develop a strategy to achieve a successful implementation of the IS [29]. The business environment and both the internal and external needs of the IS need to be analyzed as a prerequisite [34];
  • CSF4: To involve, motivate, and prepare the “right” stakeholders: How well an IS will work in an organization depends on the user involvement in the development process [44,45]. The success of this involvement depends on how well people work and communicate [46]. In working together as a team, it is important to adapt and tailor one’s role in the team and communicate well with each other [29]. An important IS project success factor is the ability to incorporate the views of all stakeholders in the project [31]. Moreover, cooperation among the stakeholders reduces the possible risks that may lead to project failure [34]. Furthermore, stakeholders will also act as champions (plural) for the project and it is important that they complement, not resemble, each other, and are committed to the project [39].
In our long-term endeavor to reveal and better understand the complexity of applying CSFs in ISD we have learned that managing CSFs is about adapting them to situational and contextual factors and applying them in concert, rather than in isolation, since they strengthen each other [14,24]. We have also learned the need of using champions in a structured and conscious way [39].

3. Research Method

Both healthcare organizations and HIS are complex, e.g., [6,8] and managing CSFs is about adapting them to situational and contextual factors from a holistic approach [14]. Thus, our research is based on a holistic perspective and system thinking is used. This emphasizes the importance of understanding the case’s role in the big picture and implies that the case is considered both as a part of the whole and as a system that consists of interrelated components. Such a system is more than the sum of the components in the sense that the system possesses emergent properties. This is an approach appropriate for studying the complex situations caused by human interactions, as a way to deal with social complex problems [47]. The purpose of a system can be achieved by using the relationship between “things” and “people”. In the process of dealing with a complex system, the system is affected by a lot of non-structural factors and human factors [48]. It also includes studying and understanding things from the three levels of inquiry (why, what, how) as described by Van Gigch [27].
In accordance with the goal of this study, we want to understand how CSFs can be prospectively applied and managed in order to inform theory building, rather than theory testing. This justifies an inductive research strategy [49] and a single in-depth case study has been conducted. Results from a single case study inform theory building through analytical generalization rather than statistical generalization [50]. Case study data has been analyzed according to a single-case holistic design as described by Yin [50]. The single unit is the Referral and Answer SubProject (RASP) designed and implemented based on the four overarching CSFs described in the previous section [14]. The study produces context-dependent knowledge and experiences in an attempt to understand complex issues in real life [51]. The case RASP and the data analysis strategy are discussed below.

3.1. Case Introduction

The Referral and Answer SubProject (RASP) was part of a larger HIS project, The Referral and Answer project, which was performed in a Swedish organization called the Region of Västra Götaland (VGR) [14,39]. Healthcare in VGR was organized in 15 autonomous administrations, e.g., each hospital and each administration of healthcare centers with their own board, controlled by an administration manager. The Referral and Answer project concerns the process of referral and answer and aims to ensure patient security by implementing a standardized way of working and information content that supports the referral process for all types of referrals. Objectives to achieve this aim include developing and implementing a VGR common regulations book, a desired common and unified VGR referral process as well as a common VGR IT solution. The first two of these three objectives, and an accompanying objective of getting people motivated and positive to the project, were central in the RASP case. RASP achieved its objectives and is regarded as really successful by the various involved stakeholders as it obtained its results.
From a holistic view, the project was designed based on the four overarching CSFs described in Section 2. In an organization with 45,000 employees, it is impossible to work together with everybody. On the other hand, it is critical to involve both management and people working in the healthcare process. A participatory structure was developed and RASP administration managers were appointed in each of the 15 administrations. These RASP administration managers were critical for the multiple champion behaviors performed by multiple champions [39].
The RASP project team included three members. Two of them have healthcare education and extensive experience in healthcare work but are now working as Operations Controllers, namely, Development Managers in two different administrations in the VGR. The third project team member has a PhD in Data and Systems Science, had a position at VGR when the project was performed, and is the first author of this paper. When the first author became a member of the ISD project team, she argued that the project should be designed and implemented based on CSFs to support a holistic approach. This means that the first author was directly involved in RASP and hence had the possibility to “… test a working hypothesis about the phenomenon of interest by implementing and assessing change in a real-world setting” [52] (p. 441). The used CSFs in RASP are the four overarching CSFs described in Section 2.
The data collection in RASP was based on the participation of the first author in the RASP project team and an in-depth interview held by the second author with the contact person in the steering group. The data collection related to the participation of the first author in the RASP project team included project notes and presentations, but also individual reflections from a research perspective written down during the project. During the 13 month project period, regular discussions were held in the project team considering planned CSF-related actions and interventions, positive and negative effects of these actions, and reasons why these effects occurred. The results of these discussions were documented by the first author. In summary, the collected data consisted of formal meeting notes, slides used during the meetings, and documented personal reflections of the first author.
For a more comprehensive and thorough description of the case and data collection methods, we refer to [14].

3.2. Data Analysis

Data analysis was performed by the first and second authors, and the third author was included in a later stage in the writing process. The first author had an insider perspective, and the second and third authors had a more neutral outsider perspective. Hence, within the group of researchers, the insider and outsider research team approach was used [53]. This has many positive outcomes, for instance, the insiders can help the outsiders to understand and become more involved in organizational matters and the outsiders can assist the insiders in zooming out, offering a distanced approach. Preunderstanding shapes can orient people towards particular strategies for knowledge production and action. Being solely an outsider as a researcher can result in making it difficult to include the situations that insiders have “lived”, within practice [53]. Throughout the data analysis both these perspectives are combined to form a thorough understanding of the case presented, thereby contributing to one another. To validate the correctness of this paper the findings have been shared with one of the other project members in RASP.
Data analysis focused on how the overarching CSFs were applied and observed in the case. A first analysis [14] revealed that general CSFs were tailored to situational circumstances and were strengthening each other. This analysis was on a quite general level and did not yet fully reflect how different CSFs actually were applied and managed in different situations. Subsequently, a more thorough thematic analysis of the qualitative data collected in the RASP project was conducted. The analyzing work was grounded in systems thinking and had an “emphasis on a holistic approach to understanding systems … eliminating the deficiencies at a systems level that created the problems in the first place” [54] (p. 2163). The analysis was conducted inductively, from a ‘bottom up’ way, i.e., the themes identified were strongly linked to the collected data [55]. However, the researchers’ theoretical and analytical interest in systems thinking and the application and management of the four overarching CSFs have been of importance in identifying themes. The CSF literature has enhanced the analysis by sensitizing to more subtle features of the data. As a result, particularly interesting examples of “CSF application” in the empirical data were highlighted and organized.
A thematic analysis includes a number of steps and levels, which are performed iteratively and in parallel [55]. In phase one, the entire data set was read through several times before the coding started, to become familiar with all aspects of the data. This was mainly performed by the first author, with an insider perspective, while the second author, with an outsider perspective, continuously asked questions in order to clarify and deepen the understanding. Then, in the second phase, initial codes were generated by the first author, together with an initial list of ideas about what was identified in the data, in relation to the aim of this paper. In the third phase the first and second authors together focused on the analysis from a holistic perspective in relation to the whole data set, and by applying systems thinking, sorted the different codes into potential themes at the broader level. In phase four the themes were determined and reviewed, in order to include coherent and meaningful data and to include clear and identifiable distinctions between the identified themes. The fifth phase included the refinement and the final naming of the themes. Furthermore, the data within the themes were analyzed in this phase, to identify the essence of each theme. The fourth and fifth phases were conducted by the first and second authors together. The sixth and last phase involved the final analysis and writing of the findings. The last phase also included reviewing the data again using the themes as a tool to ensure that all aspects were considered as a way to verify the findings. In this work, all three authors were included. Thus, the findings illustrate the story revealed in the collected data, in relation to the research goal in this paper.
Based on the thematic analysis, five themes in the form of system levels, where CSFs were applied and managed, were identified: the individual level, the technology level, the project level, the organizational level, and the societal level as pictured in Figure 1.
These themes contribute to a further understanding of how to prospectively apply and manage CSFs in HIS projects. While we went through all the data again and again, using these system levels as a tool to group them, we enriched our knowledge about what these system levels concern. In the next section, we describe the findings using these system levels.

4. Findings

The goal of this paper is to further understand how to prospectively apply and manage CSFs in HIS projects. To enhance readability the findings are presented for each CSF using the identified system levels (see Figure 1). We believe that this structure will contribute to clarifying how CSFs prospectively can be applied and managed on various system levels as well as how they can interact and support each other. In the descriptions, there are references to other CSFs in order to make interactions between the CSFs more visible. Each CSF description is summarized in a table (Table 1, Table 2, Table 3 and Table 4).

4.1. CSF1: To Learn from Failed Projects

As there had been negative experiences with earlier HIS development projects in VGR, the project team recognized the importance of this CSF: to explore and understand why similar projects had been problematic in the past in this organization in order to prevent making the same mistakes (see Table 1).
On the project level, it involved looking thoroughly at several recent related IT development projects and investigating for each of them why they had succeeded or why they had had problems. During this analysis, the CSF was rephrased from “learning from failed projects” to “learning from earlier projects, both successful and failed ones”. It became apparent that contrasting successful and failed projects created insight into what kind of approaches were crucial in this organization. Lessons learned from this analysis were amongst others that earlier ISD projects had a strong focus on technology and not on implications for work process redesign. Therefore, the current project was rephrased as a work process development project rather than an IT project, which was also signaled by making the organizational development department rather than the IT department responsible for the project. Here, learning from earlier projects (CSF1) influenced how the boundary for the project was defined (CSF2). It proved to be very important that lessons learned not only created understanding in the project team but also resulted in concrete (visible) changes in the current project. These new project design choices were clearly related to the lessons learned to emphasize that “things would be done differently this time”. In the first meeting with the RASP administration managers, one of them raised the question “Why shall we succeed this time?”. This question revealed the importance of being more structured and clearly communicating the main differences between the RASP approach and the former way of working in a more structured way, which was an important prerequisite for getting commitment and acceptance for the project (CSF3). This communication was in practice carried out by the individuals involved in the work.
The analysis did not only create insights on the project level. Analyzing large IT development projects over a longer period of time revealed deeper insights on the organizational level. For example, it became even clear how large and complex the VGR organization is with its many autonomous administrations and the challenges to create support for changes at the highest decision-making level, at middle management levels, and at the work floor. As a consequence, the project team developed a participatory structure to manage these complex challenges of creating support at all organizational levels. Here, learning from earlier projects at the organizational level (CSF1) influenced how stakeholders were involved and motivated on the project level (CSF4). The participatory structure defined how stakeholders from many different levels, departments, and roles were involved and how they could influence the change process. Again, understanding from earlier innovations was converted to a clear action point for the current project.
The individuals who became members of the project team and members of the participatory structure were individuals who had been part of earlier successful and less successful projects. They were also members of the VGR organization and therefore carriers of the organizational culture. RASP had a conscious strategy when selecting members and considered their different backgrounds, knowledge, affiliations, and experience with earlier IT implementation projects at various levels and units of VGR. Another important issue was to convince key individuals in the project how lessons learned from earlier projects resulted in a different strategy in this project (the participatory structure). The individuals served as project champions and were instrumental in communicating how the participatory addressed earlier development problems and in that way motivating stakeholders to contribute to the project (CSF4).
Whereas the project was rephrased as primarily a work process development project, the role of technology support was constantly addressed. Based on disappointments from earlier projects, technology was not seen as an isolated phenomenon, but the integration of the work process and technology support was seen as crucial.
The review of earlier healthcare innovation projects in VGR also revealed that such projects are complex because innovation is a part of society and not without constraints, but needs to consider national regulations, policy guidelines, and existing technological and data exchange standards and protocols. Tensions between local needs and national standards could partly explain dissatisfaction with innovation results when large system inertia resulted in marginal innovation. Project participants needed to become aware of the necessity and consequences of system inertia, as well as means of how major issues at a national level can be influenced (see further CSF2).

4.2. CSF2: To Define the System’s and Subsystems’ Boundaries

The key to a successful project is that boundaries are clear considering what is included in the project and what is not, as well as the relations between them (see Table 2). Earlier referral projects did not achieve their aims and the experience from another recent high-stakes VGR IT project was among many stakeholders regarded as negative (CSF1). How the project was placed in the organization also influenced how the project was interpreted in the organization. To emphasize the aim and the holistic view, a decision was taken in the planning stage to change the project from an “IT-project” governed by the IT department to a “Development project with IT-support” governed by the healthcare department. The different characteristics of RASP were important in the forthcoming work with the development of work processes.
Clear boundaries and relations imply not only exploring and defining the project’s boundaries and relations but also managing them over time. Boundaries may be debatable or misinterpreted, or circumstances in the project or in its environment may change. In these situations, the project team has to have a strategy to manage these relations, i.e., arguing for maintaining the boundary as it is, or adapting the boundary to the new situation.
Boundaries and relations exist at many interfaces. One already discussed issue is to visualize the role of technology and how it relates to work processes and business objectives. In RASP the Swimlane technique was one technique used. The need to use already stored data from technological applications, as well as storing newly created data there as a result of a decision, were shown in one swimlane. Activities of different actors were shown in other swimlanes. In this way, the role and contributions of technology became clear and could be influenced throughout the whole project.
On the project level, the scope of the project has to be articulated unequivocally, in close relation to the project objective (CSF3) and the larger organizational purpose. In RASP this implies explaining why the project is of urgency from the customer’s (patient’s) perspective. In the RASP case, the following patient citation was used in all meetings, to remind everyone involved why RA was performed, and to create a sense of urgency: “That one needs to wait several months to get an appointment and an answer; it is anyway my life that is ticking away”. Given the project assignment and objective, relations with the surrounding organization and the larger environment need to be explored on the organizational and societal level. By mapping what benefits are produced for different interest groups in the organization the role of the project in the larger whole becomes visible.
From the relation between project and organization, it is a small step to look at how this CSF is manifested at the organizational level. One important issue is to understand the organizational culture and informal decision-making processes, which also will contribute to understanding where important and suitable project champions can be found. This can again be utilized at the project level. When the role of the project in the larger organization has become clear, general CSFs such as “involve the right stakeholders” can be translated into project-specific ways of working. The stakeholder representatives that are identified by the objectives in CSF3 and addressed in interaction strategies in CSF4 are a means to manage relations with interest groups in different parts of the organization.
Another issue at the organizational and societal level is to map how project results interfere with existing governing policies, other parallel change projects, and cultural habits. From the understanding that boundaries are not fixed, but illustrate relations that need to be managed and negotiated continuously, the project team needs to ponder whether to accept certain of the policies or parallel project decisions as given, or whether to aim to influence and change them to create more room for the own project. It is also important to analyze the project’s relation to other projects in order to understand how to influence and also what will influence. For example, the relationship between RASP and a national Referral and Answer project (National eReferral) was described and communicated as shown in Figure 2. This was a result of discussions concerning the interface between RASP and the National eReferral. There were opinions in the project that RASP should be interpreted as a part of the National eReferral project and therefore had to be paused pending results and decisions from the national work. Analyzing the interface from a holistic approach using systems thinking resulted in a common view that the knowledge developed in RASP must be shared with the National eReferral project. But it also resulted in an insight into the importance of being updated and informed of what was happening on the national level as well as the need to influence the national work. To appoint the right stakeholder here was critical (CSF4). System thinking was used as a base for visualizing and communicating this (Figure 2).
On the individual level, the vision of the role of the project and its relations needs to be realized practically by the project manager. Although all project team members (and even closely involved stakeholder representatives) are involved in managing the relationships across boundaries at different levels, it is of utmost importance that the project manager clearly can explain the role of and need for the project from these multiple perspectives. When selecting a project manager it is important to investigate whether these skills are present. For example, the potential project manager could be asked to describe the project, with a specific focus on the technology’s role and how to develop it. The potential project manager could be asked to describe how to use the chosen project strategy and working methods. The latter might show whether the project manager can adapt general approaches to the specific circumstances of this project.

4.3. CSF3: To Have a Well-Defined and Accepted Objective

The interests of the different stakeholders were mapped and served as input for formulating a project objective that unified all the interests (see Table 3). For RASP, patient security was chosen as an overarching objective that was relevant and important for all stakeholders. Patient security is also an important issue at the national level, so this objective also served well to address stakeholder interests at that level (in relation to CSF2). During the development of the objective stakeholders were already involved by means of informal anchoring, which implied that the objective could be influenced earlier, was known at the start of the first formal meeting project, and was supported by all stakeholders (in relation to CSF4).
When formulating the objective in different ways, the role of technology was addressed, i.e., how technology contributed to patient security and how it enabled new work processes that served patient security. Additionally, on the societal and organizational level, a check was done on whether the objective was in line with existing local and national governing policies.
The process of creating acceptance for the objective continued during the whole project in order to maintain support. That earlier referral projects did not achieve their aims and negative experience from another VGR IT project (CSF1) were important aspects to pay attention to. Much effort was put into connecting the overall objective to each of the stakeholder’s interests by reformulating what patient security in the context of this project meant for them and the group they represented. That activity addressed both the individual and the organizational level. At the individual level, each of the stakeholder representatives needed to be convinced. This was partly done by creating examples with a strong emotional appeal (i.e., showing the consequences for patients: “it is after all my life that is at stake”). Furthermore, the three levels of inquiry WHY-WHAT-HOW helped us to formulate and obtain a commitment for objectives on different levels (CSF2). To obtain acceptance from every administration, it must serve the overall objective of patient security on the why level, it must be described on the what level, and at the same time leave the how level open for local implementation adaptations. As put by one RASP administration manager: “How we take us from A to B is our own responsibility”.
Secondly, by explicitly addressing what patient security implied for their department or interest group, the stakeholder representatives were supported to convince their own home organization. Deliberately, the objective, i.e., the desired and common unified VGR referral process, was formulated on the “what level” to give stakeholders room “how to” implement the objectives in suitable ways. If objectives had been formulated too rigidly on the how level, it would have been much more difficult for all the different organizational departments with their unique circumstances to accept them.
During the project, progress toward the objective was constantly addressed at all formal project meetings in the project. Partly as a way to maintain support for the objective and to check whether all activities really contributed to it, and partly as a way to increase motivation and support for the project and its results as a whole.

4.4. CSF4: To Involve the “Right” Stakeholders

This CSF is about identifying and involving the right individuals for different roles in the project (see Table 4). Project team members need to complement each other and together they need to cover all the required competencies. Additionally, they need to support the project objective and they need to be good communicators who can relate to the many interests of the stakeholders. In a similar way, stakeholder representatives need to be selected who believe in the project and that act as enthusiastic ambassadors, while they at the same time need to have good relations with their home organization in order to be able to convince them of the importance of the project. Therefore, the RASP project defined some base criteria that stakeholder representatives should fulfill, while each department board selected the most suited person (as they had insight into which person both fulfilled the criteria and had a good network in their own department). In addition, the project team realized that these individuals had to be convinced about the necessity and background of why this new approach was chosen. Development work is about changing individuals’ beliefs and assumptions which are based on their earlier experiences (in relation to CSF1).
On the technology level, one important aspect was that at least some of the many involved stakeholders and project team members had skills that helped to mediate the relations between technology interest groups and healthcare process interest groups.
As already addressed under CSF3, all the involved individuals and the respective groups they represented needed to be convinced at the start, as well as support from them needed to be maintained throughout all phases of the project. A dedicated infrastructure that guided and supported interaction between all stakeholders in informal gatherings and formal meetings proved to be especially effective during RASP. This participation infrastructure, a new way of working in IS development projects compared to earlier (CSF1), was regarded as an innovation and an extra result of this project in itself.
On the societal level, the interface between the local RASP and the National eReferral project was identified as a critical one (see CSF2). Project team members served as a stakeholder and project members for the project in the national arena, just like stakeholders from organizational departments joined RASP. Furthermore, one person from the formal steering group in RASP was included in the national steering group. This was a proactive action in accordance with how the interface was defined between RASP and the national work, and its consequences.

5. Discussion

The findings presented in this paper illustrate a deeper understanding of how to prospectively apply and manage CSFs. The analysis confirms that “there exist strong interactions between the four CSFs applied, which implies that CSFs should be analyzed and applied in concert rather than in isolation” [14] (p. 11). The analysis shows that each CSF was observed on and tailored to different system levels and that the different system levels interact in order to manage the CSFs. This means that the analysis reveals that it exists strong interactions between different system levels, both within the limit of a specific CSF and between different levels and CSFs. To the best of our knowledge, this finding goes beyond existing literature. It adds a new perspective to existing knowledge that CSFs are not singular and isolated, but interlinked and consisting of several dimensions [14,17]. Furthermore, learning considering the application of the 4 CFSs resulted in elaborated and refined formulations for each CSF which are presented in Table 5 and discussed below.
Concerning learning from failed projects (CSF1), our analysis shows that learning also must include learning from successful ones. Furthermore, the importance of communicating what is done differently this time as a result of what is learned appeared as really important. The individuals served as project ambassadors and were critical for the multiple champion behaviors performed by multiple champions as described in van Laere and Aggestam [39]. Culture can be regarded as the result of a group’s accumulated learning [56] and the importance of culture was revealed in our analysis. This is also well established in the literature, e.g., [33,57]. One important issue is to understand the organizational culture and informal decision-making processes to be able to understand where important and suitable project champions can be found [39]. Knowledge concerning boundaries and relations (CSF2) are only “tools” for understanding an ISD project’s role in the big picture: the main thing is to have a holistic approach. In more recent studies the importance of CSF interrelations is emphasized, e.g., [14,17,24], which in turn requires a holistic approach and systems thinking. The importance of having a well-defined and accepted objective is well-established in the literature (CSF3). Our study demonstrates the importance of having corresponding objectives on the different levels of inquiry [37] as well as the importance of having a way of working that is well-defined and accepted. Finally, our study also portrays that the need to involve, motivate, and prepare the “right” stakeholders (CSF4) must also be taken into consideration from a champion behavior [39] and a change management perspective on the project, organizational and societal levels rather than only the individual level.
Reflecting on our own research design, it appeared to us that the typical research design of CSF studies may be a contributing factor to why they often focus on the identification of CSFs and seldom discuss the application of CSFs in depth. More studies in the field of CSF need to take the application question as a starting point to further develop our understanding of this complex matter. Whereas CSF studies often are quantitative, analyzing multiple cases, our study is based on an analysis of a single case study. Overview studies of many cases are still needed, but a larger variety of research designs, and the choice of longitudinal single case study design in particular, could help the CSF field to increase its understanding of CSFs from a “how to apply” CSFs perspective.
Implications of our findings for researchers and practitioners are as follows:
  • Research implications: How to prospectively apply and manage CSFs on different system levels HIS development projects can now be investigated both more holistically and in more detail, at least focusing on how they interact between system levels and CSFs. Furthermore, the used CSFs are overarching and general. Thus, the results have the potential to be useful when studying CSFs in other contexts;
  • Practical implications: Practitioners that address CSFs to improve their HIS projects need to be more aware of how a single CSF is implemented differently on various levels of the HIS project. The descriptions in this study can be used as practical checklists guiding how to realize situational adaptation in HIS projects. Notably, the main takeaway message may be that general CSFs need to be reformulated to more specific factors and measures on different system levels of the innovation. The tables in this paper could function as a rough checklist to raise questions such as “how do we address this CSF at the individual, technology, project and societal levels?”, forcing the project manager and the project team to be very specific, rather than assuming that the CSFs has been addressed when it has been applied at one level.

6. Conclusions

The CSF literature often limits itself to identifying CSFs but seldom explains how they should prospectively be applied and managed. The main contribution of this paper is the rich descriptions of how CSFs prospectively can be applied and managed on various system levels. Three important contributions are as follows:
  • CSFs must be managed and applied differently on various system levels;
  • Interactions between different system levels have been revealed and interactions between CSFs were confirmed;
  • Elaborated and refined formulations of the four CSFs were developed.
The detailed descriptions in Table 5 contribute to further understanding of how to prospectively apply and manage CSFs in HIS projects, the need to include different system levels, but also how the CSFs actually unfold during the whole project and how complex their applications and interactions are. The findings confirm the interactions between CSFs and reveal the interactions between different system levels, which to the best of our knowledge is a perspective that is missing in current CSFs research. This adds a new perspective to existing knowledge which is important to include in future studies.
The findings enriched our understanding and knowledge of the complexity of prospectively applying and managing CSFs in HIS implementations. The findings also enriched our understanding of what the individual CSFs actually are about and also enabled us to elaborate the CSFs formulations into a richer description. The elaborated and refined formulations (Table 5) give a clearer and more comprehensive picture of what CSFs are about and as a result better guidance on how to apply each of the CSFs.
As this research design is based on one case, this single case can be considered a critical case for theory development [51]. Recent studies, e.g., [29,33,34,57] reveal that the CSFs used in RASP still are central and relevant. Since our goal was to understand complex issues in real life and more extensively explain a rather unexplored issue we argue that a single case study was suitable. However, there is a need to carry out further studies, both by quantitative analyses of multiple cases (to investigate whether identified interactions occur across many cases) and qualitative in-depth analysis of single cases (to understand how application differs from one context to another), in order to validate and develop the work further.

7. Suggestions for Future Research

In future research, it would be interesting to further investigate the interactions between CSFs at different system levels (i.e., how a well-defined and accepted objective at the individual, organizational, and project level impacts each other) and between CSFs (i.e., how a well-defined and accepted objective on the individual level impacts involving the right stakeholders at the project and organizational level) in HIS development projects. An interesting question to be studied after that analysis would be how practitioners need to manage the process of addressing multiple CSFs at multiple levels in concert and how champions can be used. The study presented in this paper, showing the manifestation of CSFs at five different system levels in a HIS project, is a first step on the way to such a more thorough analysis and deeper understanding of how to apply multiple CSFs at multiple levels in concert.

Author Contributions

Conceptualization, L.A. and J.v.L.; methodology, L.A., and J.v.L.; formal analysis, L.A. and J.v.L.; investigation, L.A. and J.v.L.; writing—original draft preparation, L.A. and J.v.L.; writing—review and editing, L.A., J.v.L., and A.S.; project administration, L.A. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Data Availability Statement

Restrictions apply to the availability of these data. Data was obtained from VGR and are available from the corresponding author with the permission of VGR.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Lindberg, I.; Lindberg, B.; Söderberg, S. Patients’ and healthcare personnel’s experiences of health coaching with online self-management in the renewing health project. Int. J. Telemed. Appl. 2017, 2017, 9306192. [Google Scholar] [CrossRef] [PubMed]
  2. Gjellebæk, C.; Svensson, A.; Bjørkquist, C.; Fladeby, N.; Grundén, K. Management challenges for future digitalization of healthcare services. Futures 2020, 24, 102636. [Google Scholar] [CrossRef]
  3. Alter, S. Defining Information Systems as Work Systems: Implications for the IS Field. Eur. J. Inf. Syst. 2008, 17, 448–469. [Google Scholar] [CrossRef]
  4. Saxena, D.; McDonagh, J. The Evolving Nature of Information Systems Controls in Healthcare Organisations. Australas. J. Inf. Syst. 2020, 24. [Google Scholar] [CrossRef]
  5. Heeks, R. Health information systems: Failure, success and improvisation. Int. J. Med. Inform. 2006, 75, 125–137. [Google Scholar] [CrossRef] [PubMed]
  6. Aanestad, M.; Vassilakopoulou, P.; Øvrelid, E. Collaborative innovation in healthcare: Boundary resources for peripheral actors. In Proceedings of the International Conference on Information Systems, Munich, Germany, 15–18 December 2019; p. 24. [Google Scholar]
  7. DeSanctis, G.; Poole, M.S. Capturing the complexity in advanced technology use: Adaptive structuration theory. Organ. Sci. 1994, 5, 121–147. [Google Scholar] [CrossRef]
  8. Linnéusson, G.; Andersson, T.; Kjellsdotter, A.; Holm, M. Using systems thinking to increase understanding of the innovation system of healthcare organisations. J. Health Organ. Manag. 2022, 36, 179–195. [Google Scholar] [CrossRef] [PubMed]
  9. Lee, A.S.; Thomas, M.; Baskerville, R.L. Going back to basics in design science: From the information technology artifact to the information systems artifact. Inf. Syst. J. 2014, 25, 5–21. [Google Scholar] [CrossRef]
  10. Flodén, J. Essentials of Information Systems; Studentlitteratur: Lund, Sweden, 2018; ISBN 978-91-44-12348-6. [Google Scholar]
  11. Chaudhry, B.; Wang, J.; Wu, S.; Maglione, M.; Mojica, W.; Roth, E.; Shekelle, P.G. Systematic review: Impact of health information technology on quality. efficiency, and costs of medical care. Ann. Intern. Med. 2006, 144, 742–752. [Google Scholar] [CrossRef]
  12. Svensson, A.; Gustavsson, L.; Svenningsson, I.; Karlsson, C.; Karlsson, T. Healthcare professionals learning when implementing a digital artefact identifying patients’ cognitive impairment. J. Workplace Learn. 2023, 35, 490–505. [Google Scholar] [CrossRef]
  13. Akkermans, H.; van Helden, K. Vicious and virtuous cycles in ERP implementation: A case study of interrelations between critical success factors. Eur. J. Inf. Syst. (EJIS) 2002, 11, 35–46. [Google Scholar] [CrossRef]
  14. Aggestam, L.; Van Laere, J. How to successfully apply critical success factors in healthcare information systems development? A story from the field. In Proceedings of the ECIS 2012 20th European Conference on Information Systems, Barcelona, Spain, 10–13 June 2012; p. 220. [Google Scholar]
  15. Poon, P.; Wagner, C. Critical success factors revisited: Success and failure cases of information systems for senior executives. Decis. Support Syst. 2001, 30, 393–418. [Google Scholar] [CrossRef]
  16. Rockart, J.F. Chief executives define their own data needs. Harv. Bus. Rev. 1979, 57, 81–93. [Google Scholar] [PubMed]
  17. Warren, A.M. Increasing the Value of Research: A Comparison of the Literature on Critical Success Factors for Projects, IT Projects and Enterprise Resource Planning. Systems 2016, 4, 33. [Google Scholar] [CrossRef]
  18. Shaul, L.; Tauber, D. Critical success factors in enterprise resource planning systems: Review of the last decade. ACM Comput. Surv. 2013, 45, 55. [Google Scholar] [CrossRef]
  19. Lameijer, B.A.; Antony, J.; Borgman, H.P.; Linderman, K. Process improvement project failure: A systematic literature review and future research agenda. Int. J. Lean Six Sigma 2022, 13, 8–32. [Google Scholar] [CrossRef]
  20. Rivas, L.; Ganvini, C.; Mendoza, L.E. Critical Success Factors Proposal to Evaluate Conditions for eHealth Services. In Proceedings of the International Conference on Information Technology & Systems, San Carlos, Costa Rica, 9–11 February 2022; Springer: Cham, Switzerland, 2022; pp. 128–139. [Google Scholar]
  21. Remus, U.; Wiener, M. A multi-method, holistic strategy for researching critical success factors in IT projects. Inf. Syst. J. 2010, 20, 25–52. [Google Scholar] [CrossRef]
  22. Esteves, J.; Pastor, J. Organizational and technological critical success factors behavior along the erp implementation phases. In Enterprise Information Systems VI; Seruca, I., Cordeiro, J., Hammoudi, S., Felipe, J., Eds.; Springer: Berlin/Heidelberg, Germany, 2006; pp. 63–71. [Google Scholar]
  23. Denolf, J.M.; Trienekens, J.H.; Wognum, P.; van der Vorst, J.G.; Omta, S. Towards a framework of critical success factors for implementing supply chain information systems. Comput. Ind. 2015, 68, 16–26. [Google Scholar] [CrossRef]
  24. Cyrus, K.M.; Aloini, D.; Karimzadeh, S. How to Disable Mortal Loops of Enterprise Resource Planning (ERP) Implementation: A System Dynamics Analysis. Systems 2018, 6, 3. [Google Scholar] [CrossRef]
  25. Flood, R.L.; Carson, E.R. Dealing with Complexity, 2nd ed.; Plenum Press: New York, NY, USA, 1993. [Google Scholar]
  26. Avison, D.E.; Fitzgerald, G. Information Systems Development: Methodologies, Techniques and Tools, 2nd ed.; McGraw Hill: New York, NY, USA, 1998. [Google Scholar]
  27. Van Gigch, J.P. System Design Modeling and Metamodeling; Plenum Press: New York, NY, USA, 1991. [Google Scholar]
  28. Nembhard, I.M.; Alexander, J.A.; Hoff, T.J.; Ramanujam, R. Why does the quality of health care continue to lag? Insights from management research. Acad. Manag. Perspect. 2009, 23, 24–42. [Google Scholar] [CrossRef]
  29. Juniawan, M.A.; Ashari, N.; Prastiti, R.T.; Inayah, S.; Gunawan, F.; Putra, P.H. Exploring Critical Success Factors for Enterprise Resource Planning Implementation: A Telecommunication Company Viewpoint. In Proceedings of the 2022 1st International Conference on Information System & Information Technology (ICISIT), Virtual, 27–28 July 2022; IEEE: Piscataway, NJ, USA, 2022; pp. 1–6. [Google Scholar]
  30. Aggestam, L. A Framework for Preparation process In Proceedings of the 11th Doctoral Consortium in CAiSE, Riga Technical University, Riga, Lativa, 7–11 June 2004.
  31. Von Würtemberg, L.M.; Franke, U.; Lagerström, R.; Ericsson, E.; Lilliesköld, J. IT project success factors: An experience report. In Proceedings of the 2011 PICMET’11: Technology Management in the Energy Smart World (PICMET), Portland, OR, USA, 31 July–4 August 2011; IEEE: Piscataway, NJ, USA, 2011; pp. 1–10. [Google Scholar]
  32. Nasir, M.H.N.; Sahibuddin, S. Critical success factors for software projects: A comparative study. Sci. Res. Essays 2011, 6, 2174–2186. [Google Scholar]
  33. Fennelly, O.; Cunningham, C.; Grogan, L.; Cronin, H.; O’Shea, C.; Roche, M.; Lawlor, F.; O’Hare, N. Successfully implementing a national electronic health record: A rapid umbrella review. Int. J. Med. Inform. 2020, 144, 104281. [Google Scholar] [CrossRef] [PubMed]
  34. Yaokumah, W.; Omane-Antwi, B.B.; Asante-Offei, K.O. Critical success factors of strategic information systems planning: A Delphi approach. Kybernetes 2023, 52, 1999–2017. [Google Scholar] [CrossRef]
  35. Ewusi-Mensah, K.; Przasnyski, Z.H. Factors contributing to the abandonment of information systems development projects. J. Inf. Technol. 1994, 9, 185–201. [Google Scholar] [CrossRef]
  36. Lyytinen, K.; Roby, D. Learning failure in information systems development. Inf. Syst. J. 1999, 9, 85–101. [Google Scholar] [CrossRef]
  37. Axelsson, K.; Melin, U.; Söderström, F. Analyzing best practice and critical success factors in a health information system case—Are there any shortcuts to successful implementation? In Proceedings of the 19th European Conference on Information Systems (ECIS), Helsinki, Finland, 9–11 June 2011; p. 175. [Google Scholar]
  38. Anantatmula, V.S.; Rad, P.F. Role of organizational project management maturity factors on project success. Eng. Manag. J. 2018, 30, 165–178. [Google Scholar] [CrossRef]
  39. van Laere, J.; Aggestam, L. Understanding champion behaviour in a health-care information system development project–how multiple champions and champion behaviours build a coherent whole. Eur. J. Inf. Syst. (EJIS) 2016, 25, 47–63. [Google Scholar] [CrossRef]
  40. Barlow, H.A.; Burke, M.E. The organisation as an information system: Signpost for new investigations. East Eur. Q. 1999, 4, 549–557. [Google Scholar]
  41. Milis, K.; Mercken, R. Success factors regarding the implementation of ICT investment projects. Int. J. Prod. Econ. 2002, 80, 105–117. [Google Scholar] [CrossRef]
  42. Pun, K.-F. Cultural influences on total quality management adoption in Chinese enterprise: An empirical study. Total Qual. Manag. 2001, 12, 323–342. [Google Scholar] [CrossRef]
  43. Markus, M.L.; Robey, D. The organisational validity of management information systems. Hum. Relat. 1983, 36, 203–226. [Google Scholar] [CrossRef]
  44. Cherry, C.; Macredie, R.D. The Importance of Context in Information System Design: An assessment of Participatory Design. Requir. Eng. 1999, 4, 103–114. [Google Scholar] [CrossRef]
  45. Browne, G.J.; Ramesh, V. Improving information requirements determination: A cognitive perspective. Inf. Manag. 2002, 38, 625–645. [Google Scholar] [CrossRef]
  46. Saiedian, H.; Dale, R. Requirements engineering: Making the connection between the software developer and customer. Inf. Softw. Technol. 2000, 42, 419–428. [Google Scholar] [CrossRef]
  47. Mingers, J.; White, L. A review of the recent contribution of systems thinking to operational research and management science. Eur. J. Oper. Res. 2010, 207, 1147–1161. [Google Scholar] [CrossRef]
  48. Ji, B.; Liu, Y.; Jin, Z. An evaluation of the design and construction of energy management platform for public buildings based on WSR system approach. Kybernetes 2018, 47, 1549–1568. [Google Scholar] [CrossRef]
  49. Eisenhardt, K.M.; Graebner, M.E. Theory Building from Cases: Opportunities and Challenges. Acad. Manag. J. 2007, 50, 25–32. [Google Scholar] [CrossRef]
  50. Yin, R.K. Case Study Research: Design and Methods; Sage: London, UK, 2014. [Google Scholar]
  51. Flyvbjerg, B. Five misunderstandings about case-study research. Qual. Inq. 2006, 12, 219–245. [Google Scholar] [CrossRef]
  52. Lindgren, R.; Henfridsson, O.; Schultze, U. Design Principles for Competence Management Systems: A Synthesis of An Action Research Study. MIS Q. 2004, 28, 435–472. [Google Scholar] [CrossRef]
  53. Louis, M.R.; Bartunek, J.M. Insider/Outsider Research Teams: Collaboration Across Diverse Perspectives. J. Manag. Inq. 1992, 1, 101–110. [Google Scholar] [CrossRef]
  54. McGrath, R. Reflections on Russell Ackoff’s Legacy in the Centenary Year of His Birth. Prod. Oper. Manag. 2019, 28, 2162–2164. [Google Scholar] [CrossRef]
  55. Braun, V.; Clarke, V. Using thematic analysis in psychology. Qual. Res. Psychol. 2006, 3, 77–101. [Google Scholar] [CrossRef]
  56. Schein, E.H. Organizational Culture and Leadership, 3rd ed.; John Wiley & Sons, Inc.: Hoboken, NJ, USA, 2004; ISBN 0-7879-6845-5. [Google Scholar]
  57. Leyh, C.; Sander, P. Critical Success Factors for ERP System Implementation Projects-An Update of Literature Reviews. In Proceedings of the Enterprise Systems-Strategic, Organizational and Technological Dimensions (Lecture Notes in Business Information Processing, LNBIP, St. Louis, MO, USA, 12 December 2010; Sedera, D., Gronau, N., Sumner, M., Eds.; Springer International Publishing: Cham, Switzerland, 2015; Volume 198, pp. 45–67. [Google Scholar]
Figure 1. System levels where the CSFs were observed.
Figure 1. System levels where the CSFs were observed.
Systems 11 00469 g001
Figure 2. How the relation between the local and national level was communicated.
Figure 2. How the relation between the local and national level was communicated.
Systems 11 00469 g002
Table 1. CSF1 applied and managed on different system levels.
Table 1. CSF1 applied and managed on different system levels.
System LevelCSF1: to Learn from Earlier Projects, Both Successful and Failed Ones
IndividualIndividuals are carriers of organizational culture and of lessons learned from earlier projects. Individual learning is the foundation for everything. Key individuals are as ambassadors crucial in communicating what has been learned, connecting to their earlier experiences, and explaining how lessons learned impact the design of the current project. To develop an individual understanding of what will be done differently this time is critical.
TechnologyThe project is redefined as a work process development project rather than a technology project, but integration of technology in the work process requires that the role of technology is addressed explicitly
ProjectLearning from earlier projects needs to include both positive and negative experiences. It is important that lessons learned not only create understanding but also result in clear and visible alternative designs and actions in the coming project. The main differences must be communicated in a structured way.
OrganizationAnalyzing many earlier projects over time reveals organizational factors that impact development projects. The complexity of VGR required the development of a participatory structure that dealt with anchoring and creating support at all levels, departments, and roles.
SocietalThe inertia of national standards hampered innovation and could lead to dissatisfaction with project results. Participants needed to become aware of the benefits of standards and inertia, as well as means of how the national level could be influenced in case of major issues
Table 2. CSF2 applied and managed on different system levels.
Table 2. CSF2 applied and managed on different system levels.
System LevelCSF2: DEFINING Boundaries and Relations
IndividualThe individual project manager must understand and communicate the project’s role in the big picture. The challenge is to select individuals (project managers and members) who demonstrate the ability to clearly articulate the role of technology in the project and the contribution of the project to the larger organization.
TechnologyThe role of technology is explicitly visualized by incorporating technology as one subsystem in the larger system. Discern between information flows and work processes, as technology supports information flows. Use the swimlane technique where data stored in technological applications is one swimlane.
ProjectFrom a holistic perspective, the scope of the project has to be articulated unequivocally. Boundaries of the project, and more importantly relations with and forces from the surrounding organization need to be explored, defined, and maintained over time. Map what benefits are produced for whom and clarify the project’s role in the larger whole. General CSFs need to be translated into project-specific ways of working.
OrganizationPlace the project in that organizational unit that corresponds to the aim of the project. Analyzing the organizational culture and informal decision-making processes, will also contribute to knowing what champions to involve and how to select a project manager. Analyze parallel projects, governing policies, and documents to know how they will impact the project and whether the project result is according to them, if they need to be adapted, and/or how the project can influence other projects.
SocietalMap how the project is related to national guidelines and other national innovation initiatives. Relations need to be actively managed, i.e., national decisions influence us but we can also influence them
Table 3. CSF3 applied and managed on different system levels.
Table 3. CSF3 applied and managed on different system levels.
System LevelCSF3: A Well-Defined and Accepted Objective
IndividualAn accepted objective requires that each individual is involved in creating the objective so it becomes a shared objective. An emotional appeal is important and can be done by communicating the objective with examples that affect it.
TechnologyThe contribution of technology support must be explicitly connected to the overall objective.
ProjectThe project objective must be clearly linked to organizational objectives and unified stakeholder interests. Informal anchoring before formal meetings contributes to acceptance of the objective and the participative way of working. Progress towards the objective should be continuously communicated.
OrganizationThe objective needs to be accepted by all stakeholders in the different parts of the organization. Therefore, it is important to translate the general overall objective to what it actually means for different parts of the organization. It is also critical, not at least from an acceptance perspective, that the objective is formulated and communicated on a “what” level, whereas the respective departments have the freedom to fill in the “how”.
SocietalIt is critical that the objective should not be in conflict with existing governing policies and should be in line with other strategic development projects and the overall direction for innovation.
Table 4. CSF4 applied and managed on different system levels.
Table 4. CSF4 applied and managed on different system levels.
System LevelCSF4: Involve the Right Stakeholders
IndividualA project needs to select and attract a number of individuals who will serve as champions for the project and will help to remove obstacles of different kinds at different levels.
TechnologySome of the stakeholders need to serve as a mediator that can build bridges between technological departments and business units.
ProjectThe project team members need to have different backgrounds, affiliations, and competencies that complement each other and that mirror the different stakeholder groups. The project needs an infrastructure that guides and enables interaction between the multiple identified stakeholder groups.
OrganizationStakeholder representatives need to cover all the different stakeholder groups and interests at different parts and levels in the organization. The commitment of all these groups needs to be managed and maintained continuously throughout the whole project.
SocietalIn order to represent the project’s interests, both sharing knowledge developed in the project and keeping the project and the involved organizations updated, representatives from the project need to participate in other projects that have been defined as critical.
Table 5. Elaborated and refined formulation for each CSF.
Table 5. Elaborated and refined formulation for each CSF.
CSFOrigin FormulationElaborated Formulation
CSF1To learn from failed projectsTo understand the culture and to learn from earlier projects, both successful and failed ones, and clearly communicate how these lessons learned are addressed in the current project
CSF2To define the system’s boundary, for the whole system and for relevant subsystems:To have a holistic approach and to understand systems complexity, i.e., looking at an ISD project based on its role in the “big picture”, including defining the system’s scope and the important system elements, managing relations between system elements and relations with the environment, and paying attention to needed resources and potential risks
CSF3To have a well-defined and accepted objective aligned with the business objectivesTo have well-defined and accepted objectives, on the three levels of inquiry [27], where the why level includes the top management support and the how level can be compared with having an accepted working approach and decision-making processes, as well as having an acceptance of the forthcoming result and how to test it, measure it and follow it up
CSF4To involve, motivate, and prepare the “right” stakeholdersTo involve, motivate, and prepare the “right” stakeholders and develop their roles, including building the “right” team, also from champion behavior and change management perspective. This includes selecting and attracting a number of champions that will serve as sponsors for the project and will help to remove obstacles of different kinds at different levels.
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Aggestam, L.; van Laere, J.; Svensson, A. How to Apply and Manage Critical Success Factors in Healthcare Information Systems Development? Systems 2023, 11, 469. https://doi.org/10.3390/systems11090469

AMA Style

Aggestam L, van Laere J, Svensson A. How to Apply and Manage Critical Success Factors in Healthcare Information Systems Development? Systems. 2023; 11(9):469. https://doi.org/10.3390/systems11090469

Chicago/Turabian Style

Aggestam, Lena, Joeri van Laere, and Ann Svensson. 2023. "How to Apply and Manage Critical Success Factors in Healthcare Information Systems Development?" Systems 11, no. 9: 469. https://doi.org/10.3390/systems11090469

APA Style

Aggestam, L., van Laere, J., & Svensson, A. (2023). How to Apply and Manage Critical Success Factors in Healthcare Information Systems Development? Systems, 11(9), 469. https://doi.org/10.3390/systems11090469

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop