Paper title (Paper Title style) Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 1 The Evolving Nature of Information Systems Controls in Healthcare Organisations: The Case of a Blood Banking Enterprise System from Western Europe Deepak Saxena Trinity Business School, Trinity College Dublin Ireland saxenad@tcd.ie Joe McDonagh Trinity Business School, Trinity College Dublin Ireland Abstract Information Systems (IS) projects are found to be complex, unpredictable, and prone to time and cost overruns. Perhaps that is why organisations put a strong focus on IS controls during the planning and execution of such projects. IS control literature in the past has focussed on dyadic control relationships during an outsourced IS development project and relatively little is known about such controls during a complex enterprise systems project. Existing studies usually take a static view of IS controls and do not investigate how controls evolve during different phases of the system lifecycle, as well as across projects. This study presents a processual view of IS controls in the enterprise systems lifecycle in a national blood processing organisation. Traditional research in a blood banking context has focussed on optimising the process of blood collection, inventory management, and distribution with relatively limited attention to the implementation of the supporting information systems. This research focusses on the evolution of control based on a study of three enterprise system implementation projects in the case organisation. The study demonstrates that while all five control modes (input, outcome, behaviour, clan, and self-control) are applied across the phases of enterprise systems projects, the nature and extent of control mechanisms changes across the phases of the enterprise system lifecycle. The findings also suggest a teleological evolution of a project’s control portfolio in which the portfolio evolves based on adaptive learning processes from earlier projects. Finally, by exhibiting the influence of institutional and market context, this study also underlines the multi-stakeholder and contextual nature of enterprise systems implementation and associated controls in health service organisations. Keywords: IS Control, Enterprise systems, Formal control, Informal control, Control Evolution 1 Introduction Information systems (IS) projects are usually complex, unpredictable, and are prone to time and cost overruns (Bhoola, Hiremath, & Mallik, 2014). Moreover, evidence suggests that context plays a major role in the planning, procurement, and implementation of IS projects (Berente, Lyytinen, Yoo, & Maurer, 2019; Matinheikki, Aaltonen, & Walker, 2019; Moe, Newman, & Sein, 2017). This is especially true for healthcare organisations where complex institutional logics (e.g. medical, managerial, public service, and market) may be at work (Bunduchi, Tursunbayeva, & Pagliari, 2020; Poba-Nzaou, Uwizeyemungu, Raymond, & Paré, Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 2 2014; Salge, Kohli, & Barrett, 2015). Perhaps that is why organisations put a strong focus on IS controls during the planning and execution of complex IS projects. Information systems controls may be defined as a set of activities that are conducted in a project to moderate the behaviour of project participants and to ensure that their skills and capabilities are applied towards successful project completion (Kirsch, 1997, 2004). Traditionally, IS control literature has focussed on dyadic control relationships during outsourced IS projects (Choudhury & Sabherwal, 2003; Gopal & Gosain, 2010; Heiskanen, Newman, & Eklin, 2008) and relatively little is known about such controls during a complex enterprise systems project (Cram, Brohman, & Gallupe, 2016; Inácio & Marques, 2018). Existing studies usually take a static view of IS controls (Wiener, Mähring, Remus, & Saunders, 2016) and do not investigate how controls evolve during different phases of the system lifecycle, as well as across projects. Moreover, there is limited research on the influence of institutional context on IS controls, including in the healthcare setting. Against this theoretical backdrop, this study presents a dynamic and contextual view of IS controls during an enterprise system implementation by conducting a processual case study (Langley, Smallman, Tsoukas, Van de Ven, 2013; Niederman, Müller, & March, 2018; Pettigrew, 2012) of the system lifecycle in a national blood banking context. The research question for this study was – How does an IS control portfolio evolve during an enterprise system implementation project in a blood banking organisation? By way of supporting this question, this paper is organised as follows. Section 2 presents a brief discussion on blood banking as a research context and reviews the literature on IS controls. Section 3 justifies and outlines the case research methodology used in the study. The case narrative is presented in section 4, followed by findings and discussion in section 5. The concluding section discusses the key contributions, implications, and limitations of this study. 2 Literature Review 2.1 IS Control modes and control portfolio Traditional discussion on control theory in IS projects divides IS controls into two modes (Kirsch, 1997; Susilo, Heales, & Rohde, 2007; Wiener et al., 2016) – formal and informal. Figure 1 shows various formal and information controls with some (non-exhaustive) examples in the adjacent box. Formal controls are mostly bureaucratic in nature (Ouchi, 1979, 1980; Gregory & Keil, 2014) and are driven by organisational rules and procedures. In contrast, informal controls are social in nature (Ouchi, 1979, 1980; Chua, Lim, Soh, & Sia, 2012; Chua & Myres, 2018) and are driven by prevalent norms and practices. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 3 Figure 1. IS Control Modes (Adopted from Wiener et al., 2016) Within formal controls, while the outcome control is focussed on ensuring that pre-determined outcomes are achieved, behaviour control is focused on aligning the controlee’s behaviour towards accepted standards (Ouchi, 1978; Kirsch, 1997). The example of outcome control in IS projects could be software requirement specifications and delivery milestones. Behaviour controls may include regular meetings and production of status reports. Wiener et al. (2016) also add input control to the list of formal control modes. Input control primarily includes resource allocation (e.g. manpower, funding, infrastructure, and training) available for the project. Within informal controls, clan control and self-control are identified as predominant control modes. Clan control relies on the social capital (Chua et al., 2012) for the emergence of shared norms and practices outside formal controls. This could be done, for instance, via away-days or weekly lunches (Wiener et al., 2016) so that a collective sense of project ownership and responsibility (Wiedermann & Wiesche, 2018) is developed. Self-control, as the name suggests, is more individual in nature relying on self-monitoring and regulation (Kirsch & Cumming, 1996). While organisations primarily apply formal controls in IS projects (Henderson & Lee, 1992; Choudhury & Sabherwal, 2003; Tiwana & Keil, 2009; Wiener, Remus, Heumann, & Mähring, 2015; Wiener, Cram, & Remus, 2017), informal controls may be highly useful in low- maturity environments (Mao, Zhang, & Song, 2008) or where project leaders have considerable domain experience (Kirsch & Cumming, 1996). 2.2 Dynamic nature of control portfolio It is crucial to note that the control modes are not applied in isolation, and a control portfolio (Kirsch, 1997, 2004; Choudhury & Sabherwal, 2003; Soh, Chua, & Singh, 2011; Murungi, Wiener, & Marabelli, 2019) is often used in IS projects. This is usually done to make use of control complementarity (Grabski & Leech, 2007; Srivastava & Tao, 2012) and control ambidexterity (Gregory & Keil, 2014). While initial research largely presents a static view of a project’s control portfolio, subsequent research notes its dynamic nature. For instance, studies (Choudhury & Sabherwal, 2003; Susilo et al., 2007) report that while IS projects in the beginning typically rely on outcome-based controls, behaviour control mechanisms are often added at later stages of the project. This reflects a lifecycle (Van de Ven & Poole, 1995; Van de Ven & Sun, 2011) based assumption that each phase of the IS project exhibits certain Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 4 characteristics, and a certain configuration of a project’s control portfolio is required for each phase (Nuwangi & Sedera, 2018). An alternative conception of a project’s control portfolio relies on a teleological mechanism (Van de Ven & Poole, 1995) arguing that the organisation adopts the use of control modes based on the learnings gained during the process. For instance, organisations may not have sufficient clarity on deliverables in the beginning and would increase control to maximise the benefits (Heiskanen et al., 2008) at a later stage. Conversely, as the understanding between the client and the vendor increases, the organisation may decide to employ more trust-based controls (Gregory, Beck, & Keil, 2013). Extending this view, recent studies (Chua & Myres, 2018; Murungi et al., 2019) offer a social perspective that views controls as a negotiated order between parties. 2.3 Gaps in existing research Barring some exceptions (e.g. Soh et al., 2011), IS control literature traditionally focusses on the control portfolio for system development projects (Choudhury & Sabherwal, 2003; Heiskanen et al., 2008; Mao et al., 2008) between two parties. This results in a number of limitations. First, we have limited empirical evidence on the control mechanisms during a project where an off-the-shelf solution such as an enterprise system (Cram et al., 2016; Inácio & Marques, 2018) is being implemented. Second, the controller-controlee relationships are often conceived in terms of simple dyads (Kirsch, 2004) such as business-IS or client-vendor. Consequently, it is sometimes ignored that projects may have multiple levels of controllers and their respective controlees (Soh et al., 2011) or sometimes a controlee may have multiple controllers (Nuwangi, Sedera, & Srivastava, 2018). Consequently, different control modes may be effective at different levels. For instance, Ouchi (1978) notes that while outcome controls are easily transmitted across vertical hierarchy, different levels of the hierarchy may rely on different behaviour controls. Finally, since such studies conduct a cross-sectional analysis or focus on a single project at a single instance, there is no appreciation of the historical context (Chua & Myres, 2018) in the evolution of control modes across multiple projects is an organisation. This study aims to address these limitations by conducting a processual case study (Langley et al., 2013; Niederman et al., 2018; Pettigrew, 2012) of IS controls during three instances of an enterprise system implementation in a national blood banking organisation from Western Europe. A blood bank organisation was deemed an exemplary case (Yin, 2017) for this study since the level of controls are generally very high in the healthcare sector. A high level of control is also necessitated since software solutions for blood banks are much less standardised due to the niche nature of business processes followed across the globe. The next section introduces blood banking as a research context. 2.4 Blood banking as a research context Blood transfusion is a crucial and integral element of medical practice. It is the process through which blood cells of a donor are transferred to the recipient after careful testing and cross- matching. Blood transfusion may be required in cases where the patient has lost significant amounts of blood due to an accident or during a surgery. Thus, hospitals and clinical practices need to have an adequate supply of blood to ensure patient safety. Quite often collection and transfusion are conducted by separate entities – the former by a regional blood bank, and the latter by hospitals. Figure 2 shows the typical stages in the blood supply chain. While hospitals Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 5 store blood in a small blood bank for emergency and planned use, a major part of blood operations is covered by regional blood banks. The case organisation in this study is one such regional blood bank covering blood processing and supply in a Western European nation. Figure 2. Typical stages in the blood supply chain. In modern medicine, blood transfusion usually involves transfusing only the specific cells (e.g. red blood cells, white blood cells, platelets, or plasma) rather than transfusing whole blood. Hence, regional blood centres need to process and test individual components to ensure timely delivery and patient safety. At the same time, blood and blood components are perishable (see Table 1) and hence the collection and processing need to be optimised to minimise wastage. Responding to the peculiar nature of blood products, past research has focussed on optimising the collection planning (Alfonso, Xie, Augusto, & Garraud, 2012; Cumming, Kendall, Pegels, Seagle, & Shubsda, 1976), inventory management (Kendall & Lee, 1980) at the regional blood centre, and ordering policies in hospital (Katsaliaki & Brailsford, 2007) using modelling and simulation. Component Shelf Life Whole blood 21-35 days Red blood cells 35 days (14 days for irradiated/washed cells) White blood cells 24 hours Platelets 5-7 days Plasma (frozen) 36 months Table 1. Key Blood Components and Shelf Life (Source: JPAC, 2013) Apart from safe processing and timely delivery of the physical product, a key informational requirement for blood operations is traceability. The European Directorate for the Quality of Medicines & Healthcare (EDQM, 2017) defines traceability as “the ability to trace in all directions each individual unit of blood or the blood components derived from it from the donor to its final destination, whether this is a patient, a manufacturer of medicinal products or its disposal” (p. 218). An audit trail and lookback provision are considered essential for blood banks (Ashford et al., 2000) to ensure patient safety in situations such as a recall due to unforeseen circumstances. For this reason, implementation of Blood Enterprise Systems (BES) is often recommended to provide end-to-end connectivity for blood bank information processes (EDQM, 2017; JPAC, 2013). Such BES also need to have an interface with the testing equipment to facilitate automated transfer of results to the system (Li, Chao, & Dong, 2007) in order to avoid human errors in entering data (Gupta, Priyadarshini, Massoud, & Agrawal, 2004). Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 6 However, while the general enterprise system market benefits from the incorporation of best practices into the software, the BES software industry has much to do in this regard despite numerous directives and suggested protocols (for instance, ISBT 128 for the labelling of blood products). Due to historical evolution and regulation diversity, different blood banks follow slightly different practices. As a result, the BES market is replete with small players catering to their niche markets and none of the big players (e.g. SAP, Oracle, or Microsoft) from the wider enterprise system market provide a specific solution tailored to blood banks. In addition to the health and safety concerns, the inconsistency across various BES is a crucial reason for tighter controls when implementing a solution. Therefore, a blood bank context was considered an exemplary context (Yin, 2017) to study the evolution of IS controls. 3 Research Methodology 3.1 Processual case study This study focussed on answering the following research question: How does an IS control portfolio evolve during an enterprise system implementation project in a blood banking organisation? Since the research question is of ‘how’ type, and the research was being conducted in the real- world context, a case study (Yin, 2017; Murungi et al., 2019) approach was considered appropriate. This is in line with established practice where a case study approach is a widely used research method in IS research (Mazaheri, Lagzian, & Hemmat, 2020) as well as in enterprise systems research (Saxena & McDonagh, 2017). Moreover, since the research question focusses on the ‘evolution’ of IS control, a longitudinal case study with a processual focus (Langley et al., 2013; Pettigrew, 2012) was deemed relevant. A processual study allows the researcher to trace events (George & Bennett, 2005) over time and observe patterns across process instances (Langley et al., 2013; Pettigrew, 2012) to identify the mechanism underpinning the process. Finally, since the research question was framed for a specific context (blood bank), processual case study was adopted as it helps in developing a contextual explanation (Avgerou, 2019) based on a situated understanding (Maxwell, 2017) of specific events. Thus, a longitudinal qualitative case study approach with a processual lens (Niederman et al., 2018) was adopted to gain an understanding of the evolution in the control portfolio in the case organisation. At the global level, the blood bank market is often classified in terms of geographical coverage with North America, Europe, Asia-Pacific, and LAMEA (Latin America, Middle East and Africa) as major regions. Within Europe, the market is further classified into Germany, France, the UK, and rest of Europe (Pandey & Sumant, 2020). The case organisation in this study belongs to a nation from the rest of Europe. National Blood Processing Services (NBPS, a pseudonym) is an autonomous public body engaged in the collection, processing and distribution of blood and related products in the country. While NBPS is an autonomous agency in its day to day operations, it needs the endorsement of its parent Government Department (mentioned as Department for the remainder of the paper) for strategic investments. The agency engaged in three instances of BES implementation during 2000-2017. Considering the level of controls applied in blood bank operations, NBPS was considered an exemplary case (Yin, 2017) to study the evolution of IS controls within and across three BES projects in NBPS. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 7 3.2 Data collection Data collection started with the collection and analysis of secondary data. Table 2 shows the secondary data collected and used in the study. It may be noted the secondary data from outside the organisation was also collected, thereby avoiding a ‘container’ approach (Winter, Berente, Howison, & Butler, 2014). Analysis of secondary data helped in deriving the sequence of events and in identifying key stakeholders for primary data collection. Secondary Data Number of documents Source NBPS annual reports (2001-2017) 17 NBPS website NBPS board minutes (2002-2017) 153 NBPS website NBPS strategic plans (2005-2009, 2010-2012, 2013-2016) 3 NBPS website Newspaper reports 10 News websites Internal project documents (including internal audit) 27 NBPS project team Reports of the public auditor 3 Public auditor website Debate of the parliamentary committee 2 Parliament website Other government reports and circulars 10 Government websites Table 2. Secondary data collected in the study Primary data collection mainly consisted of in-depth qualitative interviews with the participants from the case organisation. To ensure internal validity (Maxwell, 2017), the participants from top management, the implementation team, and user groups were interviewed. Table 3 presents the interview participants’ profile. Participant’s Primary Affiliation No. of Participants Top Management Team Members 6 IT Team (including Project Manager and Super-users) 8 Members of User Groups 11 Total 25 Table 3. Details of Interview Participants Interviews were conducted by the first author in the organisation’s premises to allow for a natural interview setting (Langley & Meziani, 2020). In the paper, respondents are referred to as R1, R2, R3 etc. to ensure anonymity. In total, twenty-seven interviews were conducted with twenty-five participants (one interview had two participants, three participants were interviewed twice). All but three interviews were recorded and transcribed verbatim by the researcher. The three interviews for which recording was not permitted, detailed notes were taken, and the interview was transcribed on the same day based on the notes and memory. Once the transcription was completed, detailed case analysis was conducted as outlined in the next section. 3.3 Case analysis Case analysis was a combination of narrative analysis and qualitative coding. The case narrative was written in the form of process tracing (George & Bennett, 2005) with a focus on the sequence of events. The narrative was used not just as a description tool, but also as an analytical tool (Pentland, 1999) to identify deep structures underpinning the sequence of events. For analytical purpose, the narrative was divided using the strategy of temporal Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 8 bracketing (Langley et al., 2013; Pettigrew, 2012) in which the sequence of events is analysed in temporal blocks of each implementation cycle. The case narrative is presented in section four. This was followed by a three-stage qualitative coding exercise (Miles, Huberman & Saldana, 2014) for data reduction and identification of themes. All interview transcripts and minutes of the meetings were uploaded to the software QDA Miner Lite. In the first stage, text blocks were assigned a short phrase indicating the nature of the block. This resulted in 128 first-level codes. In the second stage, the first-level codes were amalgamated based on similarity in their nature. This resulted in nineteen second-level codes. Most of the codes corresponded to the examples of various controls (e.g. review and audit, professional norms) noted during the literature review. Finally, all second-order codes were assigned to one of the control categories – behavioural, outcome, input, clan and self-control. Appendix 1 presents the coding tree generated during the analysis. Once the coding was complete, the narrative helped in identifying the prevalence of specific control modes during the pre-implementation, implementation, and post-implementation phases of the enterprise systems project. Since the case covers three instances of the BES project, one could also observe the evolution of control modes across the three project implementations. The case analysis and discussion are presented in section five. 4 Case Narrative Figure 3 shows the timeline of the three BES projects in National Blood Processing Service (NBPS). Following the strategy of temporal bracketing (Langley, 1999; Langley et al., 2013), this section presents the narrative by highlighting key events during the three projects. Blood Enterprise System-I (BES-I) project was conceived in 1998 and completed in 2003. Blood Enterprise Systems-II (BES-II) was an upgrade of BES-I that started in 2004 but was abandoned in 2007 due to consistent problems. After a few years’ gap, NBPS engaged in a full-suite Blood Enterprise System-III (BES-III) implementation that started in 2011 and completed in 2017. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 9 Figure 3. Timeline of BES Projects in NBPS 4.1 Blood Enterprise System-I (1998-2003) National Blood Processing Service approached its parent Department in 1998 with the concern that its existing system was not ready for the Year 2000 problem and proposed the implementation of a new BES. Considering the gravity of the problem, the Department agreed Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 10 to support the enterprise system implementation. Once the proposal was approved by the Department, NBPS published an open tender for the procurement and implementation of the BES. However, the public tender had a very limited response due to the niche nature of the blood bank market and only two suppliers were shortlisted for consideration. One supplier was based in the US and offered two separate systems to manage the donor side and the processing side. The other supplier offered an integrated system and was the market leader with its clients across Europe. The contract was awarded to the second supplier (referred to as the vendor for the remainder of the paper). The implementation started around 1998 and was due to finish by late 1999 at a cost of around €4.3 million. The implementation was managed by a project manager who came from a medical background. He was assisted by a number of superusers who were in-house domain experts. The superusers were instrumental in testing and adapting the system to suit the operational needs of NBPS. The project manager and the superusers worked in close proximity with the Information Technology (IT) unit. The IT unit was responsible for ensuring that the infrastructure was of the required standard and that all technological requirements were in place for the system. The project was overseen by a steering committee which included NBPS top management and the head of IT. After resolving a number of technical and organisational issues, BES-I finally went live during early 2003 (i.e. a delay of more than three years) with an estimated cost of €9.3 million (i.e. more than double the estimated budget). In the interim, an audit was conducted by the public auditor in 2002 due to the cost and time overrun, which was subsequently debated in the parliamentary committee of public accounts in 2003. 4.2 Blood Enterprise System-II (2004-07) Since BES-I implementation took longer than expected, NBPS leadership contemplated and initiated the implementation of BES-II, an upgraded system from the same vendor. While the former was a file-based database system with limited reporting capabilities, the latter was based on a relational database system with more reporting potential. The organisation remained with the same vendor as there was not much change in the blood bank market since the tender evaluation for the first project. They also cite a benchmarking exercise conducted by another European blood service examining all possible systems at the time and still going with the same vendor. Thus, NBPS did not feel the need to go for a public tendering for BES- II. The business case for BES-II implementation was drawn up in May 2004. The business case explained the rationale for moving from BES-I to BES-II. It was written by the IT unit outlining various requirements for the implementation of BES-II. A steering committee was established to monitor the project, and to make timely decisions on relevant issues. In October 2004, the vendor sent an official proposal which was accepted by the steering committee. However, BES-II implementation consistently faced obstacles during the testing and validation for the next two years. There were considerable issues with the system and the system never went beyond testing and validation. Finally, the steering committee decided to abandon the project in the beginning of 2007. Since NBPS incurred considerable expenditure on the project, there was another public audit and a parliamentary committee debate in 2008. While the public auditor noted in its report that value for money was not achieved during BES-II implementation, it also commended NBPS for its ‘exacting testing standards’ that led to the suspension of the project. In view of the implementation failure, NBPS decided to move BES-I to the new hardware that was purchased for BES-II. The project was subject to standard testing and validation procedures and completed in 2008. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 11 Once BES-II was abandoned, NBPS sought to improve the functionality of BES-I. Since it had limited reporting capabilities, NBPS decided to implement a reporting module in late 2007. The reporting module, developed by the New York Blood Bank, fetched data from BES-I and produced the reports. The project was completed towards the end of 2009. Around 2011, NBPS undertook the development of a web-based electronic ordering system to receive online orders from the hospitals, thereby intending to replace the manual, telephone-based ordering process. The project was conceived by the head of operations within NBPS with IT unit developing the solution. By May 2011, the pilot testing of the system with a nearby hospital was completed and modifications were done in the software based on feedback received from the pilot test site. By March 2012, the electronic ordering system was live in every hospital in the country. 4.3 Blood Enterprise System-III (2011-17) At the same time, however, BES-I software was approaching the end of its lifecycle and NBPS recognised the need for a new system. Subsequently, NBPS approached its parent Department with a proposal to implement a new BES. However, since the government was tightening its purse in the wake of global recession, the Department vetoed the project at the beginning. The logjam with the Department continued for a few months when NBPS kept trying to convince the Department and Department kept vetoing the implementation. Ultimately, NBPS stressed that the timelines on support for existing hardware and software were finite and it would take some time to procure new hardware and to implement new software. This arguably posed a huge risk to the blood supply system if the existing system went down at some point in time. Eventually, the Department relented and approved the project. Along with the approval, they recommended the establishment of the Peer Review Group (PRG) to provide external project oversight. The PRG consisted one member from the Department, one member from a large government health agency, and one external expert. Once PRG was formed, NBPS prepared a requirement specification document and a tender was published before Christmas 2011. The tender document sought integration of the entire blood and tissue operations within NBPS, including reporting. This time as well, NBPS received only two responses – one from the existing vendor (who had now purchased the reporting tool from the New York Blood Bank) and another vendor from the UK. After tender evaluation, NBPS decided to implement an integrated product suite (BES-III) from the existing vendor. An extensive governance mechanism was put in place during 2011-12. This time NBPS also included a vendor representative in the steering committee with a view to support high-level coordination with the vendor. The implementation team was led by a project sponsor and a dedicated project manager. The project was divided into different work-streams according to the business processes and the functionality of the software. Each work-stream was led by a key business user assisted by system superusers. In other words, it followed a structure similar to earlier projects, but in a more extensive manner. During BES-III implementation, NBPS also used the services of an external auditor from the private sector for a two-part review of the project. The two reviews were respectively completed in the latter half of 2013 and 2014. Cognizant of the cost overruns in previous projects, NBPS also made sure that project expenditure was regularly examined by the finance committee of the organisation. At the start of 2014, the finance committee noticed that vendor invoices consistently got delayed and did not properly reflect the content and amount of work. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 12 The negotiations with the vendor finally concluded in June 2014 and the final agreement was subsequently endorsed by the finance committee. Two smaller modules (one on the tracing of blood requests, the other a risk management module on nonconforming cases) went live in the first half of 2014. The core BES-III module (centred on blood processing) was scheduled to go-live in the fourth quarter of 2014. However, the implementation got consistently delayed due to technical and change management issues, finally going live in September 2015. This was followed by resolution of reporting and performance issues in 2016. Finally, the last module for BES-III, a module for managing the information on tissue banking, went live in 2017. While BES-III project had some time and budget overrun, it was deemed at an acceptable level and did not invite any additional scrutiny, much to the relief of NBPS. 5 Analysis and Discussion The case analysis primarily involved identification of patterns (Langley et al., 2013; Pettigrew, 2012) across the three implementations and identification of the evolution of an IS control portfolio in National Blood Processing Organisation (NBPS). The case analysis is presented using the enterprise system lifecycle model consisting of three phases (Ali & Miller, 2017) – pre-implementation, implementation, and post-implementation. As shown in Table 4, while all phases use each of the five control modes, the precise control mechanisms and the control portfolio evolve throughout the enterprise system project peaking during the implementation phase. Moreover, the nature and extent of control also evolves across multiple projects in an organisation. Pre-implementation Implementation Post-implementation Input Resource allocation, Market control User training Market control Outcome Business case Requirement specifications, testing and validation, project plan Testing and validation Behaviour Administrative controls Steering group, Financial oversight, Project communication, Audit and review Audit and review, Change control Clan Professional norms (Health) Professional norms (Health/IT) Professional norms (Health) Self-control Individual initiative (top leadership) Individual initiative (project team) Individual initiative (management) Table 4. Control portfolio during enterprise system projects 5.1 Input Control The pre-implementation phase of BES projects is marked by input controls in the form of resource allocation and market control. The main input control (Wiener et al., 2016, 2017) for all three projects was mainly in terms of resource allocation. While the project managers for BES-I and BES-III came from business, the project manager of BES-II was from the IT department. The findings support the long-standing recommendation (Adam & O’Doharty, 2000) that project leadership and control should remain outside the IT unit, preferably with the senior managers (Bernroider, 2013; Sumner, 2018) from the business. Keeping the project Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 13 leadership with the business helps in ensuring the system-business fit and in institutionalising the implementation process within the organisation. As far as superusers are concerned, selection of domain experts as superusers (Obwegeser, Danielsen, Hansen, Helt & Nielsen, 2019; Sumner, 2018) worked for NBPS in the long run because the superusers gained significant experience in implementing BES-I and validating BES-II. The same set of superusers continued for BES-III, with some additional domain experts trained as superusers for the latter. In this way, it supports the recommendations that a multi- skilled team (Syed, Bandara, French, & Stewart, 2018; Sumner, 2018) having experience in both organisational processes and IT is crucial for the implementation. However, case evidence also suggests that in some cases, the project members from the business side “either weren’t made by their respective managers to get involved to the levels they should have been involved or chose not to get involved at the level they should have been involved” (R8). This illustrates a form of passive resistance (Murungi et al., 2019), which may be the result of a conflict between multiple institutional logics (Bunduchi et al., 2020) in the healthcare setting. The niche nature of the blood bank industry resulted in the market acting as an input control mechanism (Ouchi, 1979, 1980) during the pre-implementation phase. While there exist a lot of capacity in the health informatics sector in general (Miah, Shen, Lamp, Kerr, & Gammack, 2019), few IT vendors possess the appropriate capabilities and skills to fully support the evolving needs of the blood banks (Li et al., 2007). For this reason, all three instances of pre- implementation are marked by limited options available to NBPS due to a niche market (Olsen & Sætre, 2007), as opposed to the general health informatics market where many solutions are available for hospital and clinical management. Thus, during the pre-implementation phase for all three instances of BES project, the market indirectly controlled the options available to NBPS. Interestingly, a user notes for BES-III that they got a certain module “because the organisation decided as a whole that they were going for [the complete suite]… never saw it operated anywhere else” (R14). This suggests that replacement risks (Furneaux & Wade, 2017) and perceived reputational gains (Polykarpou, Barrett, Oborn, Salge, Antons, & Kohli, 2018; Salge et al., 2015) may also play a role in system acquisition apart from the formal gap analysis. During the implementation phase, user training also acted as an input control mechanism. There was a significant amount of time allocated to user training during BES-I since NPBS “had people who did not know how to turn on a computer, suddenly sitting down trying to figure it out – F11 and F8 and all these different buttons” (R7). “For most of the end-users, they were using computers the very first time. So, it was not just training for BES-I, but also it was their first exposure to work with computers” (R18). For BES-II, user training was not required since the project was abandoned. Interestingly, user training was not given too much attention during BES-III implementation since the business processes and user screens did not change much during BES-III implementation. A limited amount of training was conducted towards the very end of the implementation. The “training at the last minute didn't really impact because the navigation (in BECS) is so similar to the old system” (R22). This underscores the importance of users’ prior exposure to the software, suggesting limited investment in formal training during ES upgrades (Koh et al., 2009; Barth & Koch, 2019). Perhaps due to these factors, NBPS did not report any problems associated with BES-III usage after go-live. This supports the importance of existing social capital (Sykes, 2015; Sykes & Venkatesh, 2017) in system usage in an organisation. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 14 The market also played a controlling role during the post-implementation phase. During the post-implementation phase for BES-I, while NBPS recognised the need for a reporting tool, the project started only when a reliable solution was available from an external provider (New York Blood Bank). In contrast, internal development of electronic ordering system started since no similar feature, that could work with BES-I, was available in the market. 5.2 Outcome Control The three BES projects are marked by diverse control mechanisms for enforcing outcome control across the phases. In the pre-implementation phase, business case was the main behaviour control mechanism. Interestingly, the business case seems to serve a dual purpose in this regard. While the ostensive purpose of the business case was to provide the rationale for the implementation (Nafeeseh & Al-Mudimigh, 2011), the demonstrative nature of the business case preparation (Berente, Gal, & Yoo, 2010; Einhorn, Marnewick, & Meredith, 2019) may also be noted in the case study. While the users were involved in the process, they often did not have significant expertise in developing such documents. For BES-III, users report that they “were given documents from another European blood service and more or less told to copy and paste them” (R17). It was also expressed by the respondents that “not enough time was put in at that stage of the process” due to time constraints on “on top of (their) routine day” (R16). The findings support the argument that user involvement in the early stages may not be feasible due to their inexperience (Wagner & Newell, 2007). At times, actively involving end users may not be productive due to a lack of time (Wagner & Piccoli, 2007) from their day- to-day job. Paradoxically, although envisaged as a control mechanism, user involvement in business case development may be ineffective (Lyytinen & Newman, 2015; Willis & Chiasson, 2007) at the same time. During the implementation phase, requirement specifications, testing and validation, and project plan were the main outcome control mechanisms. The project team used requirement specification to lock down user expectation. This is in line with the use of requirement specifications as a scope control and expectation control (Einhorn et al., 2019) mechanism. Similarly, project plan was used as a mechanism to control the project timeline. While BES-I and BES-II were marked by huge deviation from the project plan, most respondents noted “a preoccupation” with and “an unmerciful push” (R4) towards the go-live in BES-III. This reflects a teleological dimension (Van de Ven & Poole, 1995; Wiener et al., 2016) in the form of learning from prior projects. In one instance where project leadership was aware that the go- live date would be postponed for BES-III core module, the team members were informed about it only at the very end “to keep the pressure on and the focus on getting the work done” (R2). As the narrative suggests, however, there were still some delays in the project. This suggests that project plans in dynamic environments should be used as a reference only and need to be constantly updated (Petit, 2012) in response to emerging situations. However, the main outcome control mechanism in all three instances of BES implementation was testing and validation of the system. Perhaps owing to its healthcare context, NBPS essentially subscribes to validation view of the implementation process. Within NBPS, “validation lifecycle process is very closely akin to project management, especially in terms of specification, design, testing, (and) delivery” (R3). There is “a great emphasis on validation reports for all the software development in NBPS… and there is a quality manager sitting in IT, who ensures that (the) IT systems fulfil all the quality requirements” (R15). Considering the concern related to patient safety and the complexity of institutional logics (Bunduchi et al., Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 15 2020; Poba-Nzaou et al., 2014; Salge et al., 2015) in the healthcare setting, the level of testing and validation does not seem misplaced. In fact, testing and validation also worked as an outcome control during the post- implementation phase as well. The reporting project team followed similar procedures for report development validation and testing that are reported for the implementation phase: We did specs for every one of them and then tested them against the spec. Got them built, got them in, had a look at them, got them refined, then validated them. So, that's how we did it. (R4) Electronic ordering system initiation was a bit informal in the sense that it was “born out of (the) Director of Operations and (the) Head of processing approaching a member of IT directly” and “there were no controls put in place” (R5). However, later on, outcome controls were placed, and it was ensured the system was properly validated and that it was a secure system. Therefore, for both the reporting system and the electronic ordering system, testing and validation was the main outcome control mechanism during the post-implementation phase of BES-I. 5.3 Behaviour Control Perhaps owing to the public sector context, behaviour control in the pre-implementation phase is marked by administrative controls in the form of departmental approval and public tendering processes. For BES-I and BES-III, NBPS asked for departmental approval. For BES- II acquisition though, NBPS did not seek clearance from its parent Department, effectively bypassing administrative control. Instead, the vendor sent an official proposal for the project which was then accepted by NBPS. As noted in the case, the main reason for this was BES-II being an upgrade of BES-I system, and unchanged market condition. However, getting the departmental approval for BES-III proved to be a difficult job due to prevailing economic environment. Thus, the pre-implementation phase demonstrates the politically contested and negotiated nature of the acquisition process (Matinheikki et al., 2019; Moe et al., 2017) in the public sector. A second administrative control for the acquisition process is the public tendering process. While NBPS used public tendering processes for the acquisitions requiring capital investments for the first and the third instances, it did not do so in the second instance. This reflects the dialectics of public sector procurement (Moe et al., 2017) in which the public entities may wish to continue extensive collaboration with the vendor, but also are restricted by existing procurement rules. The implementation phase saw the most extensive form of behaviour control across multiple levels, supporting the findings (Soh et al., 2011; Nuwangi et al., 2018) on hierarchy of controls and the multiplicity of controller-controlee relationships in a multi-stakeholder environment. The steering group was the main behaviour control mechanism in all three project instances. A steering group comprising of top management, and heads of IT and business units oversaw the implementation of BES-I and BES-II. The steering group for BES-III also included a high- level vendor representative, in addition to four members from the senior management team at NBPS. It was felt that “the set-up of the steering group meetings helped” (R3) the project and ensured that the issues were “being raised with the vendor at the highest level” (R2). Thus, the findings support the notion of the steering group as an effective behavioural control mechanism (Loonam, McDonagh, Kumar, & O'Regan, 2014; Sumner, 2018) for enterprise systems implementation. Case evidence also suggests that such temporary hybridisation Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 16 (Matinheikki et al., 2019) of including the vendor in the steering group (Choudhury & Sabherwal, 2003) helps in early resolution of implementation problems. This also reflects the teleological learning (Van de Ven & Poole, 1995; Wiener et al., 2016) from earlier projects when the vendor was not part of the steering group. Blood Enterprise System-III implementation also included a financial oversight as a cost control mechanism (Matinheikki et al., 2019; Susilo et al., 2007; Grabski & Leech, 2007) during the implementation phase. This probably was due to the repercussions associated with BES-I and BES-II that went significantly over-budget and invited an audit by the public auditor, once again exhibiting a teleological evolution of controls. Cost-control with the vendor involved “being very challenging and scrutinising every invoice” (R1) and verifying it with the actual work performed. There was also a quarterly review of the BES-III project by the finance committee of NBPS. It is a sub-committee of the NBPS Board and the “project manager would present at each meeting of the finance committee a project update and a status report on the project” (R2). Regular project meetings were identified as a key form of behaviour control (Matinheikki et al., 2019; Niederman et al., 2018; Wiener et al., 2016) during the implementation phase. For BES-I, separate project groups operated in the two major centres, and there were no joint meetings. During BES-II, this was remedied, and project management was integrated across the two centres with a single project team. While there were larger project meetings (usually once a month) for BES-III, work-stream meetings were more frequent (usually once a week). NBPS had “an implementation plan for each of the different work-streams” (R3). Each work- stream had a “weekly meetings with (the) project manager (and) issues were discussed weekly” (R22). The majority of the respondents agreed that the work-stream structure worked well for the project, supporting the observation that such structure may help in strengthening structural ties (Wiedermann & Wiesche, 2018) within the larger project team. The post-implementation phase of BES implementation in NBPS is marked by project audit and review especially by external parties. For BES-I and BES-II, NBPS ended up justifying itself before the public auditor and the parliamentary committee. In both cases, there were many “questions asked from the government point of view at that time as to why so much money was spent” (R22). In that sense, public auditor and parliamentary committee acted as a post- facto behaviour control for entire process. After the implementation failure of BES-II, NBPS also commissioned an external review of the project and a professional audit firm was appointed to undertake this review. Around the same time, NBPS also commissioned a study by an academic expert to suggest steps to maximise the business value from IT. Both these initiatives can be seen as efforts to repair their reputation (Polykarpou et al., 2018) in the public service context that demands higher levels of public accountability (Campbell, McDonald & Sethibe, 2010; Matinheikki et al., 2019; Syed et al., 2018). Perhaps therefore, being “very conscious of (what) had happened in the past” (R1), NBPS incorporated project audit and review as a control mechanism also during the implementation phase of BES-III. As noted in section four, there were two audits of BES-III by external audit partners. Furthermore, NBPS constituted a PRG for BES-III when suggested by the parent Department. Formation of PRG is a mandatory feature of large-scale IT projects in the national public sector. However, since NBPS is not funded through voted monies, it need not form a PRG by law. Yet, it formed a PRG to ensure legitimacy (Matinheikki et al., 2019) within the public sector context. It was also noted that the PRG “did ensure that (NBPS) did retain Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 17 discipline around project management and around delivering through the different stages” (R2). Thus, the findings support the use of external reporting and audits (Grabski & Leech, 2007; Chang, Yen, Chang, & Jan, 2014) as behavioural control mechanisms during enterprise systems implementation. At the same time, it also shows a teleological evolution (Van de Ven & Poole, 1995; Wiener et al., 2016) of behaviour controls across multiple projects. A high level of behavioural control was also visible in the change controls during the post- implementation phase. Any maintenance and upgrade activity within NBPS require a high level of change control procedures (Wang, Ju, Jiang, & Klein, 2008), a form of strict behaviour control. For some, “there (is) an insane amount of change control and a very high level of validation (surpassing) the level of validations and quality control (in the pharmaceutical industry)” (R18). There was a feeling that within NBPS, “it can be quite difficult to get a change. There is an awful lot of paperwork. There is a validation procedure and a lot of paperwork even for the smallest change on a system” (R16). This particular element of change control also relates to the clan control discussed in the next section. 5.4 Clan Control Due to the nature of its business, multiple institutional logics (Berente et al., 2010, 2019; Bunduchi et al., 2020; Salge et al., 2015) – medical, nursing, IT, managerial – clan control could be observed in NBPS. As one participant notes [National Blood Processing Service] is an organisation comprised of many different kinds of professionals. There are senior consultant doctors (who) have a very strong view on just about everything. You have a full cohort of medical scientists, who will regard themselves as a professional of their own. There is a full cohort of nurses in the organisation, and then you've got the IT professionals, who have their own particular technical set of blinkers that they look at, everything at. So, you've all these professional groups, sitting at a table, all looking over at everybody else's what they are doing and commenting on what everybody else is doing. (R1) Due to its health service context, NBPS is risk averse with a safety culture (Poba-Nzaou et al., 2014; Salge et al., 2015). As one participant notes: “Our concern in scientific side is safety. Have we tested it and is everything right? And is the donation fit to go? So, we are buried in a whole lot of that” (R4). High level of change control (noted in section 5.3) is justified in the organisation because “there is a safety in that. So, it means that people aren't changing things at willy-nilly… it's quite cumbersome to make a change but again, there is a safety element in that” (R16). This is aligned with the observation that health professionals prefer sticking to tried and tested systems (Furneaux & Wade, 2017) when it comes to healthcare IT. While the health sector norms were found to be effective during the pre-implementation and the post-implementation phase, it was at odds with IT professional culture especially during the implementation phase. While the health norms prioritise safety, even if at the expense of time, IT professionals sometimes felt frustrated due to it. This usually resulted in IT professionals taking on additional responsibilities, reflecting a clan control by the IT unit. “So, it's the people in IT (who) had to pick up the slack for those people” (R12). The IT unit was “doing it since they (business) were not doing it” (R18). The result was that resources from the IT unit (including superusers) worked “above and beyond, working on evenings and on weekends” (R18). Irrespective of the project, the clan control within the IT unit (Chua et al., 2012; Goldbach & Benlian, 2015; Wiedermann & Wiesche, 2018) is clearly evident from the quotation below: Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 18 What IT (unit) tends to do is to pick-up what other people drop. That is just the nature of what we do. I think it's just a mindset. You may kind of know yourself that technically-minded people have a particular way of going about things. So, if they see a problem, they generally want to fix it. I did find that we ended up picking an awful lot of things in the project that weren't strictly our responsibility to do. (R8) While professional norms played a greater role in the IT unit assuming additional responsibilities, some bit of self-control was also evident, as noted in the next section. 5.5 Self-control Self-control in the BES project was evident in the form of individual initiatives. In all three instances, the initiative from the top management played an important role during the pre- implementation phase. From NBPS Board minutes, it is clear that the chief executive presented the rationale for the implementation in NBPS Board meetings, resulting in the Board accepting the proposal for the implementation of the new system. Case evidence supports the observation that senior management are the most likely activators (Bernroider, 2013) for enterprise systems projects. Support from top management is deemed crucial for such projects (Bhoola et al., 2014; Loonam et al., 2014; Syed et al., 2018; Sumner, 2018) since “once you get the leadership and the buy-in from the top (and) once you get the support at a senior administration level…, you can get the job done” (R3). There was a significant amount of individual initiative from the project team during the implementation phase. This was mainly due to the resource allocation discussed in section 5.1. For instance, the superusers had to concentrate on the implementation as well as to focus on the maintenance of the existing system. The project resourcing was such that “the same people who (were) supporting the current day to day production applications (were) implementing projects” (R8). This resulted in a lot of multi-tasking. The superuser “would be writing the test scripts for [BES-III] and then a user may call to solve a daily problem related to [BES-I]” (R18). Understandably this decision was made to exploit superusers’ in-depth knowledge of the system (Obwegeser et al., 2019; Sumner, 2018), but it also increased their workload (Wagner & Piccoli, 2007). For this reason, superusers seemed to impose a lot of self-control upon themselves. Since this was noted for the domain experts as well as the members of the IT unit, it was taken as a sign of self-control rather than clan control. As participants from both groups observe: I've been working weekends a lot, and extremely long hours during the week, I've to say. But there was nobody else to do my job. So, I haven't had my holidays really either… I was doing more than I should have been doing. I would have been down in the labs doing some IT work. I'm not saying that it is IT's fault, but when things needed to be done straightaway… you want to do it. So, I went down to the labs myself and just did it.” (R12) There wasn't enough hours in the day to get everything done - you know because and then you're kind of under pressure to get things done at a certain time and to get documents signed off and changes made and things like that, you know. So, it was kind of pressurised, but every project is like that. (R21) In the post-implementation phase, self-control from the management played a major role in the introduction of new modules. The initiative for the reporting module came from the Director of Operations who joined NBPS in 2005 and saw value in introducing a reporting and Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 19 forecasting system. Similarly, the development of electronic ordering system was initiated when the Director of Operations and the Head of processing unit approached a member of the IT unit. This illustrates the extended role of senior management (Bernroider, 2013; Loonam et al., 2014) in enterprise systems projects beyond investment decisions. 6 Conclusion 6.1 Contribution This study offers a number of contributions towards a holistic understanding of IS controls. First, this study provides a rich description of the evolution of an IS control portfolio during an enterprise system lifecycle implemented in a regional blood bank in Western Europe, something that is relatively scarce in extant literature (Cram et al., 2016; Inácio & Marques, 2018). The study demonstrates that the nature and extent of controls changes across the phases of the enterprise system lifecycle, thus supporting a lifecycle perspective (Van de Ven and Poole, 1995; Van de Ven & Sun, 2011) within a project. While all control modes are found to be applicable across all phases, they differ in terms of control mechanisms applied in different phases. This is a significant contribution of this study as limited evidence is available on the clan control and self-control dimensions (Wiener et al., 2016), especially in the presence of multiple institutional logics. Second, by studying the three instances of the implementation in a single case organisation, it presents the historical evolution (Chua & Myres, 2018) of a control portfolio across multiple projects as they unfold over time. In particular for behaviour controls, the findings suggest a teleological (Van de Ven & Poole, 1995; Wiener et al., 2016) evolution of a control portfolio in which new control mechanisms are introduced over time based on the adaptive learning process from earlier projects. Third, this study moves beyond a single controller-controlee dyad and exhibits the multi- stakeholder and multi-level (Soh et al., 2011; Nuwangi et al., 2018) nature of the control portfolio. This is particularly salient in the case of behaviour controls during the implementation phase. While project communication provided the control within project, other behavioural controls (steering group, financial oversight, audit and review) acted as the control mechanisms over (Wiener et al., 2017) the project. This supports the observation (Ouchi, 1978) that different levels of the hierarchy may rely on different behaviour controls. Finally, by exhibiting the influence of institutional context and niche market, this study underlines the contextual nature (Avgerou, 2019; Berente, et al., 2019; Matinheikki et al., 2019) of the enterprise systems implementation and associated controls in the blood bank market. Application of external controls (public auditor, parliamentary committee, PRG) is a reflection of the public sector context where demands for public accountability (Campbell et al., 2010; Matinheikki et al., 2019; Syed et al., 2018) are usually higher. The influence of the health sector (Bunduchi et al., 2020; Poba-Nzaou et al, 2014; Salge et al., 2015) is also evident in the form of the prevailing safety culture and the focus on a high level of validation and change control. Due to the niche nature (Olsen & Sætre, 2007) of the blood bank market, this study also demonstrates the influence of market as an input control mechanism (Ouchi 1979, 1980) in the form of limited vendor/product options. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 20 6.2 Implications There are a number of implications of this study for practicing managers. First, the institutional and market influences on the control portfolio indicate that the top management team needs to be aware of the contextual factors when planning and executing enterprise systems projects. Controls due to the contextual factors may increase the demand for resources as well as the need for top management involvement. These requirements are to be factored-in when planning a project in a complex environment like public health. Second, multi-stakeholder control structure identified in this study suggests that there are multiple controller-controlee relationships with the same managers playing both roles at times. For instance, while top management primarily acted as a controller during the pre-implementation and the implementation phase, they fulfilled the controlee role when representing the organisation before the national auditor during the post-implementation phase. This might require managers to revise their mental models as the project progresses. Third, a related implication is that managers may need to draw from different skillsets (e.g. technical, managerial, or political) based on the control portfolio evolution during the enterprise systems lifecycle, depending upon their role and whom they are interacting with. Fourth, the importance of an informed and powerful steering group cannot be overemphasised for enterprise system implementation. In addition, the case evidence suggests that it might be beneficial to include a high-level vendor representative in any such group. This may facilitate the resolution of issues from the very beginning. Fifth, the outcome of BES- III suggests that a high number of formal controls may be associated with positive project outcomes. Hence, it might be better for the managers to be comprehensive in applying formal controls. Even though this might take time in the beginning, it would eventually be beneficial for the overall project in terms of project completion and ensuring legitimacy. Finally, for IS audit and evaluation functions, there is a need to recognise and respond to the evolving nature of an organisation’s control portfolio as it relates to enterprise systems implementation. Of necessity, this requires a commitment to (re)educating key stakeholders about the critical linkages between controls at various phases/stages of the enterprise systems lifecycle and the pursuit of purposeful and positive IS-enabled business change. 6.3 Limitations and future development Some limitations of this study need to be outlined. First, this study acknowledges the context specificity of the findings and limited external generalisability due to the focus on a single case. However, the rich description provided in this longitudinal case seeks generalisation to theoretical propositions (Yin, 2017) as opposed to statistical generalisation to a population. Second, due to the retrospective nature of the interview method, there might be a possibility of post-hoc rationalisation by the participants to provide some coherence to the events and a rational purpose to their actions. However, publicly available documentation, reports from the national auditor, and parliamentary committee debates are used as triangulation devices (Miles et al., 2014; Yin, 2017) to ensure internal validity (Maxwell, 2017) of the account. Third, due to access restrictions, the vendor perspective could not be included. The vendor perspective could have added richness to the case study and may have contributed to overall validity of the study. Finally, due to time limitations, we could not investigate the post- implementation phase of BES-III. Since the BES-II project was abandoned during implementation, the findings for the post-implementation phase rely on BES-I project only. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 21 In terms of future development, the findings from this study suggest that there is merit in pursuing further research into the evolving nature of control portfolios in enterprise systems initiatives in diverse contexts. Moreover, since the enterprise systems industry is moving towards cloud-based implementation, future research may focus on studying the difference between the control mechanisms operating in a traditional on-premise implementation versus those in the cloud environment. Of particular interest here is a deep exploration of the role and influence of IS audit and evaluation functions in shaping control portfolios that contribute directly to achieving positive IS-enabled business change. References Adam, F., & O'Doherty, P. (2000). Lessons from enterprise resource planning implementations in Ireland–towards smaller and shorter ERP projects. Journal of Information Technology, 15(4), 305-316. Alfonso, E., Xie, X., Augusto, V., & Garraud, O. (2012). Modeling and simulation of blood collection systems. Health Care Management Science, 15(1), 63-78. Ali, M., & Miller, L. (2017). ERP system implementation in large enterprises–a systematic literature review. Journal of Enterprise Information Management, 30(4), 666-692. Ashford, P., Gozzard, D., Jones, J., Revill, J., Wallis, J. ... & Cohen, H. (2000). Guidelines for blood bank computing. Transfusion Medicine, 10(4), 307-314. Avgerou, C. (2019). Contextual explanation: alternative approaches and persistent challenges. MIS Quarterly, 43(3), 977-1006. Barth, C., & Koch, S. (2019). Critical success factors in ERP upgrade projects. Industrial Management & Data Systems, 119(3), 656-675 Berente, N., Gal, U., & Yoo, Y. (2010). Dressage, control, and enterprise systems: the case of NASA's Full Cost initiative. European Journal of Information Systems, 19(1), 21-34. Berente, N., Lyytinen, K., Yoo, Y., & Maurer, C. (2019). Institutional logics and pluralistic responses to enterprise system implementation: a qualitative meta-analysis. MIS Quarterly, 43(3), 873-902. Bernroider, E. W. (2013). Effective ERP adoption processes: the role of project activators and resource investments. European Journal of Information Systems, 22(2), 235-250. Bhoola, V., Hiremath, S. B., & Mallik, D. (2014). An Assessment of risk response strategies practiced in software projects. Australasian Journal of Information Systems, 18(3). https://doi.org/10.3127/ajis.v18i3.923 Bunduchi, R., Tursunbayeva, A., & Pagliari, C. (2019). Coping with institutional complexity. Information Technology & People. 33(1), 311-339. Campbell, J., McDonald, C., & Sethibe, T. (2009). Public and private sector IT governance: Identifying contextual differences. Australasian Journal of Information Systems, 16(2), 5-18. https://doi.org/10.3127/ajis.v16i2.538 Chang, S. I., Yen, D. C., Chang, I. C., & Jan, D. (2014). Internal control framework for a compliant ERP system. Information & Management, 51(2), 187-205. Choudhury, V., & Sabherwal, R. (2003). Portfolios of control in outsourced software development projects. Information Systems Research, 14(3), 291-314. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 22 Chua, C. E. H., Lim, W. K., Soh, C., & Sia, S. K. (2012). Enacting clan control in complex IT projects: A social capital perspective. MIS Quarterly, 36(2), 577-600. Chua, C. E. H., & Myers, M. D. (2018). Social control in information systems development: a negotiated order perspective. Journal of Information Technology, 33(3), 173-187. Cram, W. A., Brohman, K., & Gallupe, R. B. (2016). Information systems control: A review and framework for emerging information systems processes. Journal of the Association for Information Systems, 17(4), 2. Cumming, P. D., Kendall, K. E., Pegels, C. C., Seagle, J. P., & Shubsda, J. F. (1976). A collections planning model for regional blood suppliers: description and validation. Management Science, 22(9), 962-971. Einhorn, F., Marnewick, C., & Meredith, J. (2019). Achieving strategic benefits from business IT projects: The critical importance of using the business case across the entire project lifetime. International Journal of Project Management, 37(8), 989-1002. EDQM (2017). Guide to the preparation, use and quality assurance of blood components. European Directorate for the Quality of Medicines & Healthcare. https://www.edqm.eu/en/blood- guide Furneaux, B., & Wade, M. (2017). Impediments to information systems replacement: a calculus of discontinuance. Journal of Management Information Systems, 34(3), 902-932. George, A. L., & Bennett, A. (2005). Case study and theory development in the social sciences. Cambridge, MA. Goldbach, T., & Benlian, A. (2015). How social capital facilitates clan control on software platforms to enhance App-developers’ performance and success. In Thirty Sixth International Conference on Information Systems, Fort Worth 2015 Gopal, A., & Gosain, S. (2010). Research note – The role of organizational controls and boundary spanning in software development outsourcing: Implications for project performance. Information Systems Research. 21(4), 960-982. Grabski, S. V., & Leech, S. A. (2007). Complementary controls and ERP implementation success. International Journal of Accounting Information Systems, 8(1), 17-39. Gregory, R. W., & Keil, M. (2014). Blending bureaucratic and collaborative management styles to achieve control ambidexterity in IS projects. European Journal of Information Systems, 23(3), 343-356. Gregory, R. W., Beck, R., & Keil, M. (2013). Control balancing in information systems development offshoring projects. MIS Quarterly, 1211-1232. Gupta, O., Priyadarshini, K., Massoud, S., & Agrawal, S. K. (2004). Enterprise resource planning: a case of a blood bank. Industrial Management & Data Systems, 104(7), 589-603. Heiskanen, A., Newman, M., & Eklin, M. (2008). Control, trust, power, and the dynamics of information system outsourcing relationships: A process study of contractual software development. The Journal of Strategic Information Systems, 17(4), 268-286. Henderson, J. C., & Lee, S. (1992). Managing I/S design teams: a control theories perspective. Management Science, 38(6), 757-777. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 23 Inácio, H., & Marques, R. P. (2018, June). Analysis of the research on internal control in enterprise resource planning systems. In 2018 13th Iberian Conference on Information Systems and Technologies (CISTI). IEEE. JPAC (2013). Handbook of Transfusion Medicine. Joint United Kingdom (UK) Blood Transfusion and Tissue Transplantation Services Professional Advisory Committee. https://www.transfusionguidelines.org/transfusion-handbook Katsaliaki, K., & Brailsford, S. C. (2007). Using simulation to improve the blood supply chain. Journal of the Operational Research Society, 58(2), 219-227. Kendall, K. E., & Lee, S. M. (1980). Formulating blood rotation policies with multiple objectives. Management Science, 26(11), 1145-1157. Kirsch, L. J. (1997). Portfolios of control modes and IS project management. Information Systems Research, 8(3), 215-239. Kirsch, L. J. (2004). Deploying common systems globally: The dynamics of control. Information Systems Research, 15(4), 374-395. Kirsch, L. J., & Cummings, L. L. (1996). Contextual influences on self-control of IS professionals engaged in systems development. Accounting, Management and Information Technologies, 6(3), 191-219. Koh, S. C. L., Gunasekaran, A., & Cooper, J. R. (2009). The demand for training and consultancy investment in SME-specific ERP systems implementation and operation. International journal of production economics, 122(1), 241-254. Langley, A., & Meziani, N. (2020). Making Interviews Meaningful. The Journal of Applied Behavioral Science, 56(3) 370–391. Langley, A., Smallman, C., Tsoukas, H., & Van de Ven, A. H. (2013). Process studies of change in organization and management: Unveiling temporality, activity, and flow. Academy of Management Journal, 56(1), 1-13. Li, B. N., Chao, S., & Dong, M. C. (2007). SIBAS: A blood bank information system and its 5- year implementation at Macau. Computers in Biology and Medicine, 37(5), 588-597. Loonam, J., McDonagh, J., Kumar, V., & O'Regan, N. (2014). Top managers & information systems: ‘Crossing the Rubicon!'. Strategic Change, 23(3-4), 205-224. Lyytinen, K., & Newman, M. (2015). A tale of two coalitions - marginalising the users while successfully implementing an enterprise resource planning system. Information Systems Journal, 25(2), 71–101. Mao, J. Y., Zhang, X., & Song, W. (2008). Information Systems Development in a Low Maturity Environment: An Exploratory Case Study on Control Modes. PACIS 2008 Proceedings, 263. Matinheikki, J., Aaltonen, K., & Walker, D. (2019). Politics, public servants, and profits: Institutional complexity and temporary hybridization in a public infrastructure alliance project. International Journal of Project Management, 37(2), 298-317. Maxwell, J. A. (2017). The validity and reliability of research: A realist perspective. Eds. Wyse, D., Selwyn, N., Smith, E., & Suter, L. E. (Eds.). The BERA/SAGE handbook of educational research (pp. 116-140). UK: Sage. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 24 Mazaheri, E., Lagzian, M., & Hemmat, Z. (2020). Research Directions in information Systems Field, Current Status and Future Trends. Australasian Journal of Information Systems, 24. https://doi.org/10.3127/ajis.v24i0.2045 Miah, S., Shen, J., Lamp, J. W., Kerr, D., & Gammack, J. (2019). Emerging Insights of Health Informatics Research: A Literature Analysis for Outlining New Themes. Australasian Journal of Information Systems, 23. https://doi.org/10.3127/ajis.v23i0.2137 Miles, M. B., Huberman, A. M., & Saldana, J. (2014). Qualitative Data Analysis. Sage. Moe, C. E., Newman, M., & Sein, M. K. (2017). The public procurement of information systems: dialectics in requirements specification. European Journal of Information Systems, 26(2), 143-163. Murungi, D., Wiener, M., & Marabelli, M. (2019). Control and emotions: Understanding the dynamics of controllee behaviours in a health care information systems project. Information Systems Journal, 29(5), 1058-1082. Nafeeseh, R. A., & Al-Mudimigh, A. S. (2011). Justifying ERP investment: the role and impacts of business case a literature survey. International Journal of Computer Science and Network Security, 11(1), 185-193. Niederman, F., Müller, B., & March, S. T. (2018). Using process theory for accumulating project management knowledge: A seven-category model. Project Management Journal, 49(1), 6- 24. Nuwangi, S. M., & Sedera, D. (2018). Too Tight – Too Loose: Controlling Lessons from a Failed IS Development Project. Australasian Conference on Information Systems 2018. UTS, Sydney. Nuwangi, S. M., Sedera, D., & Srivastava, S. (2018). Multi-layered Control Mechanisms in Software Development Outsourcing. PACIS 2018 Proceedings. 167. Obwegeser, N., Danielsen, P., Hansen, K. S., Helt, M. A., & Nielsen, L. H. (2019). Selection and training of super-users for ERP implementation projects. Journal of Information Technology Case and Application Research, 21(2), 74-89. Olsen, K. A., & Saetre, P. (2007). IT for niche companies: is an ERP system the solution?. Information Systems Journal, 17(1), 37-58. Ouchi, W. G. (1978). The transmission of control through organizational hierarchy. Academy of Management Journal, 21(2), 173-192. Ouchi, W. G. (1979). A conceptual framework for the design of organizational control mechanisms. Management Science, 25(9), 833-848. Ouchi, W. G. (1980). Markets, bureaucracies, and clans. Administrative Science Quarterly, 129- 141. Pandey, S., & Sumant, O. (2020). Blood Bank Market by Product Type, Function, Bank Type, and End User: Global Opportunity Analysis and Industry Forecast, 2020–2027. Allied Market Research. https://www.alliedmarketresearch.com/blood-bank-market Pentland, B. T. (1999). Building process theory with narrative: From description to explanation. Academy of Management Review, 24(4), 711-724. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 25 Petit, Y. (2012). Project portfolios in dynamic environments: Organizing for uncertainty. International Journal of Project Management, 30(5), 539-553. Pettigrew, A. M. (2012). Context and Action in the Transformation of the Firm: A Reprise. Journal of Management Studies, 49(7), 1304-1328. Poba-Nzaou, P., Uwizeyemungu, S., Raymond, L., & Paré, G. (2014). Motivations underlying the adoption of ERP systems in healthcare organizations: Insights from online stories. Information Systems Frontiers, 16(4), 591-605. Polykarpou, S., Barrett, M., Oborn, E., Salge, T. O., Antons, D., & Kohli, R. (2018). Justifying health IT investments: A process model of framing practices and reputational value. Information and Organization, 28(4), 153-169. Salge, T. O., Kohli, R., & Barrett, M. (2015). Investing in information systems: On the behavioural and institutional search mechanisms underpinning hospitals’ IS investment decisions. MIS Quarterly, 39(1). Saxena, D., & McDonagh, J. (2017). A Systematic Literature Review of the Enterprise Systems Research in Leading IS Journals (2000-2015). In Proceedings of the Twelfth Midwest Association for Information Systems Conference, US: Springfield, Illinois, May 2017 Soh, C., Chua, C. E. H., & Singh, H. (2011). Managing diverse stakeholders in enterprise systems projects: a control portfolio approach. Journal of Information Technology, 26(1), 16- 31. Somers, T. M., & Nelson, K. G. (2004). A taxonomy of players and activities across the ERP project life cycle. Information & Management, 41, 257–278. Srivastava, S. C., & Teo, T. S. (2012). Contract performance in offshore systems development: Role of control mechanisms. Journal of Management Information Systems, 29(1), 115-158. Sumner, M. (2018). ERP Project Retrospectives—55 Enterprise Systems: Evaluating Project Success, Lessons Learned, and Business Outcomes. In Proceedings of the Thirteenth Midwest Association for Information Systems Conference, US: Saint Louis, Missouri 2018. Syed, R., Bandara, W., French, E., & Stewart, G. (2018). Getting it right! Critical success factors of BPM in the public sector: a systematic literature review. Australasian Journal of Information Systems, 22. https://doi.org/10.3127/ajis.v22i0.1265 Susilo, A., Heales, J., & Rohde, F. (2007). Project Management Effectiveness: the choice-formal or informal controls. Australasian Journal of Information Systems, 15(1). https://doi.org/10.3127/ajis.v15i1.480 Tiwana, A., & Keil, M. (2009). Control in internal and outsourced software projects. Journal of Management Information Systems, 26(3), 9-44. Van de Ven, A. H., & Poole, M. S. (1995). Explaining development and change in organizations. Academy of management review, 20(3), 510-540. Van de Ven, A. H., & Sun, K. (2011). Breakdowns in implementing models of organization change. Academy of Management Perspectives, 25(3), 58-74. Wagner, E. L., & Newell, S. (2007). Exploring the Importance of Participation in the Post- Implementation Period of an ES Project : A Neglected Area. Journal of the Association for Information Systems, 8(10), 508–524. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 26 Wagner, E. L., & Piccoli, G. (2007). Moving beyond user participation to achieve successful IS design. Communications of the ACM, 50(12), 51-55. Wang, E. T., Ju, P. H., Jiang, J. J., & Klein, G. (2008). The effects of change control and management review on software flexibility and project performance. Information & Management, 45(7), 438-443. Wiedemann, A., & Wiesche, M. (2018). How to Implement Clan Control in DevOps Team. Twenty-fourth Americas Conference on Information Systems, US: New Orleans, 2018. Wiener, M., Remus, U., Heumann, J., & Mähring, M. (2015). The effective promotion of informal control in information systems offshoring projects. European Journal of Information Systems, 24(6), 569-587. Wiener, M., Mähring, M., Remus, U., & Saunders, C. S. (2016). Control Configuration and Control Enactment in Information Systems Projects: Review and Expanded Theoretical Framework. MIS Quarterly, 40(3), 741-774. Wiener, M., Cram, A., & Remus, U. (2017). The view from the top – how senior executives exercise control over information systems projects to enhance performance. In Proceedings of the 25th European Conference on Information Systems (ECIS), Guimarães, Portugal, June 5-10, 2017 (pp. 1423-1438). Willis, R., & Chiasson, M. (2007). Do the ends justify the means? A Gramscian critique of the processes of consent during an ERP implementation. Information Technology & People, 20(3), 212-234. Winter, S., Berente, N., Howison, J., & Butler, B. (2014). Beyond the organizational ‘container’: Conceptualizing 21st century sociotechnical work. Information and Organization, 24(4), 250-269. Yin, R. K. (2017). Case study research and applications: Design and methods. Sage publications. Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 27 Appendix -1: Coding Tree Code Control Mechanism Control Mode Being Public Sector Administrative control Behaviour Control Difference with Pvt Sector Different Processes Following EU Directive PRG Oversight Procurement Process Project Approval Public Accountability Regulatory Oversight IT Audit Audit and review Learning from Past Project Audit Project Evaluation Project Review Change Management Change control Focus on Change Control Impact of Change Limited BPR Process Change Quality Control Risk Management Budget Overrun Financial oversight Budgetary Control IT Budgeting Project Costing Project Meetings Project communication User Buy-in User Expectation User Resistance Work Stream Meetings Communication within Organisation ICT Council Steering Group IT Representation in TMT Management Support to IT Project Management Steering Committee Following International Standard Professional norms (Health) Clan Control Organisation Culture Risk Aversion in the Health Service Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 28 Risk Aversion in NBPS Safety Focus Different Professional Cultures Professional norms (Health/IT) Ensuring Professional Accountability Fragmented view of the Organisation Inter-departmental Tension Internal Work Relationships Organisation Complexity Validation Credibility Following Technology Curve Professional norms (IT) IT Taking the Slack Being First User Market control Input Controls Benchmarking Against Peers Blood Transfusion Industry Complete Suite Dominant Vendor External Development of the System In-house/Outsourcing Nature of Blood Operations Niche Market Relationship with Vendor Vendor’s Push System Usage in the Industry Dedicated Project Manager Resource allocation Domain Expert as Superuser IT Infrastructure IT Staffing Multiple Responsibilities Project Leadership Project Resourcing Project Structure Project Team Single Point of Dependency Staffing Superusers Location Superuser's System Knowledge Work Streams Prior Exposure to System User training Staff IT Skills Training needs BBCS Business case Outcome Controls Blood Control System Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 29 Business Integration Business Process Ownership Customisation Data Migration Database Integration Gap Analysis Introducing ISBT-128 IS Strategy Process Specificity Project Scoping Single Site Processing System Centrality to Business System Maturity System Usage in Organisation Understanding Hospital's Needs Understanding Impact of Change Cascading Effect on Projects Project plan Change in Go-Live Dates Focus on Go-Live Incremental Development No Parallel Systems Project Lifecycle Project Planning Time Overrun Validation View of Project System Definitions Requirement specifications System Functionality User Involvement Competing Access Testing and validation Hardware Constraints System Configuration System Constraints System Performance System Quality System Security System Testing Electronic Document Management System Individual initiative (management) Self-Control Electronic Ordering System Implementing BOSS Information Deficit Introducing Automation Australasian Journal of Information Systems Saxena & McDonagh 2020, Vol 24, Research Article IS Controls in Healthcare 30 MIS Reporting Operational Improvement Operational Inefficiency Work Stress Individual initiative (project team) Initiating Project Proposal Individual initiative (top leadership) TMT Support Copyright: © 2020 Saxena & McDonagh. This is an open-access article distributed under the terms of the Creative Commons Attribution-NonCommercial 3.0 Australia License, which permits non-commercial use, distribution, and reproduction in any medium, provided the original author and AJIS are credited. doi: https://doi.org/10.3127/ajis.v24i0.2635 http://creativecommons.org/licenses/by-nc/3.0/au/