1 Introduction

Public sector organizations aim to acquire the best possible information systems (IS) and, at the same time, comply with public procurement regulations [4]. Evidently, this task is not easy [5] as the success rate remains low [6]. This lack of success has made the public procurement of IS, its challenges, and different features an increasingly popular research topic [13].

These failures are often associated with the project’s size [6], policies, and legislation [2], in addition to common reasons for failed IS projects [7]. However, these reasons are usually reported as project specific. Therefore, their applicability or broader understanding is debatable. A generic list of IS acquisition characteristics would provide better understanding and, thus, explain why some acquisitions fail and others succeed. This need and potential motivate our research.

Moe [2] argued that the lack of know-how in the acquisition process hinders to successful IS acquisition. This lack of expertise has several causes and consequences. For example, the vendor might not be aware of what the customer or user really wants and/or needs while the user may mistrust the vendor as the company is offering strange features and solutions [1]. Incompetent, inexperienced, and careless preparation and construction of the requirements are likely to result inauspicious tendering and procurement [8].

However, studies on the different characteristics of public IS procurement and their influence on acquisition projects are rare. This lack of research emphasizes two research needs: acquisition characteristics and their impacts. In this paper, we focus on the former. We seek answers to the question, “What are the key characteristics of a public sector IS acquisition?” To construct a taxonomy for public sector IS acquisition, we explore four public sector IS acquisition cases and classify their characteristics.

The paper is organized as follows: Sect. 2 provides the theoretical background. The following section introduces the research settings and methods. Then we briefly present our findings. The discussion section summarizes the results, and the conclusion places the paper in a broader context.

2 Theoretical Background

Public procurement refers to the process of acquiring goods or services for a government or public organization through buying or purchasing [9]. The procurement process can be divided into five phases: specifying the requirements, tendering, selecting the vendor, contracting, and implementing and completing the process [2]. An important difference between public and private sector organizations is the question of ownership. Individuals in a society ‘own’ public organizations while private businesses are owned by a limited number of shareholders or entrepreneurs [10]. Furthermore, the funding for public acquisitions is based mainly on taxation. In addition, in the public sector there are fewer market-related disturbances than in the private sector [11]. The control mechanisms for the public sector are imposed by political factors and specific legislation instead of only economic factors. However, public sector organizations rarely have direct competition offering the same services [10]. These factors lay the foundation for the characteristics of all public sector organizations, but the way the characteristics occur in IS acquisitions is rarely studied.

Procuring IS differs significantly from more standardized goods or services [5]. The actual need may sometimes be challenging to recognize or articulate. The alternative solutions for needs may not always be comparable without careful analysis and operationalization. This issue applies to assessing different options and their significances [1].

A standardized, off-the-shelf information system seldom fulfills the needs of any organization without target-specific configurations. This also applies in the public sector. Therefore, fulfilling an organization’s needs require customization. This often leads to outsourcing the development. As public sector organizations tend to decrease their IS departments, intensive cooperation and communication with external stakeholders are emphasized; outside vendors are seldom sufficiently familiar with the context and the operations [12]. This also applies to internal parties. An IT department in a public sector organization rarely knows or understands the use context of social services, for example. This means that when decisions about the requirement specifications and the scope must be made, the appropriate content may remain vague [13].

The procurement process itself, with its legislative restrictions and payment model and standard government contracts has several obstructions and limitations. If, for example, the call for tenders is poorly prepared, it will narrow the vendors’ willingness to participate in the tendering process and to engage in the project. This will limit competition and provide fewer alternatives for the customer organization. To put it in other words, this will hinder the organization from getting the best solution or price [4, 14].

Another relevant stream of literature is IT investments. Xue et al. [15] argued that IT investments are influenced by the characteristics of the investment (scope, requirements), the external environment (competitive pressures, institutional forces, external resources), and the internal context (centralization, the IT unit’s power). Premkumar and King [16] similarly emphasized organizational size, industry, planning time horizon, resources, and organizational capabilities and resources. Jones and Hughes [17] stated that the size of the IS investment has an impact on the evaluation and success of the investment. The IT investment literature thus emphasizes the role of generic characteristics in investments. However, the literature does not accentuate or differentiate the characteristics in the public sector context.

All this indicates that several characteristics frame the acquisition. However, a comprehensive list is not available, and some characteristics may actually be derived from other features. In other words, the vagueness in the requirement specification phase may originate from the organizational structures, culture, and system characteristics. Consequently, the literature, even when combined, does not comprehensively describe IS acquisition characteristics, as the research premises are derived from various perspectives and approaches in individual studies.

3 Research Setting

3.1 Research Methods

This study follows a qualitative collective case study [18] approach in which the cases might “be similar or dissimilar, redundancy and variety [are] each important. They are chosen because it is believed that understanding them will lead to better understanding, perhaps better theorizing, about a still larger collection of cases” [19, p. 437]. Four cases were selected according to their type (public sector IS acquisition) and appropriate project phase (the acquisition activities had ended and the system implementation had either just been completed or was ongoing). Two cases appeared to be successful IS acquisitions while two cases faced major problems. The unit of analysis is a case.

The data was collected by interviewing every key person in each project in a semi-structured interview. The list of cases and interviewees is presented in Table 1. The interviewees were chosen by snowball sampling [20, pp. 816–817]. The first interviewee was selected by our contact, after which we deliberately asked the interviewees about other stakeholders to interview later. The interviews, approximately an hour each, were conducted in spring 2014 face-to-face at the interviewees’ premises. The interviews followed the thematic open interview approach in which a general frame was modified according to the interviewees’ state and status. We wanted to gain an in-depth understanding of how the project proceeded and its details.

Table 1. Descriptions of the cases

The cases were analyzed by utilizing grounded theory [21] as the coding method. This means that the data was coded several times. In this paper, we do not intend to develop a theory, as is often the case with grounded theory [22]. Instead, we investigate a collection of open and axial codes as characteristics of IS acquisition. This means that two authors analyzed the data by first identifying distinct characteristics of each case (open coding) and then revised the codes several times until they were harmonized. Finally, similar codes were grouped into larger groups and labeled with appropriate names (axial coding). These groups, with representative examples, are presented in the discussion.

3.2 The Cases

The four public sector IS acquisition cases are briefly described in Table 1.

The Case A acquisition was initiated by one hospital district, but the acquisition was broadened to cover multiple hospital districts in the end. The interviewees were selected from the initial hospital district. The Case B acquisition had strong political supervision as the acquisition was initiated by the Ministry of Social Affairs and Health. The ministry stated that all public dental care systems had to be connected to the national database. This project was coordinated by the National Institute for Health and Welfare that launched a call for piloting projects. The case municipality applied for the pilot project and received guidance and funding from the institute. The Case C acquisition was complex with multiple components. The acquisition encountered severe challenges when the losing vendors sued the municipality in market court. The market court, to which disputed public sector case parties may appeal, ruled the tendering process had been unlawful, derived from the ambiguous terms used in the requirement specification. Case D was the least problematic acquisition, as the income support division had just purchased a complete IS. Cases A and C had to be tendered by legislation, while Cases B and D were not tendered.

4 Empirical Findings

The data analysis depicted 19 recurring characteristics in the public sector IS acquisitions. These characteristics were present in all cases, although, because of space limitations, only an example from one case illustrates each characteristic.

Assuming Uniformity.

In all cases, the stakeholders assumed that equivalent services, provided by public sector organizations, would have identical processes elsewhere. It was thus assumed that an IS utilized in one public sector organization could be easily copied and replicated elsewhere. For example, in Case A, the project manager stated, “As a whole, the processes are relatively similar.” The chief information officer (CIO) stated, “In the beginning, we agreed on conducting a specification project, in which we describe the process, general requirements, and architecture to a maternity care system. We stated that there are ten hospital districts; it would be good to get them all involved in this.” As the project included two isolated departments, with separate IS, inside the hospital districts, the chief medical officer stated, “The idea was to deliberately achieve non-institutional and specialized healthcare under the same model.” These assumptions created challenges for the vendor, as the municipalities participating in the joint acquisition had diverse needs. “We cannot start always carrying out the requests. He says so. We do it. The next one says no, we want it in this way” (Case A, Product Manager).

Creating a Consortium.

In Case A, the CIO and the chief medical officer saw the opportunity to create a consortium with multiple hospital districts to leverage their bargaining power with the vendor. “Our aim was a joint acquisition with economies of scale. We wanted to get the vendor to bend for better conditions and thus gain work of better quality” (Case A, CIO). “The idea was that we would have had a national project, and we would have been big enough a counter-power to these companies in negotiation positions” (Case A, Chief Medical Officer). Thus, the acquisition was a joint acquisition for multiple hospital districts.

In other cases, the acquisitions were not jointly conducted, but they had features of similar consortium acquisitions. For example, in Case D, the IS was developed by the customer group with members from multiple municipalities using the same system. “They had a working group, which met every now and then. Municipalities presented requests to the vendor and disclosed in what direction they are moving” (Case D, Division Director).

IS Acquisition Complexity.

Single IS acquisitions are connected to multiple divisions or even municipalities. In Case A, the new IS covered two maternity wards’ departments in multiple hospital districts. The bases, needs, and processes differed in the municipalities. “Every hospital district could, in their own time, in their own schedule, take the tendered system into use” (the CIO). The diversity between the clients increases the complexity of the IS.

Divided Decision Making.

In Case A, in which the acquisition was carried out by a consortium, decision making was divided among multiple hospital districts. “It actually ended so that because every district had an equal decision-maker, we did not achieve a common mindset” (Case A, CIO).

Steering and Working Groups.

Every case had multiple stakeholder groups: steering and planning groups and project groups. In addition, Case C had working groups for different specialties, e.g., security and telecommunication. In Case B, there were isolated user, steering, project, and testing groups. This created problems although the groups made decisions, gave statements, and provided information. The project manager (Case B) stated, “I do not know who makes the final decision about the acquisition; there has to be probably a kind of steering group which has made the decision.”

Initial Idea Derived from Operations.

In three cases, the acquisition idea was initiated by a non-IT employee. “The need arises always from the substance, I mean from the labor and delivery room, child health center, and hospital wards” (Case A, Product Manager).

Idea Is Carried Out by IT Department.

In all cases, IT departments conveyed the idea forward. “Business units usually tell their own IT departments their needs because budgeting is their responsibility. They always have the budget” (Case A, Product Manager). The IT department is then assumed to gain approval for the acquisitions. “A proposal was written to IT department […], and then [they] launched the acquisition as they should” (Case C, Project Manager).

Political Forces.

In Case B, the initial idea was not launched by the business unit but by a ministry. The acquisition topic was going to be mandatory sooner or later. “This IS acquisition has been like ‘implement it or else..’” (Case B, Project Coordinator). Political forces thus strongly influenced the case. Similarly, in Case D, legislation and the municipality’s council directed the acquisition. In the public sector, political aspects and agendas affect decision making as the voices of various task forces and teams must be heard before decisions about specific points are made. Political forces were thus evident.

Detailed Requirement Specification.

In Cases B and D, the requirements were not specified by the organizations doing the acquisition. Instead, the requirements were either steered by national requirements (Case B) or set by a superficially configured product (Case D). Legislation required no tendering. In Case A, the hospital district employed a commonly and publicly owned ICT provider to lead and coordinate the IS acquisition. In addition, the provider employed a consultant to help specify the requirements: “We actually had multiple user groups: doctors, midwives, non-institutional side, nurses, secretaries, everyone defining how this system should be used. All of this was written down, and then we negotiated multiple times and refined the specification” (Case A, Chief Medical Officer). The time-consuming phase resulted in the requirement specification being partly indefinite and partly a detailed trade-off of diverse needs. Case C was similar as legislation necessitated formal tendering. Detailed and thorough requirement specification steered the tendering process and vendor selection. Specifying the requirements was equally time-consuming.

Burden of Existing Systems.

In all cases, the organizational IS had a long history. In Cases A, B, and D, the acquisition was an update or an add-on to existing systems. In Case C, the system was meant to be built from the scratch, although the organization had a similar system. In all cases, the interfaces with existing systems caused significant problems. “We don’t practically have any other options than [vendor’s name], because we use their systems” (Case D, Division’s Director). Consequently, existing legacy systems were burdens.

Only a Few Potential Vendors in the Market.

Existing systems and closed interfaces led to situations in which the organization had only a few potential vendors or only one in Cases B and D. In addition, the size of the acquisitions in Cases A and C reduced the number of potential vendors. In contrast, the smaller acquisitions in Cases B and D were updates and add-ons, which made the current vendor an obvious candidate. Although the interfaces did not bind the client to the vendor, the customers relied on a well-known vendor if tendering was not required, as in Case B. “Our experts have been strongly participating in [existing patient system] with [vendor’s name], and we know it inside out, its pros and cons. We know how to use it, and we have stated that it is workable. It is possible that we didn’t want to take the risk to end up in something worse” (Case B, Project Coordinator).

Seeking Preliminary Information.

All acquisition organizations sought information before the acquisition. In Case D, a business unit representative was assigned to explore customer needs. “His task was to carry out a customer survey and explore customers’ willingness patronize electronically and their technical premises, possible support needs” (Case D, Division’s Director). In Case C, the “IT department purchased a preliminary report, and in the report, they collected the current situation of home care. They had various workshops and interviews for different user groups” (Project Manager). The acquisition organization also requested information from possible vendors about technical solutions to specify the requirements.

Mapping Processes.

In all cases, the processes that would be connected to the upcoming IS were mapped and described. The mindset was to get a system to support the processes, not vice versa. “I understand that we have to change the age-old healthcare processes and bend them to certain limit according to the IS, but we have some core processes, which we won’t bend; the IS has to bend” (Case A, Chief Medical Officer). This task was executed internally, although different parties participated.

Lack of Resources in the IT Department.

Aperson from the IT department acted as the project manager or coordinator in every acquisition. However, the role was taken on in addition to other projects and tasks. “I acted as the project manager in addition to my own job” (Case D, Project Manager). The IT department and project sizes and competencies varied. “We have, in the IT department, one technical person, who is me, and then I have four people, nurses and social workers, on a team” (Case A, CIO). The lack of resources became visible to other parties.

Innovation Is Derived from Individuals.

The initial ideas were launched or highlighted by individuals. For example, in Case A: “As we know, all good ideas derive from a bar encounter. So did this, so we had many years ago, a hospital’s chief medical officer’s meeting, and later in the evening, we sat with the boys and a couple of ladies at the bar. We stated that we had a common factor, and it is this IS. We noted that it was reaching its end, and we needed a new one” (Chief Medical Officer). Individuals’ personal formal and informal contributions seem to be remarkable factors in hatching and launching ideas. Only in Case B was the idea launched and driven by political bodies. However, there was an individual at the function who took the idea forward.

Competency.

Acquisition competence was distributed to multiple organizations and departments. This is displayed vividly in Case C: “Home care people do the practical specifications. Then the specifications go to the IT department, because the users know only how to say ‘I don’t want the hatch to open,’ so the IT department knows how to define it in requirement form—and then we have dialogue about all the requirements. We have a work distribution so that we [the procurement department] provide after that all the economic conditions for the tendering” (Case C, Procurement Specialist).

Dedicated Procurement Organization.

Cases A and C had a dedicated procurement organization for the tendering phase. In Case A, the organization was an external information and communications technology (ICT) provider and in Case C an internal procurement organization. Sometimes, this style caused problems as the business units did not understand tendering, and the procurement organization did not understand the business: “It was outside my expertise. I did the requirements. The tendering part did not interest me” (Case A, Chief Medical Officer). The procurement specialist (Case C) stated, “We do not know diddly-squat about home care.”

IT Department Owns the Contract.

The IT department always owned the contracts. It even seemed obvious. Other units did not seem to be interested in the contracts or were not allowed to participate in the contract phase. “Of course, the responsibility for the contracts is in the IT department” (Case C, Project Manager).

Distant Funding.

Funding the acquisitions was not a question in the cases. Interviewees mentioned that the acquisition was budgeted for and approved by different steering groups. The main actors did not seem to worry about the funding, especially in the business units. “The costs were never actually a problem; I think they were no driver here. We’re talking about tens of thousands of euros. When I think about the hospital’s expenses, it equals a few hip surgeries” (Case A, Chief Medical Officer). The IT departments negotiated the prices although the funding was not discussed.

5 Discussion

Our findings indicate that all public sector organizations sought to collaborate as bigger units in the beginning of the IS acquisition [23]. However, the cases demonstrate that the advantages of volume did not materialize; instead, the opposite occurred as the complexity of the acquisition increased [24]. Volume created problems in Case A. For example, they received only three bids from the major actors in the national ICT field. This reduced the number of potential solutions significantly. In addition, although the municipalities provided seemingly similar services, the organizations and processes differed. Here, joint acquisition increased complexity as diverse needs, processes, and actors had to be considered. This complexity increased the number of non-decision-making groups whose opinions and statements were still valued, which caused time delays and overlap in conferring with the various parties. Then, as decision making was distributed among multiple equal parties, no one was in charge. Therefore, larger consortia seem to create more problems instead of providing the advantages of volume.

The IS acquisitions were initiated by business units and their senior managers. Then the idea was presented to the internal IT department. This is a bottom-up approach. Although in Case B the idea originated from political parties (the top-down approach), it was opportunistically adopted by the business unit and the IT department. Together, they presented the proposal to several steering groups for support and funding. The cases indicate that no matter where the idea for the acquisition originated, the role of individuals is emphasized.

Planning the acquisition depends on the need for tendering. In the cases in which tendering was required, the requirement specifications were done carefully: The processes were mapped and described in detail. In addition, different actors participated in specifying the requirements. However, although the requirements were accurate from the individual actors’ viewpoints, no one considered the big picture (c.f. [1]). In cases where tendering was not required, the planning phase was not clear. The customer did not explore alternative vendors but simply acquired the system from a well-known vendor with which the customer had an existing relationship. Thus, the need to tender forced the acquisition organization to explore different solutions, map their processes, and commit the business personnel to create accurate requirement specifications.

The acquisition parties included the business unit, the IT department, and, in some cases, a separate procurement organization. An external procurement consultant is an ICT acquisition specialist while an internal consultant is in charge of all kinds of acquisitions. Thus, the parties’ competences vary. In some cases, the acquisition was carried out by only the business unit and the IT department which had appropriate experience and competence. Then no tendering was required. The IT department took an active role, usually with an assigned technical project manager or coordinator. However, the employee often had multiple concurrent projects, lessening his or her commitment and participation. Sometimes, a business unit representative was also assigned to the project to provide an operational perspective. Although the participants might have the necessary knowledge and competence, they were divided into multiple units and working groups, and each group represented its own field. This makes information sharing difficult as understanding others and their specialties is not supported [1]. No one understands the big picture. Table 2 groups the characteristics of public sector IS acquisitions into six groups.

Table 2. Grouping of characteristics

Although tendering was often carried out by a separate procurement organization, the business unit and the IT department evaluated the bids and selected the vendor. After the vendor was selected, the procurement organization withdrew from contracting and transferred the responsibility to the IT department. The lengthy contracting phase, including the negotiation of prices and conditions as the most challenging aspects, was carried out by the IT department. Surprisingly, no one worried about funding.

6 Conclusion

We have provided a list of public sector IS acquisition characteristics. Our analysis indicated 18 common characteristics: assuming the uniformity of municipalities and divisions, creating a consortium, IS acquisition complexity, divided decision making, steering and working groups, initial idea derived from operations, idea is carried out by the IT department, political forces, detailed requirement specification, locking in a vendor, seeking preliminary information, mapping processes, lack of resources in the IT department, innovation is derived from individuals, competency, isolated procurement organization, the IT department owns the contract, and distant funding. These characteristics were categorized into six groups: size, dispersed groups, comprehensive preparation, IT unit’s central role, driving forces, and market/locking in a vendor.

Size seemed especially challenging. Joint tendered acquisitions seem to displace smaller vendors. This contradicts Moe’s [2] need for the technologically best solutions. As tendering is costly and time-consuming, the public sector pays a higher price for the acquisition and then tenders it again. This is not necessarily in line with the need for the most economical alternative. All this reduces the public sector’s bargaining power and even their know-how, allowing the major vendors to dominate the tendering and contracting phases. As non-tendered acquisitions are often made with a well-known vendor, the public sector organizations get locked in to vendors, increasing their monopoly.

Our findings provide an explanation of the IS acquisition characteristics in the public sector. This list helps researchers and practitioners understand the context and challenges. These characteristics also help organizations anticipate different emerging features in IS acquisitions. However, these characteristics should be further studied as we did not focus on influences and impacts.

One limitation is that the country in which the study took place is largely dominated by two to four vendors. Therefore, smaller, sometimes more innovative, vendors are often excluded from tendering. This exclusion may have implications for various characteristics. In addition, the selection of the cases may have caused limitations. The number of cases was small (4), and they are mainly in the health and social security sector. Whether the findings are generalizable to other areas of societal infrastructure, such as building and housing, or other acquisitions, remains debatable, and necessitates further research.