# Dialectics and Contradictions in Public Procurement of Information Systems

Carl Erik Moe, Maung Kyaw Sein

► To cite this version:

Carl Erik Moe, Maung Kyaw Sein. Dialectics and Contradictions in Public Procurement of Information Systems. 13th International Conference on Electronic Government (EGOV), Sep 2014, Dublin, Ireland. pp.289-300, 10.1007/978-3-662-44426-9_24. hal-01401753

HAL Id: hal-01401753

https://inria.hal.science/hal-01401753

Submitted on 23 Nov 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Dialectics and contradictions in public procurement of Information Systems

Carl Erik Moe<fnref n="1" /> and Maung Kyaw Sein<fnref n="1" />,<fnref n="2" />

**Abstract.** Public procurement of Information Systems is a highly complex process. Not surprisingly, systems often fail to meet the needs for which they were procured. One of the main causes of this is the contradictions between goals of different stakeholders. Identifying and understanding these conflicts and contradictions are essential to develop strategies to improve the procurement process. In this paper, we present a case study where we examined the procurement process of a system carried out by a public entity in Norway. Using dialectic theory and stakeholder theory as interpreting lenses, we identified a number of conflicts and contradictions. Some of the contradictions resulted from conflicting and divergent goals of the various stakeholders across groups but also within groups, while others resulted from differing goals of policies and regulations.

**Keywords:** Public procurement of IS. Dialectics. Stakeholder theory.

## 1 Introduction

Procurement has become the most common way of acquiring information systems (IS), especially in the public sector. However, this is a highly complex process [1]. There are numerous instances of failed procurement projects (e.g. the GOLF-project in Norway). One of the main causes of this is conflicting goals. These goal conflicts may be due to incompatible political goals, such as ensuring open and fair competition versus preference for local vendors, or they can be due to conflict between short-term and long term goals of the projects. Such projects also involve a variety of stakeholder groups who have diverse and often conflicting interests which adds to the existing conflicts. To develop appropriate strategies to deal with conflicting goals we first need to identify them.

Two streams in the literature have examined these issues. One stream has examined the conflicts and contradictions that surface in IS projects in general [2-4] and in the public sector in particular [1, 5]. The theoretical premise of several of these studies has been dialectics [4, 6-8]. The other stream has focused on

<footnote n="1">¹ Department of Information Systems, University of Agder, Kristiansand, Norway
{Carl.E.Moe, Maung.K.Sein} @uia.no</footnote>

<footnote n="2">² Luleå University of Technology, Luleå, Sweden</footnote>
stakeholders and how differing interests lead to contradictions and often conflicts in
IS projects in general [3, 9] and in eGovernment in particular [10-12]. While each
stream has produced valuable insights, they only address part of the problem: either
the nature of the conflicts or the interests of the stakeholders. Only a few studies have
used both perspectives to provide a more complete picture (e.g. [13]).

We propose that combining dialectical theory with stakeholder theory provides us with a sharper theoretical lens to understand the conflicts and contradictions that arise in a public IS project, especially in public procurement. A better understanding of this process can lead to better strategies to cope with challenges. To examine our proposition, we conducted a case study of the procurement of an EHR system (Electronic Health Record) in Norway and interpreted the data using concepts from dialectics and stakeholder theories. We unearthed a number of contradictions that underlay the procurement process and identified the role of various stakeholders in these contradictions.

The rest of the paper is organized as follows: In the next section, we discuss some of the conflicting goals in public procurement. We then briefly describe the two theoretical perspectives, namely, dialectics and stakeholder theories. Next, we describe our case and our data analysis, and then present our findings. We conclude the paper by discussing our findings in relation to existing literature and suggest areas for future research.

## 2. Conflicting Goals in Public Procurement

Public procurement is regulated in most countries and thus differs from private
procurement. The European Union (EU) applies two public procurement directives
with the underlying principles of transparency and non-discriminatory competition
[14, 15]. All public procurements above a threshold value of 200 000 € (for 2014)
should be announced as a call in EU's tender electronic database (TED). Some
countries have additional national threshold levels; which requires calls to be
announced in the national database.

A public entity may face a number of dilemmas or conflicting goals in a
procurement process. Among these is the dilemma between the principle of equal
opportunities for all competitors and preferences for a specific software vendor, or for
local vendors. Many states in the US have criteria related to promoting the efforts of
small businesses, women, and minorities when choosing contractors [16]. Dilemmas
exist between creating requirements specifications up front or developing the system
specification as an integral part of the procurement process [5]. The latter option
allows for greater learning from the vendors. These dilemmas are further complicated
when stakeholders have different and often conflicting interests. This challenge may
be tougher in the public sector than in the private sector, as organizations that are
subject to political controls are more likely to face multiple sources of authority that
are potentially conflicting [17]. In public procurement, we can expect contradicting
interests between vendors and procuring entities. While procurement managers and
CIOs want a clear, complete and detailed picture of requirements, vendors find
requirement specifications too detailed and extensive [18]. Vendors are often left with
the task (and the power) of providing the answers as to whether their software meet the functionality requirements. This can create a challenge for the procuring entities. Moreover, different user groups may have different goals [9] which often leads to compromises on software functionality and application of power to overcome user resistance [3]. It is often extremely difficult for all stakeholders to agree on the objectives for a new system (Swanson 1988, in [19], p. 11). The sheer variety of stakeholders make public procurement of IS a highly complex process. Figure 1 depicts this complexity.

<figure><img src="image_2.png" /><figcaption>Fig. 1. A basic stakeholder model</figcaption></figure>

It is a misconception that stakeholder theory advocates equal treatment of all stakeholders [20]. An organizational entity may have several conflicting goals or interest groups competing for priority [21]. Oppositions may be external to the organizational entity. Vendors may have their obvious interest of doing business, and this interest may not align with the internal stakeholders. Interest groups, such as chambers of commerce may try to influence a municipality to procure from vendors in the region. Elected politicians may have a say as representatives for the citizens. Lastly, regulatory bodies enforce regulations.

In practice a procurement project may have an even more complex stakeholder map than shown in figure 1. End user groups may not be homogeneous but may have different interests. Even members in the project group may have conflicting interests. Line management may have different interests, depending on the functional area they represent. Further, stakeholders' relative preferences may vary over time [4]. Public procurement can be a rather long process, hence a stakeholder group such as end users can't be expected to sustain the same interest in a procurement all through a project.
**3. Theoretical Premises**

To understand the complexity of the public procurement process discussed above, we draw upon two theoretical premises, stakeholder theories and dialectics.

**3.1 Stakeholder theory**

A stakeholder can be defined as "any group or individual who can affect or is affected by the achievement of the organization's objectives" [22]. Stakeholders are also people who have put something at risk in relationship with the firm [23], or with power to change the strategic future of the organization [24]. Stakeholder theory has been adopted in the e-Government field [11] and studies have shown that stakeholders can be influential in the success or failures of public IS projects [10, 25]. This perspective is different from that of the management literature which focuses on which stakeholders are important to a corporation and how these salient stakeholders should be managed. Stakeholders have a significant role to play in ensuring successful e-government. Hence it is suggested that a shared understanding of the interests, perspectives, value dimensions, and benefits sought by the various stakeholders is vital [12]. This also applies to procurement of IS in public sector. As the procured system affects different stakeholder groups, we should expect that the requirement specification and the selection of the system would be critical.

**3.2 Dialectics**

Dialectical reflections and contradictions can be means to understand change processes in IS development [2, 6]. Contradictions can be understood as opposites (thesis and anti-thesis), but not necessarily conflicts. In dialectics theory, stability and change is explained by reference to the balance of power between the opposing entities [21]. The opposing entities may be between different commitments for one group, or between different stakeholder groups with contradicting goals (e.g. nurses involved in a project and other nurses not involved).

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Dialectical process lens (adapted from [21])</figcaption></figure>

The dialectic process (Fig. 2) can result in three possible outcomes: (a) synthesis which is a negotiated compromise between the thesis and the anti-thesis (b) the thesis
or the anti-thesis prevails, or (c) no resolution; the thesis and the anti-thesis remain in
a state of pluralism or conflict. A synthesis may in turn lead to a contradicting
antithesis which may set off another dialectical process.

Dialectical approach has been suggested for studying IS implementation which is conceived as a complex intertwined set of social and political interactions [19]. Dialectics has been applied to analyze learning [7] and misalignments in ERP implementation [8]. We therefore found dialectics useful in our study.

## 3.3 Summary

In this section, we put forward two theoretical premises that we argue can be relevant to understand the complex public procurement process. While stakeholder theory and dialectics has been previously applied in combination in analysis of e-government cooperation [13], and enterprise implementation [7, 8], to our knowledge it has not been used in examining public procurement. In our study we attempt to demonstrate how combining the two analytical lenses can provide a better understanding of public procurement of information systems. We describe the case next.

# 4. Case Study

Our case site was a Norwegian municipality with a population of approximately 40.000. The procurement was part of a larger project to comply with a directive of the Norwegian government which required message exchange of electronic health records (EHR) between all municipalities and public hospitals. A project group called “Message Exchange Group” was set up to determine how to comply with the directive. The group soon discovered that their present vendor could not add the message exchange functionality to the existing system. Consequently, the municipality established a new project group to procure an EHR system that included some members of the “Message Exchange group”.

## 4.1 Case Narrative

In keeping with the usual practice in the municipality, the procurement project group consulted an inter-municipal procurement consulting entity and invited other municipalities in the regional network of municipalities to join the process. One smaller municipality decided to take part; however the process was led by the bigger municipality. The two municipalities applied tenders with negotiations as the procedure for this case.

Figure 3 depicts the timeline of the procurement process. As can be seen; the project commenced in April 2012. The municipality announced the upcoming tender and invited vendors to submit documentation for pre-qualification on issues such as financial capabilities and technical competencies. In parallel the project group finalized the requirement specifications, so they could invite vendors to submit offers. To do so, it borrowed a requirement specification from a neighboring municipality
that had been through the same process less than 2 years before. The project group visited three neighboring municipalities that had used systems from three major EHR-vendors, to get insights to develop the specifications further. It also held a brainstorming session with a reference group of 16 super users to get further input.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Timeline of the procurement process showing the different stages</figcaption></figure>

At the pre-qualification stage, three vendors expressed an interest in participating. We started our data collection with observation in the meeting where the project group opened the papers the vendors had submitted to establish their credentials. All three were found qualified and they were invited to submit offers. All of them did within the deadline, and were invited to take part in the negotiations.

The negotiations were carried out primarily through three day-long meetings with each vendor on scheduled issues. Each vendor got the same information prior to the meetings, and was given exactly a week between each meeting. The first meeting was meant to check whether there was a common understanding of the requirements and the software. The project group discovered that all vendors to some extent had ticked off incorrectly on whether their software met a requirement or not. Price and contract issues were on the agenda for the second meeting. In this meeting one of the vendors was told within minutes that they had to rewrite the contract terms and were sent home after approximately an hour. They submitted a new contract and were allowed to take part in the following negotiations.

In the third meeting the vendors were asked to demonstrate how the software could be applied in an assigned task. A group of super users was invited to this meeting, where they posed questions to the vendors on matters that concerned them. The procurement group leader led the session and ensured that the users did not focus on marginal issues. The project group also collected the opinions of the super users after the demonstration. After this round the project group carried on a short round of negotiation over telephone with two vendors before selecting the final winner.

## 4.2 Data Collection

We collected data through 15 interviews and observation in 7 project meetings. There were 10 telephone (Skype) interviews that lasted for 10 – 45 minutes and 6 face-to-face interviews that lasted for 60 – 75 minutes. We interviewed the project managers twice, 4 of the super users of the new system, the super user of the old system (who also was in the project group), one additional member of the project group, the procurement managers involved, and sales manager at the winning vendor. The
meetings included 3 negotiation meetings with vendors and lasted for 2 – 7 hours. We also got access to memos from some of the meetings. We recorded all interviews and project meetings and later transcribed them. In our data analysis, we applied a hermeneutic circle [26] approach. We identified key stakeholders and their interests.

## 5. Findings

We began our analysis by identifying the various goals in the project and the stakeholders who were associated with these goals. Table 1 summarizes our findings.

<table><caption>**Table 1.** Goals observed in the projects</caption><thead><tr><td>Goal</td><td>Description</td><td>Evidence</td><td>Associated stakeholder(s)</td></tr></thead><tbody><tr><td>1</td><td>Conduct a formally correct procedure</td><td>Extensive use of procurement consultants; careful organizing of the negotiation process.</td><td>Project group and procurement consultant</td></tr><tr><td>2</td><td>Select the system that meets their needs best</td><td>Considerable time spent by the project team on requirements specification; ranking vendors based on meeting specifications.</td><td>Project group, end users</td></tr><tr><td>3</td><td>Select a vendor within the deadlines</td><td>The project had tight deadlines, and the negotiations with the vendors were done over a 3 week intense period.</td><td>Project group</td></tr><tr><td>4</td><td>Implement message exchange</td><td>Government requirement; the requirement specification</td><td>Project managers, government</td></tr><tr><td>5</td><td>Acceptable contract terms</td><td>One of the vendors nearly disqualified as their contract terms not found acceptable</td><td>Project group</td></tr><tr><td>6</td><td>Avoid complaints</td><td>Project manager: "If we disqualified them based on those criteria, they could have complained on the process"</td><td>Procurement consultant</td></tr><tr><td>7</td><td>Keeping the old system</td><td>One stakeholder wanted to postpone procurement of the new system while waiting for new national requirements.</td><td>System owner of the old system, (s)he was a member of the project group</td></tr><tr><td>8</td><td>Migration of data from the old system</td><td>Note handed out in meeting; quotes from both project managers</td><td>System owner of both the old and the new system were members of the project group</td></tr></tbody></table>

We then used these goals and our interview data to conduct our dialectics based analysis to unearth the contradictions that existed in the project. We unearthed 4 contradictions which we describe next.

**Contradiction 1:** "Following regulations vs. satisfying system needs"
*Thesis*: The thesis arose from goal 1 (Conduct a formally correct procedure), and from goal 6 (avoid complaints). Right from the start, care was taken to ensure that procedures were followed strictly. The procurement consultant led the first few meetings of the project group, and gave the members precise instructions on how to run the process, e.g. the length of deadlines, the need to give the vendors equal access to information, and equal time to prepare in between negotiation meetings. He told them: *"We have to document that we do the procurement properly ...."*

*Antithesis*: The antithesis arose from goal 2 (Select the system that meets their needs best). In the brainstorming sessions, the reference group of users was asked to "say something about what could be better in a new system", and "what we wanted as part of a new system", according to one of the members of the reference group. The group was further invited to take part in visits to municipalities that used software from the three main vendors. The project group spent a great deal of time and resources getting the requirement specification right.

*Resolution*: The thesis won. The project group went to great lengths to ensure that regulations were not violated. For example, to avoid complaints, it kept in one vendor who they considered for disqualification. The winning vendor essentially confirmed it thus: *"They are so afraid of doing mistakes, so a normal dialogue is not possible. You do not get a good solution. It's all about fulfilling the requirement specification"*.

**Contradiction 2: "Change vs. persistence"**

*Thesis*: The thesis arose from goal 4 (Implement message exchange). This was a government requirement. The project plan stated: "The goal of the project is to implement electronic messages between internal cooperating entities as well as to external collaborating partners", and it was clearly stated in the requirement specification.

*Antithesis*: The antithesis had its base in goal 7 (Keeping the old system). At the start it was not clear that the municipality needed to procure a new system to implement message exchange, but the understanding gradually evolved for the project leaders. However, not all group members shared this view. The project leaders were aware of this. According to the "Message Exchange project" leader: *"there was not agreement in the project group (on the need for procurement) ... one person knows the old system very well and it is probably a bit sad to replace such a system"*. . The procurement project leader conveyed the same story: *"nn (the system owner of the old system) suggested postponing it (the procurement) for a couple of years because of upcoming national requirements for a core record, and the risk of betting on the wrong horse"*. A quote from one of the members in the reference group goes the same way: *"I think we still do not understand what it means to lose some of the functionality we have in our current system"*.

*Resolution*: The thesis won, the project was carried out according to plans, and the system was procured and installed according to the deadline.

**Contradiction 3: "Revolutionary change vs. incremental change"**

*Thesis*: The thesis arose from the implied goal of starting the new system from a clean slate. It required creating a new database with the old data being moved to an archive. The project leader and some members of the project group had the opinion that a part
of the old data could be “garbage” and thus the new system could end up with dirty
and unreliable data.

*Antithesis:* The antithesis arose from goal 8 (Migrate data from the old system). The owner of the old system (and the owner of the new system) wanted to migrate data from the old system and then do the needed conversion to the format of the new system. They argued that it would save a considerable amount of work. This led to very heated discussions with the proponents of a “clean slate” start for the new system. The question was not settled until after the contract was signed with the winning vendor. The project leader said: “It (the disagreement on migration) has taken a lot of energy, ... issues that were not decided .... focus remains there instead of on other issues that should have been discussed”.

*Resolution:* The result was a synthesis. The strategy was to postpone the decision till after signing the contract and basing it on the vendor's recommendation. Some of the data from the old system was converted, but not to the extent suggested.

**Contradiction 4:** "Implementation as primarily technical vs. implementation as socio-technical change"

*Thesis:* The thesis was evident from the way the procurement project group scheduled activities such as training, without focusing on possible organizational changes or changes in work process. The procurement project leader said as an afterthought (after the installation), "we could have been better at describing our processes up front.... now it comes as are about to start the training", implying that the software could have been "tailored" better.

*Antithesis:* The antithesis originated from one of the users who represented a unit that had specific interests. That unit took care of booking of different services such as home care and the existing system was vital to him and his group. He expressed serious concerns prior to the final selection as to whether the project group understood all the challenges: "I feel that nobody on the management side has supervised us properly so that we understand the magnitude of the transition in changing system ..... "The biggest challenges are coming, and they are related to us getting a new system .... It is a form of organizational change, quite a radical one, and I don't think we properly understand this...."

*Resolution:* The thesis won. After the implementation the project leader told us that they had really not understood this user and his unit's needs: "I don't think one understands that changing a large system can have such large effects for some employees" "We have not understood well enough". "The nn unit is suffering now". "This "hit" us the other day".

**6. Discussion**

Table 2 summarizes our findings on the four contradictions that surfaced from our analysis. Two of these contradictions are related to stakeholders within the project group, none of them are across groups. Contradiction 1 is related to conflicting goals, whereas contradiction 4 is related to different perspectives of implementation.
<table><caption>**Table 2.** Overview and classification of the identified contradictions</caption><thead><tr><td>Contradiction</td><td>Stakeholder related?</td><td>Conflicting goals</td><td>Continual or after a critical incident</td></tr></thead><tbody><tr><td>Follow regulations vs. satisfying system needs</td><td>No. Related to conflicting goals within the project.</td><td>Conduct a formally correct procedure vs. select the system that meets their needs best</td><td>Continual, runs all through the process</td></tr><tr><td>Change vs. persistence</td><td>Yes, Super user on the old system vs. project leaders</td><td>Implement message exchange vs. Keeping the old system</td><td>Continual. The resistance took new forms (goal of migrating data, not meeting up on one occasion)</td></tr><tr><td>Revolution vs. incremental change</td><td>Yes. Project leaders vs. system owners.</td><td>Start the new system with a clean slate vs. migrate data from the old system</td><td>After. System owner of the old systems had to give in.</td></tr><tr><td>Implementation primarily as technical installation vs. Implementation as socio-technical change</td><td>Yes. Stakeholder related to user of the old system</td><td>Not goal related. Arose from different implementation paradigms</td><td>Continual.</td></tr></tbody></table>

Contradictions, 2, 3 and 4 are quite general in that they can be seen in almost all IS projects. Only contradiction 1 can be thought of as specific to public procurement although it can be argued that even private sector procurements are subject to some degree of regulation. However, public procurement, like any aspect in the public sector is heavily regulated, not only from the local and state level agencies, but also from international bodies (such as the EU in our case). As such, we view this contradiction to be biggest dilemma that public procurement of IS has to face. To deal with this contradiction, a number of strategies evolve. The type of tendering used in our case – tender with negotiation – itself represents such a strategy. This tendering procedure allows negotiation between the procuring agency and the vendor on matters related to system specifications and requirements while at the same time retain the transparent and fair process that regulations aim to ensure.

An intriguing feature of these contradictions is that they seem to be related. For example, contradiction 2 and contradiction 3 represent tensions between “cleaning house” from day 1 of a new system and retaining existing practices or gradually moving from institutionalized practices to new ones. An interesting analysis would be to map whether the same stakeholder or stakeholder group are responsible for multiple and related contradictions.
## 6.1 Future research directions

More research is needed to test the typology and to see whether the identified contradictions are generic and may be seen in other cases. A cross-case study will shed light into this issue. More research is also needed on issues such as the dilemma between adhering to procurement regulations and applying specific social goals. A related research focus would be on how public authorities can apply policy goals and how these goals influence different phases of the procurement process, especially the requirements specification phase.

End users is an important stakeholder group in all IS procurement. Their requirements may be contradictory to the project group's requirements. An important research questions is how end users should be involved in requirement specification. In our case, a reference group of end users was set up who were involved in requirements specification and in the selection. Whether this strategy of involving end users as a reference group instead of as members of the project group itself is an effective way is an interesting avenue of future research. Since decisions are made during a procurement process with long lasting effects, these issues may be time-sensitive.

## References

1. Moe, C.E., Newman, M.: The Public Procurement of IS - A Process View. Proc. Hawaiian International Conference on System Sciences (HICSS), Big Island, Hawaii, 06-09.01 (2014)

2. Markus, M.L.: Power, politics, and MIS implementation. Communications of the ACM, 26. pp. 430-444 (1983)

3. Howcroft, D., Light, B.: Reflections of issues of power in packaged software selection. Information Systems Journal, 16. pp. 215-235 (2006)

4. Sabherwal, R., Newman, M.: Persistence and change in system development: a dialectical view. Journal of Information Technology, 18. pp. 69-92 (2003)

5. Moe, C.E., Risvand, A.K., Sein, M.K.: Limits of Public Procurement: Information systems acquisition. In:Wimmer, M.A., Scholl, H.J., Grönlund, Å., and Andersen, K.V. (eds.) Electronic Government - 5th International Conference, EGOV 2006. LCNS, vol. 4084, pp. 281-292. Springer Verlag, Berlin - Heidelberg (2006)

6. Bjerknes, G.: Dialectical reflection in information systems development. Scandinavian Journal of Information Systems, 3. pp. 55-77 (1991)

7. Robey, D., Ross, J.W., Boudreau, M.-C.: Learning to implement enterprise systems: an exploratory study of the dialectics of change. Journal of Management Information Systems, 19. pp. 17-46 (2002)

8. Soh, C., Kien Sia, S., Fong Boh, W., Tang, M.: Misalignments in ERP implementation: a dialectic perspective. International Journal of Human-Computer Interaction, 16. pp. 81-100 (2003)

9. Heiskanen, A., Newman, M., Similä, J.: The social dynamics of software development. Accounting, Management and Information Technology, 10. pp. 1-32 (2000)

10. Scholl, H.J.: Involving salient stakeholders Beyond the technocratic view on change. Action Research, 2. pp. 277-304 (2004)
11. Flak, L.S., Rose, J.: Stakeholder governance: adapting stakeholder theory to the e-government field. Communications of the Association for Information Systems, 16. pp. 642-664 (2005)

12. Rowley, J.: e-Government stakeholders - Who are they and what do they want? International journal of Information Management, 31. pp. 53-62 (2011)

13. Flak, L.S., Nordheim, S., Munkvold, B.E.: Analyzing stakeholder diversity in G2G efforts: Combining descriptive stakeholder theory and dialectic process theory. e-Service Journal, 6. pp. 3-23 (2008)

14. Parliament, E.: DIRECTIVE 2004/18/EC on the coordination of procedures for the award of public works contracts, public supply contracts and public service contracts. (2004)

15. Parliament, E.: DIRECTIVE 2004/17/EC coordinating the procurement procedures of entities operating in the water, energy, transport and postal services sectors. (2004)

16. Bartle, J.R., Korosec, R.L.: A Review of State Procurement and Contracting. Journal of Public Procurement, 3. pp. 192-214 (2003)

17. Boyne, G.A.: Public and Private Management: What's the difference? Journal of Management Studies, 39. pp. 97-122 (2002)

18. Moe, C.E., Päivärinta, T.: Challenges in Information Systems Procurement in the Public Sector Electronic Journal of e-Government, 11. pp. 308-323 (2013)

19. Myers, M.D.: Dialectical hermeneutics: a theoretical framework for the implementation of information systems. Information Systems Journal, 5. pp. 51-70 (1995)

20. Freeman, R.E., Harrison, J.S., Wicks, A.C., Parmar, B.L., De Colle, S.: Stakeholder theory: The state of the art. Cambridge University Press (2010)

21. Van de Ven, A.H., Poole, M.S.: Explaining development and change in organizations. Academy of Management Review. pp. 510-540 (1995)

22. Freeman, R.E.: Strategic Management: A Stakeholder Approach (Marshfield, MA: Pitman). FreemanStrategic management: A stakeholder approach (1984)

23. Clarkson, M.E.: A stakeholder framework for analyzing and evaluating corporate social performance. Academy of Management Review, 20. pp. 92-117 (1995)

24. Mitchell, R.K., Agle, B.R., Wood, D.J.: Toward a theory of stakeholder identification and salience: Defining the principle of who and what really counts. Academy of Management Review, 22. pp. 853-886 (1997)

25. Sæbø, Ø., Flak, L.S., Sein, M.K.: Understanding the dynamics in e-Participation initiatives: Looking through the genre and stakeholder lenses. Government Information Quarterly, 28. pp. 416-425 (2011)

26. Klein, H.K., Myers, M.D.: A set of principles for conducting and evaluating interpretive field studies in information systems. MIS Quarterly. pp. 67-93 (1999)