‘IT and Business Alignment.' Information Systems

Research article

To coerce or to enable? Exercising formal control in a large information systems project Jakob Heumann1, Martin Wiener2,1, Ulrich Remus3, Magnus Mähring2

1University of Erlangen-Nuremberg, Germany; 2Stockholm School of Economics, Sweden; 3University of Innsbruck, Austria

Correspondence: J Heumann, University of Erlangen-Nuremberg, Chair of Information Systems III, Lange Gasse 20, Nuremberg, 90403, Germany. Tel: +49 911 5302-801; Fax: +49 911 5302-860

Abstract In virtually every information systems (IS) project, control is exercised on multiple hierar- chical project levels. For example, senior managers exercise control over project team leaders, who in turn exercise control over distinct groups of project team members. Most prior studies have exclusively focused on one specific controller-controllee dyad. As a result, there is little understanding of how IS project control is exercised across different hierarchical levels. To close this research gap, we conducted a case study of a large IS project at a major engineering firm. Our study helps enrich the traditional mode-based typology of control with the dimension of control style, that is, the distinction between enabling and coercive control. Our research contributes novel insights to the IS control literature in three ways: (1) we find that the senior management level and the project management level differ in the use of control style but not in the use of control modes, (2) we identify several factors that influence the choice of a particular control style, and (3) we find that senior managers can influence project activities on lower levels by implementing controls that can be readily emulated by project leaders as well as transmitted through hierarchical levels with little distortion. Journal of Information Technology (2015) 30, 337–351. doi:10.1057/jit.2014.11; published online 27 May 2014 Keywords: IS project control; formal control; control style; coercive; enabling; hierarchical control transmission

Introduction

Information systems (IS) projects involve a wide variety ofinterdependent tasks, requiring individuals with diverseknowledge and skills (Kirsch, 1997, 2004). Completing such projects on time, within budget, and at acceptable quality is not an easy endeavour. Control, broadly defined as any attempt to align individual behaviours with organisational objectives (Kirsch, 1996), is one important managerial tool to master this challenge. Prior research on IS project control has studied a wide range of issues (Wiener et al., 2013), including the antecedents (e.g., Kirsch, 1996, 1997; Kirsch et al., 2002), the effects (e.g., Henderson and Lee, 1992; Nidumolu and Subramani, 2003; Maruping et al., 2009), and the dynamics (e.g., Mähring, 2002; Choudhury and Sabherwal, 2003; Kirsch, 2004) of control choices.

Although providing important insights, these earlier studies widely neglect that most IS projects comprise multi- ple hierarchical levels: (1) senior managers exercise control over (2) project team leaders, who in turn control (3) distinct groups of project team members. Here, existing studies almost exclusively focus on one specific control dyad (e.g., Henderson and Lee, 1992; Kirsch, 1996, 1997; Kirsch et al., 2002, 2010), and those studies that look at multiple dyads seem to ignore the hierarchical position of controllers (Soh et al., 2011). As a consequence of this lack of multi-level analyses, we do not know whether control actions systematically differ across hierarchical project levels. This is an important research gap, since con- troller priorities, knowledge and skills, as well as available

Journal of Information Technology (2015) 30, 337–351 © 2015 JIT Palgrave Macmillan All rights reserved 0268-3962/15 palgrave-journals.com/jit/

information, competing demands, and time constraints may all change from one level to another. Thus, we can suspect some differences in the use of IS project control across hierarchical levels (Ouchi and Maguire, 1975; Ouchi, 1978). Against this backdrop, the study examines the following research question: How is control exercised on different hierarchical levels of an IS project?

As part of our study, we are particularly interested in factors influencing the exercise of control on different hierarchical levels, as well as control transmission patterns across levels. Our study focuses on formal control, that is, outcome and behaviour control (Ouchi, 1979; Eisenhardt, 1985; Kirsch, 1996), for three reasons: First, formal control has been found to be the dominant form of control in organisations in general (Eisenhardt, 1985; Cardinal, 2001), and in IS projects in particular (Henderson and Lee, 1992; Kirsch, 1997). Second, to enhance our ability to detect potential differences in the exercise of formal control across hierarchical levels, we extend the traditional mode-based typology of control by formal control styles, namely, the distinction between coercive and enabling control (Adler and Borys, 1996; Wiener et al., 2013). Third, informal control, with its focus on norms and value- based activity and individual or group self-monitoring (Kirsch, 1996), is not necessarily transmitted through hier- archy the same way formal controls are (Ouchi, 1978).

In the next section, we summarise prior research on formal control and introduce the concepts of enabling and coercive control. We then describe the research methodology, present our results, and discuss our findings. We conclude by account- ing for study limitations and discussing future research opportunities.

Control theory In the context of IS projects, managerial control is defined as ‘attempts to ensure that individuals working on organi- zational projects act according to an agreed-upon strategy to achieve desired objectives’ (Kirsch, 1996: 1). Here, control is often thought to be dyadic in the sense that there is a controller (the person exercising control) and a controllee (the target of control) (Kirsch, 1997, 2004). Prior research distinguishes between formal and informal con- trol. Formal control relies on the application of organisa- tional authority or power to control, whereas informal control is exercised with minimal reliance on organisational authority (Soh et al., 2011; Chua et al., 2012). As already noted above, the focus of this study is on formal control, which is commonly divided into two modes: outcome and behaviour control (Ouchi, 1979; Eisenhardt, 1985; Kirsch, 1996). Because recent findings suggest that the mode-based control typology alone does not sufficiently describe control actions carried out in an IS project (Harris et al., 2009; Cram and Brohman, 2013), our study will also draw on the concepts of coercive and enabling control (Adler and Borys, 1996; Wiener et al., 2013). These concepts have been successfully applied in the accounting and management literature to explain the use of formal control systems (e.g., Ahrens and Chapman, 2004; Chapman and Kihn, 2009; Jorgensen and Messner, 2009), and have recently been suggested as a promising extension of theory on IS project control (Wiener et al., 2013).

Formal control modes With outcome control, the controller focuses on the (interim and final) outputs regardless of the process by which these outputs are achieved (Kirsch, 1996). Corresponding control mechanisms specify (e.g., project milestones) or measure (e.g., software testing) desired outputs. The controller then rewards or sanctions the controllee based on how well she or he meets the prespecified outputs (Kirsch, 1997).

When behaviour control is exercised, the controller pre- scribes specific work tasks, procedures and rules, monitors their implementation, and rewards the controllee based on the extent to which she or he adheres to these prescriptions (Kirsch, 1996). Corresponding mechanisms specify beha- viours and processes (e.g., software development methodol- ogy) or enable the controller to evaluate the controllee’s behaviour (Kirsch, 1997), by either direct observation or reporting systems (Eisenhardt, 1985). Thus, outcome control is concerned with what the controllee should accomplish, whereas behaviour control is concerned with how the con- trollee should achieve desired outcomes (Henderson and Lee, 1992, Kirsch et al., 2002).

Influencing factors Ouchi’s (1979) seminal framework of control antecedents predicts conditions under which a controller will employ a certain control mode to exercise control over a controllee. According to Ouchi’s framework, the choice of outcome or behaviour control is a function of outcome measurability and knowledge of the transformation process. High levels of outcome measurability trigger the use of outcome controls. When a controller’s knowledge of the transformation process (i.e., the ability to understand means-ends relationships) is high, she or he can use behaviour controls. Eisenhardt (1985) supplemented Ouchi’s model by arguing that high behaviour observability (i.e., the ability to gather information about controllee behaviour) also increases controller propensity to use of behaviour controls (see Table 1).

Formal control styles Important aspects regarding the use of formal control refer to the degree and type of formalisation. While prior studies on IS project control have focused on the degree of formalisation (e.g., Kirsch and Cummings, 1996; Nidumolu and Subramani, 2003), so far no empirical study has considered the type of formalisation (Adler and Borys, 1996) to explain how formal controls are exercised (Wiener et al., 2013).

Adler and Borys (1996) differentiate between enabling and coercive types of formalisation, referred to as (formal) control styles in the following (Wiener et al., 2013). Coercive control is ‘designed to force reluctant compliance and to extract recalcitrant effort’ (Adler and Borys, 1996: 69), and therefore represents a rather top-down control style (Adler, 1999; Ahrens and Chapman, 2004). In contrast, enabling control is ‘designed to enable employees to deal more effectively with [the work process’] inevitable contingencies’ (Adler and Borys, 1996: 69). Specifically, enabling control seeks to facilitate successful interaction between individuals and is therefore viewed as a more collaborative control style (Adler, 1999).

Whether formal controls have an enabling or coercive influence on controllees thus depends on how they are designed and implemented. There are four generic design

Coercive or enabling IS project control? J Heumann et al 338

principles that distinguish an enabling control style from a coercive control style (Adler and Borys, 1996; Ahrens and Chapman, 2004):

(1) Repair as design principle anticipates breakdowns of control processes and provides capabilities for fixing them. In coercive control, any deviation from controller prescriptions is seen as suspect. In contrast, enabling control facilitates responses and appreciates controllee feedback to real work contingencies.

(2) Internal transparency is concerned with the visibility of local processes. Controls designed in a coercive logic are formulated as lists of flat assertions of controllee duties. In contrast, enabling controls provide the controllee with an understanding of the rationale of the applied controls as well as feedback on performance.

(3) Global transparency is concerned with the visibility of the overall context in which controllees perform their specific tasks. In coercive control, the controller considers global transparency as a risk to be minimised. In enabling control, the controller provides the controllee with a wide range of contextual information that helps the controllee interact creatively with the broader project organisation and its environment.

(4) Flexibility refers to the controllees’ discretion over the use of control mechanisms. In the coercive logic, controls are designed to minimise reliance on control- lees’ skills and discretion. Conversely, enabling con- trol is designed to support controllees by providing them with choices and options in completing their tasks.

Influencing factors Adler and Borys (1996) discuss a number of factors that may influence the choice of a particular control style. First, asymmetries of power allow individuals in higher hierarchical positions to shape the extent and type of formal control exercised. Such asymmetries also allow controllers to more easily make controllees responsible for negative outcomes, while, at the same time, controllees can less easily claim credit for positive outcomes. Thus, Adler and Borys (1996) expect a greater reliance on coercive control when asymmetries in

power are high. Second, performance pressuresmay play a role in the selection of control styles. However, Adler and Borys are indecisive as to whether such pressures facilitate a coercive or an enabling control style. On the one hand, they argue that in the presence of performance pressures an enabling control style is used to ensure adaptiveness. On the other hand, they acknowledge that performance pressures may legitimise power asymmetries and thus authorise a more coercive control orientation. Third, legitimacy concerns may encourage controllers to use an enabling control style because a coercive style may not be appropriate in the eyes of the controllee, invoke conflict, and eventually trigger negative consequences for the organisation. Finally, in settings where task complexity is high, individuals are increasingly faced with learning rather than doing tasks. The latter demands higher skill levels and discretion from them, and thus control that enables rather than coerces.

Extended control typology: Combining formal control modes and styles In this study, we integrate the notion of control styles (Adler and Borys, 1996; Wiener et al., 2013) into the traditional mode-based typology (e.g., Ouchi, 1979; Eisenhardt, 1985; Kirsch, 1996, 1997) used by most prior research on IS project control. Distinguishing between control styles within the two formal control modes potentially offers a more nuanced understanding of how formal control over IS projects is exercised in practice (Wiener et al., 2013). For example, the controller may need to decide on a specific software implementation procedure. Here, the controller may either specify in detail a specific sequence of steps to be followed and then force the controllee to adhere to this sequence (coercive behaviour control); or the controller may first provide the controllee with relevant context information, discuss options of leveraging existing best practices the controllee is already using, and then decide on the final implementation procedure (enabling behaviour control). Similarly, the controller may need to adjust the delivery date of a software module due to changing user requirements. Here, again, the controller may either request the controllee to deliver the software based on the new schedule (coercive outcome control); or the controller may

Table 1 Formal control modes and mechanisms

Formal control modes

Outcome control Behaviour control

Key characteristics ● Specify and evaluate outputs (both interim and final)

● Reward (or sanction) the controllee based on the quality and timing of delivered outputs

● Specify and evaluate procedures, rules, and processes ● Reward (or sanction) the controllee based on her or his

adherence to the specified behaviours

Influencing factors ● Measurability of controllee outputs ● Controller’s knowledge of the transformation process ● Observability of controllee behaviour

Examples of control mechanisms

● Project plan ● Defined project milestones ● Weekly status meetings ● Expected level of performance

● Work assignment ● Assignment of roles and responsibilities ● Direct monitoring ● Software development methodology (e.g., agile vs

waterfall)

Coercive or enabling IS project control? J Heumann et al 339

provide the controllee with information as to why delivery dates changed, ask for controllee feedback on whether the new schedule is realistic, and then adjust the schedule if necessary (enabling outcome control). Table 2 shows the extended framework of formal control.

Hierarchy and control Control on different hierarchical levels Virtually every IS project consists of multiple hierarchical levels. However, most prior studies have either focused on the control relationship between the IS manager and the project leader (e.g., Kirsch, 1996, 1997; Kirsch and Cummings, 1996), or the project leader and the project team members (e.g., Henderson and Lee, 1992; Kirsch et al., 2010). Other studies seem to neglect the presence of hierarchical differences among controllers by focusing on one ‘principal controller group’ while conceptualising all other project members as controllees (e.g., Soh et al., 2011; Chua et al., 2012).

Although no single study has so far systematically com- pared how IS project control is exercised across different management levels, there seems to be an implicit assumption in the literature that control actions and portfolios do not differ between levels. However, earlier studies on organisa- tional control suggest that high consistency of managerial control across levels is unlikely (e.g., Franklin, 1975; Ouchi and Maguire, 1975; Ouchi, 1978), and that patterns of leader- ship behaviour strongly differ between hierarchical levels (Katz and Kahn, 1966). One reason for this disconnect between different streams of the literature on control may be that most prior research relies on the traditional classification into modes as the only dimension to analyse control actions in an IS project. However, given the multi-dimensional character of control practices (Snell, 1992; Kirsch, 2004), adding other dimensions, such as the dimension of control style, may be useful in order to uncover differences in how control is exercised across hierarchical levels.

Control transmission through hierarchical levels One major problem in any organisation with multiple levels is that control often gets distorted as it moves through the hierarchy because of the hierarchical distance and the number of nodes that control has to travel before impacting operative behaviour (Ouchi, 1978). Prior research in the context of ‘ordinary’, non-temporary organisations found that outcome control is relatively less susceptible to hier- archical attenuation than behaviour control (Ouchi, 1978). However, these results may not be transferrable to the IS project context as such projects have distinctively different characteristics that change the conditions for control activ- ities. IS projects evolve over a finite lifespan during which a non-repetitive task is completed, and thus are temporary in

nature (Bechky, 2006). In this situation, managers often cannot rely on established corporate control practices. This further intensifies the problem of control transmission (loss) and increases the need for enhancing our under- standing about the mechanisms whereby higher-level man- agers can exert influence on lower levels.

Research methodology We chose to examine a single case to study in depth (1) how formal control is exercised on different hierarchical levels, and (2) what factors influence the exercise of formal control on the respective levels of a large IS project. The approach used in this study can be characterised as ‘soft positivism’ (Kirsch, 2004), and is guided by the processes described in Eisenhardt (1989), Yin (2009), and Miles and Huberman (1994). This means that our study is designed to examine pre-identified constructs as in the positivist view, but also draws from interpretivists and grounded theorists to surface new constructs.

Site description Our research was conducted at a major engineering firm headquartered in Germany. The firm designs, manufactures, and sells industrial technology on a global scale. In 2007, the firm embarked on a strategic product lifecycle management (PLM) project. Previously, each of the six business units (BUs) involved in the project operated its own customised PLM system. The new PLM system was to replace the ageing systems in the BUs as well as to integrate production processes across BUs in an effort to facilitate global collaboration and improve product quality. The estimated project budget was 160 million euros.

The new PLM system was to be rolled out in four major system releases, with each release representing a fully functioning system in its own right. The third system release was considered a major success throughout the entire project organisation. In our study, we focus on this release for two key reasons. First, the third release of the new system represented the largest release, which comple- tely replaced the legacy systems used by 10,000 end users in more than 100 locations in 15 countries and engaged more than 200 persons. Therefore, the third release seemed to be representative of the circumstances and conditions existing in large, complex IS projects (Yin, 2009). Second, we preferred real-time analysis of the third system release to retrospective sensemaking of earlier releases in order to ensure that study participants accurately recalled critical events and reliably reported on their perceptions of control actions. Notably, the first and second system release had already been finished in 2009 and 2011, respectively. Con- sequently, for these releases, the actual events related to control might have been misremembered or misinterpreted

Table 2 Formal control modes and styles

Formal control modes

Outcome Behaviour

Formal control styles Enabling Enabling outcome control Enabling behaviour control Coercive Coercive outcome control Coercive behaviour control

Coercive or enabling IS project control? J Heumann et al 340

by the participants. In addition, at the time we did our study, the fourth system release had not yet started. Overall, we believe that our clear focus on the third release of the new PLM system allows for an in-depth, multi-level analysis of control actions without sacrificing the analytic generalisability of our results to other system releases and large-scale IS projects (cf. Lee and Baskerville, 2003; Yin, 2009).

We were granted access to project staff from all hierarchical levels, enabling us to comprehensively study the exercise of formal control. Two senior managers were responsible for controlling 11 team leaders. The senior managers were supported by a project management office, which facilitated meetings, created project management documents, and per- formed other support functions. The team leaders were responsible for controlling their respective team members, who were engaged in a variety of tasks, such as programming, data migration, testing, implementation, and training. The average team size was 18.

We focused on the control relationship between the senior management and the project management level as well as the control relationship between the project management and the project team level. This distinction is in line with Mähring (2002), who differentiates between control over the project (exercised on the senior management level), and control within the project (exercised on the project management level). Figure 1 shows the organisational chart of the studied IS project depicting the various stakeholders and their formal relationships as controllers and controllees.

Data collection Consistent with best practices in case research, we obtained data from multiple sources (Eisenhardt, 1989; Yin, 2009). Figure 2 provides an overview of the data collection process.

Kick-off workshop Before beginning with the main data collection, we conducted a two and a half-hour workshop with the senior managers to learn about the history and context of the project as well as key events and issues. This allowed us to gain a deep under- standing of the project and helped us prepare the interview guide. The senior managers also provided us with archival data, including project progress reports, project management plans, presentation slides, as well as documentation concern- ing the project members and their mandates.

Qualitative interviews The main data collection consisted of 30 semi-structured, qualitative interviews with representatives from all hierarchi- cal levels and functional teams. Before each interview, we reviewed our notes and transcripts of previous interviews and discussed arising issues with the interviewees. We started the interview by asking interviewees about their role in the project, the tasks in which they were involved, and the deliverables for which they were responsible. We continued by asking them about their perceptions of the controls used in the project. To understand how senior management exercised control over project management, we interviewed senior

Senior manager 1

Team leader 1

Senior management level

(Controllers)

Senior manager 2

Team leader 2

Team leader 3

Team leader 11

Team members

Team members

Team members

Team members

… Project

management level (Controllers & controllees)

Project team level

(Controllees) …

Figure 1 Hierarchical project control relationships

Phase 1: Kick-off workshop

(July 2012)

Phase 2: Semi-structured interviews (August –October 2012)

Phase 3: Online survey

(October 2012 –January 2013)

Phase 4: Follow-up workshop

(May 2013)

Senior management presentation of project context, history, and future

Detailed presentation of research focus, goals, and procedure

On site face-to-face interviews with both senior managers, 10 team leaders, and 18 team members

Quantitative questionnaire filled in by both senior managers, 5 team leaders, and 32 team members

Presentation and interpretation of key results

Discussion of “lessons learned”

Qualitative phase Qualitative phaseQuantitative phase

•

•

• • •

•

Figure 2 Overview of data collection process

Coercive or enabling IS project control? J Heumann et al 341

managers about the mechanisms used to control team leaders (control exercised), and asked team leaders about their perceptions of the controls exercised by senior managers (control recognised). Similarly, to examine how control was exercised between the project management level and the project team level, we asked team leaders about the mechan- isms used to control their respective team members (control exercised), and interviewed team members about their percep- tions of the controls exercised by their respective team leader (control recognised). The distinction between exercised and recognised control is based on Ouchi’s (1978) distinction between control given and received. By collecting and triangu- lating data from both sides of the control dyad, we increased our ability to make valid and well-substantiated conclusions. Finally, we asked interviewees to describe problems encoun- tered during the project, steps taken to resolve these problems, their personal relationships with colleagues, as well as their perceptions of project performance.

The interview language was German for all interviewees, except for two team members with an Indian background, where the interview language was English. All interviews were conducted in person by two researchers, the first author together with a research assistant. Following the recommended practice of assigning interviewers different roles (Eisenhardt, 1989; Dubé and Paré, 2003), one researcher would use the interview guideline to run the interview, while the other researcher listened, took notes, and asked for clarifications when necessary. All interviews were tape-recorded and tran- scribed. The transcripts were aggregated into a case protocol that comprised more than 260 pages of text and more than 130,000 words. The transcripts were encoded using the software NVivo. Table 3 provides an overview of the interviews.

Quantitative questionnaire In addition to the qualitative data, which was our main source of data, we also collected quantitative data. Next to triangula- tion purposes, these data particularly helped us to make inferences on how formal control modes transmitted through the hierarchical levels of the IS project organisation. To develop the survey instrument (see Table A1 in the appendix), we adapted items from previous control studies (Kirsch et al., 2002; Tiwana and Keil, 2009) to the context of our study. All items were measured on 7-point Likert scales with ‘strongly agree’ and ‘strongly disagree’ anchors. Controllers (senior managers and team leaders) were asked about the extent to which they exercised outcome and behaviour control. Con- trollees (team leaders and team members) were surveyed on their perceptions of the extent to which outcome and behaviour control was used by their controller counterpart.

The two senior managers, five team leaders, and 32 team members from nine teams filled in the questionnaire.

Follow-up workshop The data collection process was complemented by a 2-hour workshop with the senior managers to interpret the findings of the study. This approach allowed us both to validate the study results and to gain additional insight into how formal control was exercised in the project.

Data analysis We approached our qualitative analysis with a deep under- standing of the theoretical domain (‘IS project control’) of our study. We were particularly interested in identifying the composition of individual control portfolios as well as how these portfolios were exercised along the project hierarchy. We therefore sought to code control mechanisms used, and classified them by control modes based on previous classifica- tions in the literature (e.g., Kirsch, 1996, 1997).

During the coding process, we discovered that controllers differed in their approaches to implement formal control, but not in their use of control modes. In an effort to meaningfully interpret our findings, we employed the distinction between coercive and enabling styles of formal control (Wiener et al., 2013). On the basis of the definitions of the four features differentiating an enabling from a coercive type of formalisa- tion (Adler and Borys, 1996), we developed additional coding guidelines for each control style, and then recoded the data. For example, in the weekly status meetings, senior managers provided the team leaders with a wide range of information about critical incidents and events to enable them to better understand how their actions were related to the broader project organisation. The feature of global transparency underlying these actions was a clear indicator of an enabling control style. In contrast, some team members commented that they were not asked about their perceptions and opinions on how certain tasks should be accomplished, impairing their ability to act flexible and adapt to real work contingencies. The absence of repair and flexibility features pointed towards a rather coercive control style.

In our coding, we explicitly took into account the multi- level context by considering, for each mechanism, the initiator (controller) and the target (controllee) of control actions. The first author conducted the coding. Results and experiences were discussed with the other authors to resolve ambiguities and uncertainties. This approach helped consolidate the coding scheme and ensured that codes were applied consis- tently across the interview data. Table A2 in the appendix

Table 3 Breakdown of interviews

Hierarchical level Interviewee # of distinct interviews (from # of teams)

Total (average) interview length (in min)

Senior management Programme manager 1 79(79) Release manager 1 61(61)

Project management Team leaders 10(10)a 500(50) Project team Team members 18(10)a 646(36)

TOTAL 30(10) 1286(43) aThe leader of the ‘reporting’ team and the members of the ‘architecture’ team were not available for interviews.

Coercive or enabling IS project control? J Heumann et al 342

shows an exemplary extract of the coding table, which was created to organise and analyse the coded control actions (Miles and Huberman, 1994).

In a subsequent analysis step, we applied basic descriptive statistics to the quantitative survey data. Here, we refrained from carrying out conventional statistical tests on the data because of the relatively small sample size (N= 39), especially on the senior and project management level. Using quantita- tive data to complement and enhance qualitative data leads to richer and more reliable results (Mingers, 2001; Dennis and Garfield, 2003).

Results In this section, we present (1) how formal control was exercised and (2) what factors influenced the exercise of formal control (a) between the senior and project manage- ment levels as well as (b) between the project management and team levels.

Control between senior management and project management levels The two senior managers pursued different roles. The pro- gramme manager was responsible for overseeing the different releases and primarily concerned with managing the interface between the project organisation and the BUs, whereas the release manager was responsible for the day-to-day manage- ment and control of the team leaders. Both senior managers were members of the steering board and regularly participated in meetings with BU and top management representatives. The senior managers negotiated the project scope document that specified the project goals and objectives with the BU representatives. When senior managers and BU representa- tives agreed on a final version all parties signed it. The project plan derived from the project scope document was the most important control mechanism used by the senior managers. The project plan stated the interim milestones and deliver- ables, and was made accessible to all project members via Microsoft SharePoint. After the initial project plan was ready, senior managers asked the team leaders to give feedback on the feasibility of prespecified milestones and, if necessary, adapted the project plan accordingly.

The project plan is the most important mechanism. We did the fine-tuning of the project plan together with the team leaders […]. As soon as the project plan was plausible and everybody knew how it would work, I went to the steering board and the BUs to present to them how we planned to proceed. Often, I did another feedback-loop with the team leaders before the project plan was ultimately specified.

(Release manager)

The senior management level thus included the concept of repair as an important feature in its control strategy. One important reason for doing so was that it was difficult to precisely prespecify milestones and deliverables that fitted the specific work processes of each team. Many teams involved more than 20 members who worked on a wide variety of interdependent tasks. Thus, while senior managers were responsible for preplanning, they were also dependent on the team leaders’ assessment of local circumstances when crafting the project plan.

The release manager must coordinate with each team leader. For example, if he says the time frame [for the next delivery] is three months then he would ask us how the different work packages were connected and whether delivery in time was possible at all.

(Team leader infrastructure)

We discussed whether we needed more time, whether certain aspects [of the plan] had to be changed, and how this would fit into the senior management’s overall program. […] We had to mutually agree upon the final plan. It’s no use, if there is a plan I can’t fulfil.

(Team leader implementation)

After the project plan was specified and clearly communicated to all team leaders, the senior managers set up weekly status meetings where project milestones and deliverables were monitored and team leaders provided status reports. While these meetings served as a mechanism for senior management to assess team leaders’ behaviours and outputs, they were also used as a means to inform team leaders about the work progress in other teams, thereby enabling them to put their work into context. Moreover, the senior managers would begin meetings with providing the team leaders with informa- tion about issues discussed in the steering board meetings as well as critical events and potential upcoming problems. Thus, this control mechanism was designed in ways that enhanced team leaders’ understanding of work processes among distinct teams (internal transparency), as well as how these work processes fitted into the project as a whole (global transparency).

[In the weekly meetings], I briefly presented news and novelties: information from the steering board, changes to plans, the critical points for next week; so that everybody understood why, for example, there was some more pressure coming from this or that corner. Then, [the team leaders] presented their current status […] . Here, the objective was not a one-way communication but to make sure that every- body informed each other.

(Release manager)

Beside weekly meetings, the two senior managers also held daily stand-up meetings, where they checked the current work status and where all team leaders exchanged relevant informa- tion and discussed critical issues for the day.

We have this daily meeting in the morning, where team leaders can exchange information: ‘What are important issues we need to solve? Do you have information regarding … ?’ This way, everybody knows what’s going on.

(Team leader migration)

The team leaders found these control mechanisms very important considering the high task complexity they were facing. For example, the team leaders responsible for migration and architecture management needed to be informed about the work status and progress in all the other teams to avoid setbacks and schedule over- runs. This was also a major reason why the senior managers exercised controls involving features of internal transparency.

Coercive or enabling IS project control? J Heumann et al 343

There were often discussions erupting [during the weekly status meeting] because [the teams] are so strongly inter- linked. For example, if the migration team changes some- thing, then this affects the architecture management team, and vice versa, and both, in turn, affect the interfaces team. It was really productive having this information platform [i.e., the weekly meeting], where everybody compared notes.

(Release manger)

By having these daily meetings, we were able to cope with the project’s complexity – across all teams.

(Team leader rollout)

There were two overarching reasons why the senior managers used an enabling control style when implementing formal controls. First, they thought that an enabling control style (e.g., informing controllees about the broader project and its environment) was critical to the success of the project. Second, beside performance considerations, legitimacy concerns also played an important role for the senior managers’ preference of an enabling control style. They believed that an overly coercive control style would not be accepted by the team leaders, lead to mistrust, and stifle motivation.

From my point of view, it is very important for the success of the project that everybody knows why we move towards a certain direction, why we do things as we do.

(Release manager)

An autocratic style, in the sense that ‘I tell you what you must do and if you want to know why, be quiet and work,’ doesn’t work – it would not be accepted.

(Release manager)

However, there were also few occasions where the senior management level switched to a coercive control style as a consequence of major performance problems in one of the teams. The senior managers then closely monitored the work process, attended internal team meetings, and coerced effort by making clear and unambiguous announcements of what needed to be done. When ‘calmer waters’ were reached again, they switched back to an enabling control style.

Control is top-down if there are severe performance problems. When there is a crisis and there are things that haven’t been done properly, then it goes top-down.

(Team leader training)

Control between project management and project team levels As most teams involved many team members, the team leaders would typically create the role of a so-called ‘topic leader’ who would be the primary contact person for all team members working on a related task. Here, structuring the team hierarchy was an important control mechanism as it helped clarifying roles and responsibilities. The team members were primarily responsible for solving tickets that specified bug fixes and change requests. The roles and responsibilities as well as the tickets were documented in a list (on Microsoft Share- Point) accessible to all team members. The team members looked up the list and then worked on the tickets assigned to

them by the team leader. The assignment of tickets to team members was based on predefined roles.

We have a very clear process regarding fixes and all sorts of implementation tasks. Often, we receive a change request [i.e., ticket]. This change request will be checked and assigned the status ‘development’. Based on these tickets, implementa- tion tasks are generated automatically. The tasks are assigned to [team members] and patches […]. When I come to work on Monday, I already know which one will be the next patch. I open the list in the intranet, and then I see directly what I will have to work on.

(Team member 1 implementation)

Tickets were classified according to their criticality: (1) tickets that could severely deteriorate the quality of the final system required management involvement, and all steps and measures had to be precisely documented by the responsible team member(s); and (2) tickets that had only a limited impact on system functionality were solved single-handedly by team members. The classification of tickets into the above-mentioned categories minimised reliance on controllees’ discretion (lack of flexibility). Because executing tickets was more of a routine task, the process itself was rarely controlled. In contrast, the ticket system conveyed to the team members what rather than how things had to be done (i.e., outcome control).

I assigned tasks, for example, the ticket retesting. Then, I communicated to the team members that this amount of tickets had to be tested by this date […]. [The team members] then focused on their assigned tasks, and I was informed about the status over the course of the day.

(Team leader testing)

The […] benchmark was the number of tickets fixed. This was clearly communicated by [the team leader]: ‘You have your ticket, solve the problem!’ When there were any problems and the problems weren’t fixed, he stepped in.

(Team member 1 migration)

Overall, controls exercised on the project management level predominantly obeyed a coercive logic. The project plan as well as the corresponding milestones and deliverables defined much of the control actions targeted at the team members. The team leaders communicated the delivery dates to the team members and checked whether the tickets would be delivered on time in order to meet the higher-level milestones specified in the project plan. The team members were provided little discretion in interpreting controls and deviations from the plan had to be avoided by all means (lack of flexibility).

The milestones are carved into stone. Especially the time schedule is more than tight. There is absolutely no room for deviance.

(Team member 2 testing)

Efficiency concerns in terms of adherence to the time schedule were an important factor influencing the control style. Time pressures legitimised lower levels of team member involve- ment and authorised a more coercive orientation of control.

The overall project management […] was relatively top- down. There was a project plan that had to be fulfilled.

Coercive or enabling IS project control? J Heumann et al 344

[The plan] was designed from the perspective of the [senior management level] or based on other external time pressures. We had to cope with this plan. Direct interaction in the sense that ‘you tell us how much time you need and we adapt the project plan accordingly’ did not exist from my point of view.

(Team member 1 migration)

In later phases of the project when the system was to be rolled out, behaviour controls became more prominent. A detailed rollout plan was developed to facilitate the smooth introduc- tion of the new system. Due to the high complexity of implementing the new system in a ‘big-bang’ fashion, the plan comprised a total of more than 250 steps to be followed precisely.

[In the rollout plan] literally every single activity was meticulously specified – a plan about what needed to be done precisely; every single installation routine with start date and delivery date.

(Team leader rollout)

Here, again, efficiency concerns were the major reason why control was exercised in a coercive logic. The complete rollout had to be done in 2 weeks and was targeted at more than 10,000 end users working in different BUs and countries. Schedule overruns would have caused considerable costs and production downtimes. Therefore, no deviation from the plan was allowed.

Much to the team members’ regret, we tracked very intensely. It was required that the system would not be down more than 16 days. In the worst case this means 16 days production downtime.

(Team leader rollout)

Taken together, our case indicates that the senior and project management levels differed in their use of control style. While senior managers relied on a more enabling control style, project managers adopted a more coercive style. We now turn to discussing the findings from our in-depth case study.

Discussion The key contributions of this study lie in three main discov- eries. First, by distinguishing between enabling and coercive control styles, we were able to identify differences in the use of formal control across the hierarchical levels of an IS project. Second, we identified a number of factors that influence the selection of a particular control style. Third, we found that senior managers can influence project activities on lower levels by enabling team leaders and by implementing controls that can be readily transmitted through the organisational hier- archy of the project.

Differences in control across hierarchical levels Our results suggest that both the senior management level and the project management level relied on a portfolio of outcome and behaviour controls. One important control mechanism was the project plan, which stated all milestones and deliver- ables and was used as a basis for regular feedback loops between the senior and project management level (repair). In the weekly meeting, all team leaders presented their work

status and discussed prior and upcoming issues. Given the dynamic nature of the project, senior managers also held daily stand-up meetings. These two types of meetings were designed in a way that enabled team leaders to understand how local processes worked within other teams and how these processes fit into the organisation as a whole (internal and global transparency), while also allowing senior managers to measure and evaluate the project’s progress towards the prespecified milestones. However, senior managers also coerced reluctant compliance from controllees and personally supervised tasks when performance deteriorated.

While the senior management level implemented formal control primarily in an enabling fashion, the project manage- ment level mostly followed a coercive logic in the implementa- tion of formal controls. Commonly used controls structured the team hierarchy and specified rules and procedures with regard to the way in which tickets should be handled. Team members were provided little discretion (absence of flexibility), and work assignments took the form of a one-way commu- nication process (absence of repair). Moreover, a detailed rollout plan specifying each step for the introduction of the new system was developed. Here, team members were not allowed any deviations from the prespecified plan (absence of flexibility). Apart from these behaviour control mechanisms, team leaders also relied heavily on the project plan and the corresponding milestones as outcome control mechanism.

Collectively, the results of our study provide new insights on how to exercise control over the project (i.e., from a senior manager perspective) as compared to control within the project (i.e., from a project team leader perspective) (Mähring, 2002). While we did not observe significant differ- ences in the use of control modes across hierarchical levels, there was a notable difference in the use of control styles. Specifically, the control relationship between the senior man- agement and project management level was characterised by an enabling control style, whereas the relationship between the project management and project team level was characterised by a coercive control style. Altogether, our results demonstrate that it is only through the lens of control style that we can see a clear difference in the exercise of formal control across hierarchical levels. Thus, extending the mode-based typology of control by also distinguishing between control styles offers a more nuanced understanding of how formal control is exercised (Wiener et al., 2013). This finding may serve as an important springboard for future research taking into account that it is often difficult to recognise and classify control actions by only distinguishing control modes (Kirsch, 1997).

Factors influencing the choice of control style We were able to identify four overarching factors influencing the choice of a particular control style (i.e., task complexity, legitimacy concerns, performance considerations, and perfor- mance/efficiency concerns), thereby providing a more encom- passing understanding of factors involved in shaping the exercise of formal control.

There were three important factors that caused senior managers to adopt an enabling control orientation. First, the choice of an enabling control style was driven to a great extent by task complexity. Team leaders were responsible for a wide range of tasks, and many of them were interlinked, requiring senior managers to design controls that would allow team

Coercive or enabling IS project control? J Heumann et al 345

leaders to be informed about each other’s activities. Second, providing controllees with information about the project context (global transparency) enabled ‘local’ adaptiveness and problem solving, which were perceived as critical factors for the success of the project. Thus, performance considerations seem to impact the selection of control styles as well. Third, consistent with Adler and Borys (1996), legitimacy concerns were found to play an important role when exercising formal control. Because the senior management did not consider coercive control to be a legitimate way of exercising control over subordinates, they tended towards a more enabling control style. This finding also shows that control choices are not only driven by task characteristics as well as efficiency and effectiveness concerns, but also by social aspects. Finally, while an enabling control style was clearly dominant, senior man- agers shifted towards coercive control when performance problems became visible. In order to get the project back on track, they enforced procedures and rules that provided little room for discretion and flexibility. Such performance pro- blems seemed to legitimise power asymmetries and authorise a more coercive control orientation (Adler and Borys, 1996).

While we were able to identify various contextual factors influencing control over the project, control within the project was largely influenced by one prominent factor, namely efficiency concerns. Here, the pressure to be on time was the major driver of a coercive control style. Tight project sche- dules meant that team members were not allowed to deviate from the prespecified plan. The same was true for the system rollout, where deviations from the prespecified process could have resulted in schedule overruns and thus major production losses for the firm.

From a practical point of view, our results show that an enabling control style can increase senior managers’ ability to handle project activities that lie outside of their normal expertise and direct control. Furthermore, our results suggest that managers have to continuously adjust their control style to the project context to safeguard the project from drifting.

Transmission of control across hierarchical levels The analysis of our quantitative data offered interesting insights regarding the transmission of formal control modes across the hierarchical levels of the project organisation (Ouchi, 1978). Table 4 shows the means and standard devia- tions (SD) for outcome control exercised and recognised as well as behaviour control exercised and recognised for each hierarchical level.

The problem of control transmission (loss) comprises two important phenomena: control (1) (inter-level) distortion and (2) emulation (Ouchi, 1978). Control distortion deals with the

potential problem that control exercised by higher managerial levels can get distorted as it moves down the hierarchy because of the hierarchical distance that control has to travel before impacting behaviours on the operational level (Ouchi, 1978). Control distortion can be illustrated by contrasting control exercised by the controller with control recognised by the controllee, and therefore measures the extent to which con- troller and controllee perceptions of the applied control modes are congruent. Our results show that control distortion was more pronounced between the project management and team level than between the senior and project management level (see Figure 3).

Table 4 Formal control perceptions by hierarchical level

Level Senior management (n= 2) Project management (n= 5) Project team (n= 32)

Variables Mean SD Mean SD Mean SD

Outcome control exercised 5.67 1.07 5.70 1.09 Behaviour control exercised 5.00 1.07 5.35 1.18 Outcome control recognised 5.47 1.11 4.96 1.53 Behaviour control recognised 5.40 1.05 4.72 1.37

Note: N= 39; ‘1’ = Very low perceptions (strongly disagree) to ‘7’ = Very high perceptions (strongly agree).

5.7

5.5

5.0

5.4

4.0

4.5

5.0

5.5

6.0

Senior management level (control exercised)

Project management level (control recognised)

Outcome control Behaviour control

5.7

5.0 5.4

4.7

4.0

4.5

5.0

5.5

6.0

Project management level (control exercised)

Project team level (control recognised)

Outcome control Behaviour control

Figure 3 Control distortion between hierarchical levels

Coercive or enabling IS project control? J Heumann et al 346

Control emulation refers to the extent to which subordi- nates (team leaders) reuse the portfolio of control modes employed by superiors (senior managers) when structuring their own control portfolio for steering desired behaviors of their subordinates (team members). Thus, control emulation illustrates the congruence with which control modes are used on different hierarchical levels within the project. We analysed the extent of control emulation by contrasting control recog- nised and control exercised on the project management level. That is, we compared the degree of formal control used by senior managers as recognised by the team leaders (control recognised) with the degree to which team leaders exercised formal control over team members as perceived by themselves (control exercised).

As depicted in Figure 4, there was only little difference in means between outcome control recognised (5.5) and exer- cised (5.7), and no difference in means between behaviour control recognised (5.4) and exercised (5.4). These observa- tions indicate an emulation effect on the project management level with regard to the use of both outcome and behaviour

control. While these observations are interesting as such, our data do not indicate what the ‘ideal’ emulation of control modes looks like. In fact, there are theoretical arguments for changes in control modes to occur across hierarchical levels (Ouchi, 1978).

Our findings regarding the transmission of formal control provide some important implications for practice. Little research has been conducted so far to challenge Nealey and Fiedler’s (1968) long-standing claim that ‘one can do little more than speculate about the mechanisms whereby the higher-level manager exerts influence two or more levels below him’ (p. 324). The study at hand takes a first step in enhancing our knowledge on this issue by showing (1) that senior managers can influence work activities on lower levels by using controls that can be readily emulated on the project management level, and (2) that senior managers have to take into account the problem of control distortion when selecting controls that need to be exercised across levels. Here, some control mechanisms such as the project plan may serve as boundary objects. Boundary objects ‘are plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites’ (Star, 1989: 393). Controls that function as boundary objects can thus help foster control emulation and mitigate control distortion. Integrating research on boundary objects into the control field could open up a new frontier in control research. Furthermore, future research could examine the problem of control distortion in more detail by specifically considering the role of control styles. For example, a coercive control style that provides less transparency on the use of control mechanisms could lead to higher control distortion. This might also explain the higher divergence in control perceptions between the project management level and the project team level. Figure 5 outlines our main results.

Limitations and future research The results of our study should be interpreted with the following four limitations in mind, which also offer promising

5.5

5.7

5.45.4

4.0

4.5

5.0

5.5

6.0

Project management level (control recognised)

Project management level (control exercised)

Outcome control Behaviour control

Figure 4 Control emulation on project management level

D istortion of control m

odes

Senior manager 1

Team leader 1

Senior management level

(Controllers)

Senior manager 2

Team leader 2

Team leader 3

Team leader 11

Team members

Team members

Team members

Team members

Project management level

(Controllers & controllees)

Project team level

(Controllees)

…

Enabling control style

Task complexity Legitimacy concerns

Performance considerations

Coercive control style

Efficiency concerns

Emulation of control modes

Figure 5 Outline of key results

Coercive or enabling IS project control? J Heumann et al 347

avenues for future research. First, we focused on hierarchical control relationships. In contrast, lateral control relationships (e.g., between team leaders or within a project team) were excluded from the study scope. Examining how control is exercised in such relationships and comparing the gained insights to how control is exercised in hierarchical relation- ships is likely to reveal interesting findings (cf. Kirsch et al., 2002).

Second, we did not explicitly examine the effects of selecting a particular control style. For example, our results suggest that controllers may shy away from using coercive control due to potential negative effects on controllee motivation and satis- faction. Moreover, our results suggest that fostering transpar- ency – an important feature of enabling control – could be a key determinant of control effectiveness and ultimately project success. Prior research on formal control systems in various management contexts has already shown that formal control exercised in an enabling fashion allows organisations to better manage and balance the tension between efficiency and adaptiveness goals (Ahrens and Chapman, 2004; Jorgensen and Messner, 2009), which is arguably a key challenge in IS projects (Tiwana, 2010). We leave it to future research to examine the attitudinal outcomes of enabling and coercive control in more detail as well as their impact on different performance dimensions.

Third, we did not incorporate informal control in our analysis. For example, Chua et al. (2012) find that controllers can deploy formal control to build social capital, thereby providing an environment conducive for building and lever- aging informal control. From a control style perspective, Chua et al.’s results could provide interesting insights into the interplay between enabling and coercive formal control and informal control in IS projects; it could for example be hypothesised that enabling formal control is more likely to foster the emergence of social capital since it is more likely to provide a basis for interaction and joint problem solving than coercive control.

Fourth, we found initial evidence on why and how the choice of a particular control style changes over the course of an IS project. For example, performance problems caused senior managers to shift from an enabling control style towards a more coercive style. Our study, however, cannot conclusively determine whether this pattern is caused by psychological factors (e.g., controllers fearing blame for a possible failure they are responsible for), or whether it is a (rational) result of controllers having sufficient task expertise to actually be able to effectively ‘take over the reins’ when a project comes adrift. Investigating dynamics in control styles might be another fruitful path to extend research on IS project control.

Conclusions Our study examined how formal control is exercised across multiple hierarchical levels in a large IS project. Contrasting how control was exercised on the senior management, project management, and project team level, we found cross-level differences in the use of control styles, but not in the use of control modes. These differences in control style are explained with distinct contextual factors prevalent on each level. Over- all, our results demonstrate that the mode-based typology of control oversimplifies control practices in IS projects.

Here, incorporating the dimension of control style into the traditional typology enables a richer and more precise under- standing of control actions. In addition, we address the important but understudied problem of control transmission, thereby also contributing important insights to the question of how senior managers can exercise effective control over large and complex IS projects.

References

Adler, P.S. (1999). Building Better Bureaucracies, Academy of Management Executive 13(4): 36–47.

Adler, P.S. and Borys, B. (1996). Two Types of Bureaucracy: Enabling and coercive, Administrative Science Quarterly 41(1): 61–89.

Ahrens, T. and Chapman, C.S. (2004). Accounting for Flexibility and Efficiency: A field study of management control systems in a restaurant chain, Contemporary Accounting Research 21(2): 271–301.

Bechky, B.A. (2006). Gaffers, Gofers, and Grips: Role-based coordination in temporary organizations, Organization Science 17(1): 3–21.

Cardinal, L.B. (2001). Technological Innovation in the Pharmaceutical Industry: The use of organizational control in managing research and development, Organization Science 12(1): 19–36.

Chapman, C.S. and Kihn, L.A. (2009). Information System Integration, Enabling Control and Performance, Accounting, Organizations and Society 34(2): 151–169.

Choudhury, V. and Sabherwal, R. (2003). Portfolios of Control in Outsourced Software Development Projects, Information Systems Research 14(3): 291–314.

Chua, C.E.H., Lim, W.-K., Soh, C. and Sia, S.K. (2012). Enacting Clan Control in Complex IT Projects: A social capital perspective,MIS Quarterly 36(2): 577–600.

Cram, W.A. and Brohman, M.K. (2013). Controlling Information Systems Development: A new typology for an evolving field, Information Systems Journal 23(2): 137–154.

Dennis, A.R. and Garfield, M.J. (2003). The Adoption and Use of GSS in Project Teams: Toward more participative processes and outcomes, MIS Quarterly 27(2): 289–323.

Dubé, L. and Paré, G. (2003). Rigor in Information Systems Positivist Case Research: Current practices, trends, and recommendations,MIS Quarterly 27(4): 597–635.

Eisenhardt, K.M. (1985). Control: Organizational and economic approaches, Management Science 31(2): 134–149.

Eisenhardt, K.M. (1989). Building Theories from Case Study Research, Academy of Management Review 14(4): 532–550.

Franklin, J.L. (1975). Down the Organization: Influence processes across levels of hierarchy, Administrative Science Quarterly 20(2): 153–164.

Harris, M.L., Collins, R.W. and Hevner, A.R. (2009). Control of Flexible Software Development under Uncertainty, Information Systems Research 20(3): 400–419.

Henderson, J.C. and Lee, S. (1992). Managing I/S Design Teams: A control theories perspective, Management Science 38(6): 757–777.

Jorgensen, B. and Messner, M. (2009). Management Control in New Product Development: The dynamics of managing flexibility and efficiency, Journal of Management Accounting Research 21(1): 99–124.

Katz, D. and Kahn, R.L. (1966). The Social Psychology of Organizations, New York: Wiley.

Kirsch, L.J. (1996). The Management of Complex Tasks in Organizations: Controlling the systems development process, Organization Science 7(1): 1–21.

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. and 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.

Kirsch, L.J., Ko, D.L. and Haney, M.H. (2010). Investigating the Antecedents of Team-based Clan Control: Adding social capital as predictor, Organization Science 21(2): 469–489.

Kirsch, L.J., Sambamurthy, V., Ko, D.G. and Purvis, R.L. (2002). Controlling Information Systems Development Projects: The view from the client, Management Science 48(4): 484–498.

Lee, A.S. and Baskerville, R.L. (2003). Generalizing Generalizability in Information Systems Research, Information Systems Research 14(3): 221–243.

Coercive or enabling IS project control? J Heumann et al 348

Mähring, M. (2002). IT Project Governance, Stockholm: Stockholm School of Economics.

Maruping, L.M., Venkatesh, V. and Agarwal, R. (2009). A Control Theory Perspective on Agile Methodology Use and Changing User Requirements, Information Systems Research 20(3): 377–399.

Miles, M.B. and Huberman, A.M. (1994). Qualitative Data Analysis: An expanded sourcebook, Thousand Oaks: Sage.

Mingers, J. (2001). Combining IS Research Methods: Towards a pluralist methodology, Information Systems Research 12(3): 240–259.

Nealey, S.M. and Fiedler, F.E. (1968). Leadership Functions of Middle Managers, Psychological Bulletin 70(5): 313–329.

Nidumolu, S.R. and Subramani, M.R. (2003). The Matrix of Control: Combining process and structure approaches to managing software development, Journal of Management Information Systems 20(3): 159–196.

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. and Maguire, M.A. (1975). Organizational Control: Two functions, Administrative Science Quarterly 20(4): 559–569.

Snell, S.A. (1992). Control Theory in Strategic Human Resource Management: The mediating effect of administrative information, Academy of Management Journal 35(2): 292–327.

Soh, C., Chua, C.E.H. and Singh, H. (2011). Managing Diverse Stakeholders in Enterprise Systems Projects: A control portfolio approach, Journal of Information Technology 26(1): 16–31.

Star, S.L. (1989). The Structure of Ill-structured Solutions: Boundary objects and heterogeneous distributed problem solving, in M. Huhn and L. Gasser (eds.) Readings in Distributed Artificial Intelligence, Menlo Park: Morgan Kaufman, pp. 37–54.

Tiwana, A. (2010). Systems Development Ambidexterity: Explaining the complementary and substitutive roles of formal and informal controls, Journal of Management Information Systems 27(2): 87–126.

Tiwana, A. and Keil, M. (2009). Control in Internal and Outsourced Software Projects, Journal of Management Information Systems 26(3): 9–44.

Wiener, M., Remus, U., Mähring, M. and Saunders, C. (2013). Control of Information Systems Projects: Review and directions for future research, Working paper, March 2013, University of Erlangen-Nuremberg, Germany.

Yin, R.K. (2009). Case Study Research: Design and methods, 4th edn, Beverly Hills: Sage.

About the Authors

Jakob Heumann has been a Ph.D. student in Information Systems at the University of Erlangen-Nuremberg, Germany. His doctoral thesis dealt with the control of IS offshore project relationships as well as the interplay between managerial control and (national) culture. His research has been

published in major IS conference proceedings including ICIS, ECIS, and AMCIS.

Martin Wiener is an assistant professor in Information Systems at the University of Erlangen-Nuremberg, Germany, the Managing Director of the University’s Dr. Theo and Friedl Schoeller Research Center for Business and Society, and an affiliated researcher at the Stockholm School of Economics Institute for Research, Sweden. His research focuses on IS project control, global IT sourcing strategies, and the digitali- sation of business and society. He has published in outlets such as Information Systems Journal, Business & Information Systems Engineering (WIRTSCHAFTSINFORMATIK), Com- munications of the AIS, and Journal of Global Information Management. Wiener has been a Track Chair and Associate Editor for major IS conferences (ECIS and ICIS), and serves as a regular reviewer for top-ranked IS journals including MIS Quarterly and Information Systems Research.

Ulrich Remus is a full professor in the Department of Information Systems, Production and Logistics Management at the University of Innsbruck, Austria. His research focuses on IS project success and failure, IS project control, knowledge work, and negative impacts of IS, such as technostress and hyperconnectivity. His work has appeared in Information Systems Journal, Information Systems Management, Journal of Global Information Management, Business Process Manage- ment Journal, Journal of Knowledge Management, and others. He regularly serves as Track Chair and Associate Editor for major IS conferences, such as ECIS and ICIS, and is on the Editorial Board of Information & Management.

Magnus Mähring is an associate professor in the Department of Management and Organization at the Stockholm School of Economics, Sweden. His current research focuses on areas such as governance of large IT projects, project escalation and de-escalation processes, executive and board involvement in IT, and the dynamics and limitations of organisational control. He regularly contributes to international conferences and has pub- lished in journals such as Decision Sciences, Journal of the Association for Information Systems, Information Systems Jour- nal, Journal of Strategic Information Systems and California Management Review. He also serves as a senior editor for Information Systems Journal and as an editor for JAIS.

Coercive or enabling IS project control? J Heumann et al 349

Table A1 Survey instrument

Construct Label Item References

Outcome control exercised (OCE)a

OCE 1 I place significant weight upon timely project completion Kirsch et al. (2002), Tiwana and Keil (2009)

OCE 2 I place significant weight upon project completion within budgeted costs OCE 3 I place significant weight upon project completion to the satisfaction of the users OCE 4 I use pre-established targets as benchmarks for the [team leaders’/members’] performance evaluations OCE 5 I evaluate the [team leaders’/members’] performance by the extent to which project goals are accomplished,

regardless of how the goals are accomplished OCE 6 I place significant weight on meeting system requirements

Outcome control recognised (OCR)b

OCR 1 The [senior managers/team leader] place(s) significant weight upon timely project completion OCR 2 The [senior managers/team leader] place(s) significant weight upon project completion within budgeted costs OCR 3 The [senior managers/team leader] place(s) significant weight upon project completion to the satisfaction of the

users OCR 4 The [senior managers/team leader] use(s) pre-established targets as benchmarks for my performance evaluations OCR 5 The [senior managers/team leader] evaluate(s) my performance by the extent to which project goals are

accomplished, regardless of how the goals are accomplished OCR 6 The [senior managers/team leader] place(s) significant weight on meeting system requirements

Behaviour control exercised (BCE)a

BCE 1 I expect the [team leaders/members] to follow an understandable written sequence of steps towards accomplishing project goals

BCE 2 I expect the [team leaders/members] to follow an understandable written sequence of steps to ensure that system requirements are met

BCE 3 I expect the [team leaders/members] to follow an understandable written sequence of steps to ensure the success of this project

BCE 4 I assess the [team leaders/members] on the extent to which they follow existing written procedures and practices during the development process

Behaviour control recognised (BCR)b

BCR 1 The [senior managers/team leader] expect(s) me to follow an understandable written sequence of steps towards accomplishing project goals

BCR 2 The [senior managers/team leader] expect(s) me to follow an understandable written sequence of steps to ensure that system requirements are met

BCR 3 The [senior managers/team leader] expect(s) me to follow an understandable written sequence of steps to ensure the success of this project

BCR 4 The [senior managers/team leader] assess(es) me on the extent to which I follow existing written procedures and practices during the development process

aRespondents: senior managers and team leaders (controller perspective). bRespondents: team leaders and team members (controllee perspective). Note: All items were rated on 7-point Likert scales (‘1’ = I strongly disagree to ‘7’ = I strongly agree).

Appendix C o ercive

o r en

ab lin

g IS

p ro

ject co

n tro

l? JH

eum ann

etal 3 5 0

Table A2 Coding of control actions

Controller Controllee Example quote Control mechanism

Control mode

Control feature

Control style

Senior managers

Team leaders

The project plans include the time schedule and the major milestones […]. They are developed at [the senior management level] and then adjusted in regular meetings where the team leaders and the BU representatives are present. Changes to plans are checked and mutually agreed upon. (Programme manager)

Mutual adjustment of project plan

Outcome control

Repair Enabling

We discussed the plans in a bottom-up style: where we were heading and whether this was in alignment with the project plan; whether we needed more time, and whether we had to change things accordingly. (Team leader implementation)

Mutual adjustment of project plan

Outcome control

Repair Enabling

[In the weekly meetings], I briefly presented news and novelties: information from the steering board, changes to plans, the critical points for next week; so that everybody understood why, for example, there was some more pressure coming from this or that corner. Then, [the team leaders] presented their current status […]. Here, the objective was not a one-way communication, but to make sure that everybody informed each other. (Release manager)

Weekly meeting for bilateral information exchange

Behaviour control

Internal and global transparency

Enabling

Team leader(s) Team members

Control was driven by the time schedule […]. The control mechanism was time, and the control style was top-down. If you are so escalation-driven, you have a relatively clear idea of the tasks to be completed. (Team leader architecture)

Time schedule Outcome control

Absence of flexibility

Coercive

[In the rollout plan] literally every singly activity was meticulously specified – a plan about what needed to be done precisely; every single installation routine with start date and delivery date. (Team leader rollout)

Detailed rollout plan Behaviour control

Absence of repair and flexibility

Coercive

The […] benchmark was the number of tickets fixed. This was clearly communicated by [the team leader]: ‘You have your ticket, solve the problem!’When there were any problems and the problems weren’t fixed, he stepped in. (Team member 1 migration)

Expected performance level (number of tickets fixed)

Outcome control

Absence of repair and flexibility

Coercive

C o ercive

o r en

ab lin

g IS

p ro

ject co

n tro

l? JH

eum ann

etal 3 5 1

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.