12th pre-icis international research workshop on ... of the 12th international research workshop on...

12th Pre-ICIS International Research Workshop on Information Technology Project Management (IRWITPM 2017) Workshop Proceedings 12/9/2017

AIS Special Interest Group on Information Technology Project Management

eProceedings of the 12th International Research Workshop on Information Technology Project Management (IRWITPM)

Seoul, South Korea, December 9th, 2017 2

Table of Contents

Workshop Welcome .................................................................................................................................................... 3

Workshop Committee ................................................................................................................................................. 3

SIG ITProjMgmt Officers .......................................................................................................................................... 3

Sponsor Thanks ........................................................................................................................................................... 4

Completed Research

* The Role of Time Pressure in Software Projects: A Literature Review and Research Agenda by Dirk Basten

....................................................................................................................................................................................... 5

Team Performance in Agile Software Development Projects: The Effects of Requirement Changes, Time

Pressure, Team Diversity and Conflict by Phil Diegmann and Christoph Rosenkranz ...................................... 18

Spanning Knowledge Holes in Large IS Projects by Gloria H.W. Liu, Cecil E.H. Chua, and Eric T.G. Wang

..................................................................................................................................................................................... 33

Research in Progress

Implementing Strategy Through IS Projects: A Theory Building Literature Review by Fred Niederman and

Kathy Chudoba .......................................................................................................................................................... 46

Temporality in Information Systems Development (ISD) Research: A Systematic Literature Review by

Mairead O Connor, Denis Dennehy, Kieran Conboy ............................................................................................. 55

Note: * marks best paper award.



WORKSHOP WELCOME

I would like to personally welcome each of you to Seoul, South Korea for the 12th International Research Workshop

on IT Project Management (IRWITPM 2017) sponsored by the AIS Special Interest Group for Information

Technology Project Management (SIGITProjMgmt). This is our twelfth consecutive annual workshop and I am so

excited that we can continue or tradition of excellence as we promote, encourage, and discuss research in the domain

of IT project management.

I hope that you enjoy the workshop proceedings that cover a wide range of topics relating to IT project management.

Technology continues to evolve and provides both opportunities and challenges in relation to our work practices, thus

providing many opportunities for research. Although technology changes, one thing stays constant and that is people

and processes. People are a critical component to ensuring processes are in place to support work practices.

I would like to thank each of you for attending our workshop and brining your expertise. I also want to send my

gratitude to the workshop authors, reviewers, organizers, and sponsors (Project Management Institute) - your effort

makes this event possible. My sincere thanks to all for your efforts and engaging with this AIS Special Interest Group.

Dawn Owens, University of Texas at Dallas, SIGITProjMgmt President

WORKSHOP COMMITTEE

Dawn Owens, University of Texas at Dallas (Workshop Program Co-Chair)

Stacie Petter, Baylor University (Workshop Program Co-Chair)

Alanah Mitchell, Drake University (Workshop Program Co-Chair)

SIG ITPROJMGMT OFFICERS

Dawn Owens, University of Texas at Dallas (President)

Michael Cuellar, Georgia Southern University (Secretary)

Radu Vlas, University of Houston – Clear Lake (Treasurer)

Mohammad Moeini Aghkariz, University of Sussex (Communications and Publicity Chair)

Cecil Chua, The University of Auckland (Membership and Community Relations Chair)

Deepak Khazanchi, University of Nebraska at Omaha (Founder)



SPONSOR THANKS

Basten Time Pressure in Software Projects



The Role of Time Pressure in Software Projects: A Literature Review and Research Agenda

Dirk Basten

University of Cologne

[email protected]

ABSTRACT

The finding that deadlines affect work in organizational settings holds particularly true for software projects, which

are usually conducted under time pressure. While the role of time pressure in software projects has been extensively

studied, the findings yielded are diverse. Some authors report a positive relationship between time pressure and

software project outcomes, while others find it to be negative or to follow an inverted U-shape pattern. Since many

aspects concerning time pressure remain unexplained and its relationship with project outcomes is more complex than

it might seem at first glance, we synthesize pertinent research to develop a research agenda aimed at improving the

understanding in this domain. Our literature review shows a variety of time pressure conceptualizations, research

approaches, and research contexts. The results reveal an inconsistent picture of time pressure’s impact on software

projects. Our research agenda includes five themes we deem beneficial to consider in future research.

Keywords

Software projects, software development, time pressure, project management, literature review, research agenda.

INTRODUCTION

It is commonly acknowledged that deadlines affect work in organizational settings (Marks, Mathieu and Zaccaro,

2001). This is particularly the case for software development, where the ‘iron triangle’ is traditionally used to assess

project success (Atkinson, 1999, Pinto, 2004). The three criteria of the ‘iron triangle’—time, budget and quality—are

closely interrelated. Empirical evidence indicates that, in most software projects, effort estimates in terms of time or

budget are typically unrealistically low (Basten and Sunyaev, 2014), making schedule and budget overruns a common

issue (Grimstad, Jørgensen and Moløkken-Østvold, 2006, Kappelman, McKeeman and Zhang, 2006, Mukhopadhyay,

Vicinanza and Prietula, 1992). Such findings apply to both sequential (Maruping, Venkatesh, Thatcher and Patel,

2015) and agile (Malgonde, Collins and Hevner, 2014) projects. Time pressure that results from overly optimistic

estimates is usually associated with negative outcomes, such as reduced software quality (Mäntylä and Itkonen, 2013).

The role of time pressure in software projects has been the subject of extensive research (e.g., Austin, 2001, Banker,

Datar and Kemerer, 1987, Mäntylä, Petersen, Lehtinen and Lassenius, 2014, Maruping et al., 2015). However, findings

yielded by these studies are inconclusive, and this lack of consistency can be attributed to the absence of a generally

accepted definition of the concept (Hwang, 1994). Evidence of both negative and positive impact of time pressure on

work performance has been reported in extant literature (Maruping et al., 2015). Since under time pressure software

developers simply work faster rather than better (DeMarco, 1982), having unrealistic deadlines can lead to software

quality reductions (Mäntylä et al., 2014). Conversely, quality of decisions has been found to increase when time-

dependent incentives are given (Kocher and Sutter, 2006). Additionally, several authors posit that the nature of this

link is dependent on the degree of time pressure (Maruping et al., 2015, Nan and Harter, 2009). Yet, despite extensive

research in this field, many aspects of time pressure’s impact on software projects remain unexplained (Siau, Long

and Ling, 2010). Indeed, the relationship between time pressure and software projects is more complex than it might

seem at first glance (Mäntylä and Itkonen, 2013). Thus, in order to improve the understanding, we aim to elucidate

the role of time pressure in software projects by answering the following research questions:

What is the state of research concerning the role of time pressure in software projects?

How should the role of time pressure in software projects be addressed in future research?

In order to answer these questions, we conducted a review of literature held in six major scientific databases, focusing

on publications that address the role of time pressure in software projects. In analyzing the work reported within, we




identified a variety of time pressure conceptualizations, research approaches, and research contexts. Considering

existing insights into the role of time pressure in software projects, we found an inconsistent picture concerning the

effects of time pressure and respective practical implications. Thus, in order to reduce these discrepancies and assist

authors of future works in this field, we developed a research agenda comprising five major themes that should be

considered to advance the understanding of time pressure’s role in software projects.

This paper is structured as follows. In the next section, we explain the core concepts pertaining to this investigation

and report insights gained through the review of extant research. We then describe the strategy we adopted for the

identification and analysis of publications concerning time pressure’s role in software projects. Subsequently, we

present the results of the literature review pertaining to the conceptualization of time pressure, research approaches

and contexts used, and the observed effects of time pressure. We then discuss the findings and develop an agenda for

future research. Finally, we conclude the paper by considering the study limitations and practical implications of our

findings.

THEORETICAL BACKGROUND

Software Projects

A project is defined as “a temporary endeavor undertaken to create a unique product, service, or result” (Project

Management Institute, 2013, p. 3). While software has been defined as “computer programs, procedures, and possibly

associated documentation and data pertaining to the operation of a computer system” (Linberg, 1999, p. 179), software

development is the process of creating software that realizes and fulfils customer expectations (Bourque and Fairley,

2014). Combining these definitions, software projects are projects in above terms for developing (or

extending/adapting) software. While a plethora of development approaches exists, researchers commonly differentiate

between sequential and agile development as the two extremes (e.g., Dybå and Dingsøyr, 2008, Palmquist, Lapham,

Miller, Chick and Ozkaya, 2013). Table 1 juxtaposes the key characteristics of both approaches, which are described

in more detail below.

Sequential Development Agile Development

Requirements presumed to be stable expected to change

Process sequential iterative

Activities (e.g., design,

implementation)

one-time in each iteration

Customer Involvement mainly during requirements

engineering and testing

in each iteration

Documentation extensive limited, tailored to the project Table 1. Juxtaposition of Sequential and Agile Development Approaches (based on Palmquist et al., 2013)

Sequential development is the traditional approach to developing software (Dybå and Dingsøyr, 2008). Traditional

approaches stem from the engineering discipline, where solutions are claimed to exist for every problem and problems

to be solved are presumed to be fully specifiable. Traditionalists thus put emphasis on extensive planning and codified

processes, as this is deemed to make software development efficient and predictable (Boehm, 2002). In the traditional

perspective, software development is a sequential (i.e., non-iterative) process that commences with requirements

engineering, followed by system design and implementation, ending with testing and integration, and maintenance

(Palmquist et al., 2013). To proceed from one phase to the next, formal review and approval is required. Thus, the

development process is accompanied by extensive documentation and customers are typically involved in determining

requirements and testing the software.

Agile development is “both a philosophy and an umbrella term for a collection of methods or approaches that share

certain common characteristics” (Palmquist et al., 2013, p. 9) rather than a single method. Common characteristics

include (Palmquist et al., 2013):

• Requirements are assumed to change.

• To counteract requirements uncertainty, software is created in short iterations, which all include the activities

of analysis, design, coding, and testing.

• Documentation is typically tailored to a project.

• Customers are involved in each iteration to approve software and decide how to proceed.




Rather than emphasizing processes, agile development approaches focus on people, their creativity and their capacity

to cope with the challenge of uncertainty (Dybå and Dingsøyr, 2008). Feedback and change are the key aspects of

agile development approaches, which “embrace, rather than reject, higher rates of change” (Williams and Cockburn,

2003, p. 39). The practices on which agile software development approaches are based have been created by

experienced practitioners (Ågerfalk and Fitzgerald, 2006). Common approaches to agile software development include

Extreme Programming (Beck, 2000) and Scrum (Schwaber and Beedle, 2002).

Time Pressure in Software Projects

Since software development is typically project-based, the requisite endeavors take place under clearly defined time

and budget constraints (Bourque and Fairley, 2014). Managers of software projects thus need to consider the three

indices—time, budget, and quality—which are commonly referred to as ‘iron triangle’ (Atkinson, 1999) or ‘triple

constraint’ (Pinto, 2004). The three indices are closely related since they typically affect each other. For instance,

restricting the budget is likely to reduce quality and time available to develop a software. In practice, when planning

projects, estimates of effort in terms of time and budget are typically unrealistically low (Basten and Sunyaev, 2014).

Consequently, overruns of project schedule and budget occur (Grimstad et al., 2006, Kappelman et al., 2006,

Mukhopadhyay et al., 1992), resulting in time pressure.

Time pressure, which is the perception that time available to complete a task is scarce in relation to the demands of

the task (Cooper, Dewe and O'Driscoll, 2001, Kelly and McGrath, 1985), is common in organizational settings

(Gersick, 1988, Gevers, Rutte and van Eerde, 2006, Waller, Zellmer-Bruhn and Giambatista, 2002). Since “factors

such as project deadlines […] dictate many aspects of team functioning, including the strategies that are employed

[and] the pace of activities […] in order for the teams to perform successfully” (Marks et al., 2001, p. 359), it is widely

acknowledged that time pressure affects employee behavior and performance.

While authors of several studies have addressed the role of time pressure in software projects (e.g., Austin, 2001,

Mäntylä and Itkonen, 2013, Mäntylä et al., 2014, Maruping et al., 2015, Shah, Harrold and Sinha, 2014), their findings

concerning the relationship between time pressure and project performance are inconclusive (Maruping et al., 2015).

For example, time pressure has been found to exert both positive and negative impact on work performance, while an

inverted U-shape relationship has been reported at the individual level in some cases. Recent empirical work has

revealed that time pressure in software development can improve efficiency (as measured in, for example, more

defects found per time-unit and greater scores on test cases) in test case development (Mäntylä et al., 2014).

An extensive body of studies exploring the role of time pressure in software projects presently exists. However, the

explanatory power and theoretical contribution of this stream of literature remains inconclusive. Additionally, extant

studies differ regarding the depth to which the role of time pressure in software projects is assessed. While some

authors treat time pressure as one of many variables with the potential to explain various phenomena, such as

developers’ attitude that results from time pressure in projects (Sojer, Alexy, Kleinknecht and Henkel, 2014), others

have a clear focus on time pressure as the study concept (e.g., Austin, 2001). Moreover, a systematic synthesis of such

studies is presently lacking, indicating that an overview and analysis of these studies is needed to improve the

understanding of time pressure’s role in software projects. Insights into the research approaches applied and contexts

studied would also be highly beneficial in providing guidance for future research in this field. Additionally, we posit

that such a synthesis would provide a much-needed structure to the previous studies and would elucidate important,

yet under-researched, phenomena in this regard.

RESEARCH APPROACH

In order to assess the role of time pressure in software projects and thus answer the two research questions guiding

this investigation, we conducted a concept-driven literature review (Webster and Watson, 2002) and applied a two-

phase approach to identify and analyze relevant literature sources.

Identification and Selection of Literature

We chose to follow a tollgate approach for the selection of publications (see Figure 1; cf. Afzal, Torkar and Feldt,

2009). In Step 1, we identified potentially relevant publications by conducting systematic searches in the following

databases: ACM Digital Library, AIS Electronic Library (AISel), EBSCOhost, IEEEXplore, ProQuest and

ScienceDirect. For our search, we relied on a query within the search fields title, abstract, and keywords for each




database. We used a combination of the terms “time pressure” AND “software”, including relevant synonyms for both

terms. We adopted the following search pattern and adapted it to match the syntax of each database:

("deadline pressure" OR "time pressure" OR "time restriction*" OR "time limitation" OR "schedule

pressure" OR "time constraint*") AND (program* OR software OR project* OR "information

technology" OR "information system*")

As time pressure is not new a new phenomenon in software development, we did not restrict the search period.

Nonetheless, to assess our search process, we compared the identified publications with a small set of known studies

(i.e., Austin, 2001, Mäntylä and Itkonen, 2013, Maruping et al., 2015). The findings yielded justify our choice of

search process (cf. Kitchenham, Mendes and Travassos, 2007) because all articles known beforehand were among the

identified publications. Our search approach yielded 36,729 results. We reduced the set of publications to the most

relevant ones by only including articles published in journals in the Journal Ranking of the Association for Information

Systems1 (AIS). Additionally, we considered selected conferences2 for the analysis. The selection of outlets resulted

in a set of 1,923 articles potentially relevant to our research purpose. In order to refine our sample, we read titles and

abstracts to determine the work’s relevance to our research objective. Finally, and based on full reading of the text,

we excluded editorials (e.g., Glass, 2004), research-in-progress papers (Malgonde et al., 2014), and studies in which

time pressure is treated as a problem in software projects without analyzing its impact (Cao and Ramesh, 2008). This

strategy resulted in a set of 11 publications matching our criteria.

Figure 1. Selection of Publications

1 Recently, the AIS removed the journal ranking from its website. It is available at:

https://web.archive.org/web/20161007113451/https://aisnet.org/?JournalRankings

2 We included the following conference proceedings in our review: Americas Conference on Information Systems

(AMCIS), European Conference on Information Systems (ECIS), Hawaii International Conference on System

Sciences (HICSS), International Conference on Information Systems (ICIS), and International Conference on

Software Engineering (ICSE).

Paper count = 36,729

Paper count = 35,173

11 primary studies

Paper count = 55

Paper count = 1,923

1,556 duplicates removed

33,250 papers excluded due to

publication selection

1,868 papers excluded after

reviewing titles and abstracts

44 papers excluded after

reading full-text (e.g.,

editorials, research-in-progress)

13 papers selected

ACMDigitalLibrary

AISElectronicLibrary

IEEEXploreEBSCOhost ScienceDirectProQuest

Search backward and

forward

2 primary studies

Step2Step1




In Step 2, we performed backward and forward searches (Webster and Watson, 2002) to complement the set of

publications. Our backward search involved analysis of the references listed in the 11 publications that emerged from

the initial search process. For searching forward, we used Google Scholar (http://scholar.google.com). While the

backward search did not yield further relevant publications, we added two publications to our set based on the forward

search.

Data Analysis

We analyzed the final set of 13 publications by using a structured coding scheme (Flick, 2009, Miles and Huberman,

1994). The coding scheme consists of the following three code families (see Table 2 for respective codes and

definitions): (1) Codes related to the conceptualization of time pressure, addressing the definition of time pressure and

related information that the authors provide in the corresponding articles; (2) The code family concerning the research

approach and context, addressing studies’ research focus, research methods, and whether the studies are based on

empirical data; and (3) Codes related to time pressure’s effects, which include information about target variables,

results and respective implications.

Code Family Code Description

Conceptualization

of time pressure

Concept label Is the concept referred to as time pressure, deadline pressure,

schedule pressure, etc.?

Definition Is the concept explicitly defined? How do the authors define /

conceptualize or operationalize / measure the concept?

Measurement Is time pressure seen as objective or as a subjective perception?

Level Does the study address time pressure on individual or team level?

Research

approach and

context

Research focus What is the study’s focus?

Perspective Perspective(s) from which time pressure is considered (e.g.,

managers, developers, testers).

Research method What research method do the authors employ (e.g., conceptual,

literature review, case study research, survey)?

Empirical data Is the study based on empirical data? Is secondary data included?

Effects of time

pressure

Target variable What target variables are considered (e.g., quality, motivation,

effectiveness, efficiency)?

Results What type of effect has been shown for time pressure on the target

variable(s)?

Implications What implications (if any) are provided based on the results? Table 2. Structured Coding Scheme

For the development of the research agenda, we relied on thematic analysis, employed in qualitative studies when the

aim is to identify, analyze and report patterns within data (Braun and Clarke, 2006). By following an inductive

approach, we attempted to capture important aspects identified in our literature review in relation to our second

research question. Thereby, a theme “captures something important about the data in relation to the research question,

and represents some level of patterned response or meaning within the data set” (Braun and Clarke, 2006, p. 82).

RESEARCH STATE

Table 3 provides an overview of the analyzed articles in alphabetical order, while our results are structured in three

subsections, pertaining to conceptualization of time pressure, research approach and context, and effects of time

pressure.

Conceptualization of Time Pressure

We present the results related to the labelling employed in analyzed studies for the concept time pressure, along with

its definition and the level from which time pressure is addressed.

While authors of several studies in our sample refer to the concept of scarcity of time available to complete a task,

‘time pressure’ as the sole label for this concept is used in seven studies only (Austin, 2001, Deak, Stålhane and Sindre,

2016, Lohan, Acton and Conboy, 2014, Mäntylä et al., 2014, Maruping et al., 2015, Pennington and Tuttle, 2007,

Sojer et al., 2014). Others refer to deadline pressure (Banker et al., 1987), time constraints (Do, Mirarab, Tahvildari




and Rothermel, 2010), or schedule pressure (Nan and Harter, 2009). Finally, some authors use time pressure

synonymously with terms such as time restriction (Mäntylä and Itkonen, 2013), deadline pressure (Shah et al., 2014)

or time availability constraints/limitations (Topi, Valacich and Hoffer, 2005).

Study Time Pressure Focus of the Study Research

Method

Empirical

Data

Austin (2001) Development of a game-theory model to explain the

effect of time pressure on software developers’ behavior

towards (not) taking shortcuts

Conceptual No

Banker et al. (1987) Analysis of the effect of time pressure on the

productivity of software maintenance

Survey Yes

Deak et al. (2016) Analysis of how professional software testers can be

motivated and exploration of the respective policies to

be implemented in software development projects

Interviews Yes

Do et al. (2010) Analysis of the effects of time constraints on the costs

and benefits of test case prioritization techniques

Experiment Yes

Lohan et al. (2014) Analysis of the effects of group cohesion and time

pressure on decision-making quality in software

development groups

Survey Yes

Mäntylä and Itkonen

(2013)

Analysis of the effect of time pressure on the

effectiveness and efficiency of manual testing tasks

Experiment Yes

Mäntylä et al. (2014) Analysis of the effect of time pressure on the

effectiveness and efficiency of test case development

and requirements review

Experiment Yes

Maruping et al. (2015) Analysis of the effect of perceived time pressure on

team performance and the moderating role of team

temporal leadership in this context

Survey Yes

Nan and Harter (2009) Analysis of schedule pressure on software development

cycle time and effort

Secondary

data, survey

Yes

Pennington and Tuttle

(2007)

Analysis of the effect of time pressure on software

project risk assessment

Experiment Yes

Shah et al. (2014) Analysis of how vendor-side test engineers in a global

software testing context accomplish their tasks under

deadline pressure situations

Ethnography

(interviews,

observations,

informal

chats)

Yes

Sojer et al. (2014) Analysis of the effect of time pressure on software

developers’ attitude towards unethical programming

behavior

Survey,

interviews

Yes

Topi et al. (2005) Analysis of the effects of time pressure on performance

(i.e., speed, correctness) concerning the creation of

database queries

Experiment Yes

Table 3. Overview of Analyzed Publications

Although not providing an explicit definition of time pressure, authors of several studies (Deak et al., 2016, Do et al.,

2010, Lohan et al., 2014, Mäntylä and Itkonen, 2013, Mäntylä et al., 2014, Shah et al., 2014, Topi et al., 2005) seem

to share the understanding provided in the definition by Maruping et al. (2015). Based on the work of Cooper et al.

(2001) and Kelly and McGrath (1985), time pressure is typically defined as “the perception that there is a scarcity of

time available to complete a task, or set of tasks, relative to the demands of the task(s) at hand” (Maruping et al., 2015,

p. 1315). In contrast to this common understanding, authors of one study see time pressure as a discrepancy between

the schedule estimated by the project team and the schedule negotiated with the client (Nan and Harter, 2009).

Additionally, we found a reference to time pressure as “tendency of testing time to shrink from the original estimate

until the actual testing execution period takes place” (Deak et al., 2016, p. 9). In other studies, time pressure is viewed

as an objective condition (Austin, 2001, Pennington and Tuttle, 2007) rather than a subjective perception. Thereby,




the level of time pressure can be understood as the probability of a deadline being unrealistic (Austin, 2001) rather

than the severity of time pressure. Despite not providing a clear definition, several researchers state their understanding

of time pressure. Because time pressure is seen as an issue in every software project, it is only considered relevant if

it is perceived as leading to ‘severe’ consequences (Sojer et al., 2014) or as “greater than average deadline pressure

on the project” (Banker et al., 1987, p. 171). In only one study, time pressure is conceptualized as a two-dimensional

construct, “where challenge time pressure produces a positive reaction and hindrance time pressure produces a

negative reaction” (Lohan et al., 2014, p. 3).

In our sample of publications, time pressure is typically considered from the individual perspective (Austin, 2001,

Banker et al., 1987, Deak et al., 2016, Do et al., 2010, Mäntylä et al., 2014, Pennington and Tuttle, 2007, Sojer et al.,

2014, Topi et al., 2005). Other authors address the effect of time pressure on individuals as well, but emphasize the

team context (Lohan et al., 2014, Mäntylä and Itkonen, 2013, Shah et al., 2014). In only two of the analyzed studies

time pressure was treated as a team-level concept (Maruping et al., 2015, Nan and Harter, 2009).

Research Approach and Context

Here, we discuss our findings pertaining to the research approaches adopted and the types of data used in the studies

included in our sample. Additionally, we examine the study context by analyzing the focus (e.g., software testing) and

perspectives (e.g., developer) considered in each case.

With one exception (Austin, 2001), authors of all studies in the analyzed sample relied on empirical data to assess the

role of time pressure in software projects (see Table 3). With the authors of five studies relying on experimental data

(Do et al., 2010, Mäntylä and Itkonen, 2013, Mäntylä et al., 2014, Pennington and Tuttle, 2007, Topi et al., 2005) and

four further cases based on surveys or secondary data (Banker et al., 1987, Lohan et al., 2014, Maruping et al., 2015,

Nan and Harter, 2009, Sojer et al., 2014), a strong focus on quantitative research approaches is evident. Only in two

studies (Deak et al., 2016, Shah et al., 2014) the authors made exclusive use of qualitative research methods and report

findings based on the analysis of data gathered through interviews, observations, and informal chats.

In our sample, we identified two approaches to the assessment of the role of time pressure in software projects. First,

several authors consider time pressure in software projects in general (Lohan et al., 2014, Maruping et al., 2015, Nan

and Harter, 2009, Pennington and Tuttle, 2007). Second, others address time pressure in relation to particular activities,

such as programming (Austin, 2001, Banker et al., 1987, Sojer et al., 2014, Topi et al., 2005) and software testing

(Deak et al., 2016, Do et al., 2010, Mäntylä and Itkonen, 2013, Mäntylä et al., 2014, Shah et al., 2014).

Besides the studies focusing on the general team perspective (Maruping et al., 2015, Nan and Harter, 2009), the effects

of time pressure have been assessed from a variety of perspectives, including both managerial roles such as project

leaders (Banker et al., 1987) or risk auditors (Pennington and Tuttle, 2007), and technical roles such as software

developers (Austin, 2001, Do et al., 2010, Lohan et al., 2014, Sojer et al., 2014, Topi et al., 2005) or software testers

(Deak et al., 2016, Mäntylä and Itkonen, 2013, Mäntylä et al., 2014, Shah et al., 2014). Yet, despite examining time

pressure from the perspective of different software development roles, in some of the experimental studies, students

served as research subjects (Mäntylä and Itkonen, 2013, Mäntylä et al., 2014, Topi et al., 2005).

Effects of Time Pressure in Software Projects

When examining the effects of time pressure in software projects, authors of the studies included in our sample

employed a variety of target variables, and thus reported different results, with diverse implications, as will be

discussed below.

In line with the diversity of research approaches and contexts, the target variables used to assess the effects of time

pressure also vary considerably across the analyzed studies. Some authors adopted indices referring to both general

projects and individuals working on the projects. Indices in the former category pertain to productivity (Banker et al.,

1987), task performance (Maruping et al., 2015, Topi et al., 2005), correctness (Topi et al., 2005), decision quality

(Lohan et al., 2014), cycle time and effort (Nan and Harter, 2009), efficiency (Mäntylä et al., 2014), effectiveness

(Mäntylä and Itkonen, 2013), and cost-effectiveness (Do et al., 2010). Shah et al. (2014) does not focus on the

aforementioned indices, but rather on individuals’ general perceptions of time pressure in software projects.

Concerning the individual perspective, target variables include information overload (Pennington and Tuttle, 2007)

and developers’ behavior related to the taking of shortcuts (i.e., software imperfections that developers deliberately




induce to save time and meet a tight deadline; see Austin, 2001), motivation (Deak et al., 2016), and unethical reuse

of code (Sojer et al., 2014). Although these variables relate to individuals instead of projects in their entirety, they can

ultimately harm company reputation.

The findings related to time pressure’s role in software projects are as diverse as suggested by previous studies in

which time pressure’s effects in other settings were considered (see Time Pressure in Software Projects). In some

studies, either a positive or a negative effect of time pressure on project outcomes is reported. On the one hand, several

authors observed a positive effect of time pressure on productivity in the execution of software projects (Banker et al.,

1987), effectiveness and efficiency of software testing (Mäntylä and Itkonen, 2013, Mäntylä et al., 2014), decision

quality (Lohan et al., 2014), and software quality (Austin, 2001). On the other hand, some researchers found that time

pressure leads to unethical code reuse (Sojer et al., 2014), information overload (Pennington and Tuttle, 2007),

decreased motivation (Deak et al., 2016), and fewer correctly performed database queries (Topi et al., 2005). In

addition to the aforementioned research streams in which time pressure was found to be favorable or detrimental to

performance, authors of two studies report the inverted U-shape relationship between time pressure and performance

in software projects (Maruping et al., 2015, Nan and Harter, 2009). While Maruping et al. (2015, p. 1323) state that

their findings do “not reflect the full inverted U-shape relationship, the pattern provides partial support for Hypothesis

1 [‘Time pressure will have an inverted-U relationship with team processes.’]”, the results of Nan and Harter (2009)

do not support a significant U-shape relationship between schedule pressure and cycle time or development effort.

Due to the incongruence in the reported results, it is challenging to derive practical implications from previous research

concerning time pressure in software projects. As noted by Mäntylä et al. (2014), practitioners typically associate time

pressure with negative outcomes. Examples for such associations include time pressure as a reason for lower software

quality, burnout, and reduced job satisfaction. Findings yielded by several of the analyzed studies corroborate this

negative association (Pennington and Tuttle, 2007, Sojer et al., 2014, Topi et al., 2005). As a consequence of this

view, their authors recommend that time pressure be better managed, which might be a challenging endeavor because

the often unrealistically low effort estimates (Basten and Sunyaev, 2014) make time pressure a common condition in

software projects. However, the answer to the question whether time pressure inhibits or contributes to success of

software projects might depend on the degree of time pressure. In contrast to findings that indicate time pressure’s

negative effect on project outcomes, some authors claim that proper levels of time pressure might have beneficial

effects on project outcomes (Nan and Harter, 2009). For instance, the link between time pressure and unethical code

reuse has only been revealed in cases of severe time pressure. Research concerning software testing also shows that

time pressure can increase both effectiveness and efficiency (Mäntylä and Itkonen, 2013, Mäntylä et al., 2014).

Maruping et al. (2015, p. 1328) thus indicate that “some degree of time pressure is beneficial for motivating teams to

engage in team processes that facilitate performance”. This suggestion is in line with the view that time pressure

should be managed so that it is perceived as challenging rather than hindering (Lohan et al., 2014). Additionally, time

pressure is suggested as a short-time measure only. A long-term strategy based on time pressure is likely to affect staff

morale and result in increased turnover (Banker et al., 1987). Mäntylä and Itkonen (2013, p. 1000) conclude: “Use

time pressure, but not constantly, as it may backfire in the form of a high staff turnover rate”. Finally, although Austin’s

(2001) investigation does not extend to the severity of time pressure, his game-theory model suggests that continuously

high time pressure results in a state in which the shortage of time is so pervasive that reporting delays becomes

destigmatized. Consequently, developers tend not to take shortcuts, which would ultimately reduce software quality,

thereby mitigating the adverse effects of time pressure.

RESEARCH AGENDA

In this section, we discuss our findings based on which we develop an agenda for future research concerning the role

of time pressure in software projects. We present five themes that authors of future works should consider:

methodological pluralism, conceptualization, contemporary development approaches, the role of context, and

empirical validation.

Methodological Pluralism

In the set of analyzed publications, we found a strong focus on quantitative research. Most authors relied on

experiments or surveys for collecting data needed to examine the role of time pressure in software projects. While

those studies provide helpful insights into effects of time pressure, the resulting assessment of time pressure is also

restricted to the setting chosen in the study. Few studies have addressed time pressure in software projects from a

qualitative perspective. The studies by Deak et al. (2016) and Shah et al. (2014) are the only two in our sample in




which a purely qualitative research approach (an ethnographic-informed study based on interviews, observations, and

informal chats) was adopted.

A complex phenomenon such as time pressure, from our perspective, requires methodological pluralism to be

understood in its entirety. Research conducted to date has revealed a positive, a negative, as well as an inverted U-

shape relationship between time pressure and the outcomes of software projects. Qualitative research, such as

qualitative field studies and case study research, is likely to contribute to a better understanding of time pressure in

the context of software projects by providing in-depth insights from experts and triangulating data from various

perspectives. For example, longitudinal case studies can help assess the effects of time pressure in the long term.

Conceptualization

In most of the studies included in our literature review, the authors do not provide a definition of time pressure. This

is likely to be problematic because a generally accepted definition of the concept is lacking (Hwang, 1994). Without

taking the definition and understanding of time pressure into account, it can be misleading to derive general

implications from extant research. Findings yielded by studies based on different understandings of time pressure

should not be compared or combined without reconciling their respective conceptualizations and operationalizations

of the core concept.

Considering two extremes, whereby time pressure is defined as the perception of time available to complete a task

being scarce relative to the demands of that task (Maruping et al., 2015) and time pressure is treated as the probability

of task deadlines being unrealistic (Austin, 2001), we encourage authors of future studies to clearly conceptualize time

pressure. Depending on the conceptualization, it might be important to emphasize whether the concept is measured

objectively, or based on the perception of project stakeholders. In the latter case, the stakeholders considered should

be explicitly named. In conceptualizing time pressure, experience and skills of stakeholders are also decisive, since

they influence the perception of the severity of time pressure (e.g., a person familiar with a task is less likely to perceive

allocated time as inadequate for its completion compared to someone without the requisite experience).

Contemporary Development Approaches

Authors of several publications in our sample examined a specific phase of software projects, such as software testing

(Deak et al., 2016, Mäntylä and Itkonen, 2013, Mäntylä et al., 2014, Shah et al., 2014). Other authors consider software

projects in their entirety (Austin, 2001, Lohan et al., 2014, Maruping et al., 2015). In cases without explicit descriptions

of the context, research seems to focus on software projects following traditional development approaches. This

assumption is based on several considerations. First, some of those cases pertain to older publications (e.g., Austin,

2001, Banker et al., 1987), which are unlikely to refer to agile development approaches, considering that their

popularity surged at the beginning of the 21st Century. Second, several works have an explicit focus on a single

development phase (e.g., Mäntylä and Itkonen, 2013, Mäntylä et al., 2014, Shah et al., 2014), which is uncommon for

agile software projects. Finally, the fact that the development approach is not specified points towards traditional

approaches, because authors with a focus on contemporary ones would be likely to mention these in their research

approach. While Deak et al. (2016) refer to both sequential and agile development, the study conducted by Malgonde

et al. (2014), which we excluded from our sample due to its status as a research-in-progress paper, is the only one with

an explicit focus on agile software development. In their research, Malgonde et al. (2014) aim to establish whether

agile software development approaches can be adopted to effectively handle time pressure. Based on Extreme

Programming, the authors make a first step to shift attention to the phenomenon of time pressure in agile software

projects.

Yet, research concerning the role of time pressure in agile software projects is limited. Since time pressure is a problem

likely to result from inadequate project management, Scrum as an agile project management approach that is

applicable to software projects (see Software Projects) is a fruitful avenue for future research. In future studies, it

would be thus beneficial to consider a juxtaposition of sequential and agile development approaches, as this would

allow the authors to investigate whether contemporary, agile development approaches are more suitable for mitigating

time pressure in software projects due to their shorter cycle times.




The Role of Context

Findings yielded by the extant research examining the impact of time pressure software project outcomes are

inconclusive (see Effects of Time Pressure in Software Projects). Considering the various contexts that have been used

to study time pressure in software development (e.g., different project phases) and the diverse results, we suggest

being more mindful of the context in which the effects of time pressure are analyzed. Since previous research has

shown that measuring project performance depends on the project context (Pankratz and Basten, 2015) and time

pressure is likely to impact project performance, future research should identify and consider theoretical perspectives

that fit the respective context. Researchers should, for instance, consider focusing on the perspective from which time

pressure is assessed (e.g., developers) and how time pressure affects those individuals in their work routines.

Empirical Validation

When evaluating the publications in our sample, we noted that Austin (2001) is the only author that does not rely on

empirical data. This study is also unique for two other reasons. First, time pressure is considered as a probability of

deadlines being unrealistic. Second, Austin (2001) uses game theory to explore the relationship between time pressure

and software quality and develops the counter-intuitive hypothesis that increasing time pressure leads to better

software quality. According to the proposed model, being continuously subjected to high time pressure results in a

state in which the shortage of time is so ever-present that reporting delays is destigmatized, ultimately leading to less

shortcut-taking and thus higher software quality. Despite manifold references to Austin’s (2001) work in the

information systems literature (e.g., Asdemir, Kumar and Jacob, 2012, Fisher, Chengalur-Smith and Ballou, 2003,

Levina, 2005, Mahaney and Lederer, 2003, Mahaney and Lederer, 2006, Nan and Harter, 2009, Shah et al., 2014,

Shao, Yin and Chen, 2014, Wang, Ju, Jiang and Klein, 2008), the model has not been empirically tested yet.

Accordingly, we suggest that authors of future studies identify suitable means for empirically testing Austin’s (2001)

counter-intuitive hypothesis.

Besides the evaluation of the model proposed by Austin (2001), we encourage researchers to replicate the empirical

studies included in our review. Considering the variety of conceptualizations and research contexts, each of the

analyzed studies is unique. Replication of these studies would thus help strengthen the confidence in the reported

findings. This call is in line with the increased awareness of the value of replication studies in the information systems

discipline (Dennis and Valacich, 2014, Niederman and March, 2015).

CONCLUSION

In this work, we aimed to advance research on time pressure’s role in software projects by providing a synthesis of

pertinent studies and developing a research agenda that paves the way for future studies in this domain. Our literature

review reveals that authors of most studies rely on quantitative research approaches and aim to analyze the effect of

time pressure on outcomes of projects applying sequential development approaches. Future research should thus focus

on contemporary development approaches that provide an alternative project management strategies, such as Scrum.

Thereby, attention should be paid to the conceptualization of time pressure and the study context. The lack of a

generally accepted definition of time pressure and the diverse contexts studied might account for the inconsistent

picture concerning time pressure’s role in software projects that has emerged from this investigation.

Our study is limited by the depth of the analysis provided in this paper and the number of publications analyzed.

Concerning the former, a systematic mapping study (Kitchenham, 2007) of the identified studies will help assess the

strength of evidence that previous research provides in support of the reported time pressure’s effects on software

development outcomes. We omitted such an assessment because our primary purpose was to develop a research

agenda. Concerning the latter, our review covers the manifold outlets considered in the AIS journal ranking and is

thus likely to provide a comprehensive perspective on time pressure’s role in software projects. Additionally, we

applied both backward and forward searches to decrease the likelihood of overlooking relevant studies. While we

identified several other studies in which time pressure is discussed in the context of software projects, these were

excluded, as their authors did not assess the role of time pressure.

Even though our primary objective was the development of a research agenda, the aggregation of the analyzed studies

also has some important practical implications. First, the reported findings indicate that severe levels of time pressure

should be avoided. Otherwise, members of software projects might adapt their behavior in ways that negatively affect

project success. Second, moderate levels of time pressure can be used to increase project success by reducing slack,




motivating higher employee performance, and ultimately increasing productivity. Finally, time pressure should be

used as a short-term measure only, as working for prolonged periods under excessive time pressure reduces staff

morale and increases turnover.

REFERENCES

Afzal, W., Torkar, R. and Feldt, R. (2009) A Systematic Review of Search-based Testing for Non-functional System

Properties, Information and Software Technology, 51, 6, 957-976.

Ågerfalk, P. and Fitzgerald, B. (2006) Flexible and Distributed Software Processes: Old Petunias in new Bowls?,

Communications of the ACM, 49, 101, 27-34.

Asdemir, K., Kumar, N. and Jacob, V. S. (2012) Pricing Models for Online Advertising: CPM vs. CPC, Information

Systems Research, 23, 3-part-1, 804–822.

Atkinson, R. (1999) Project Management: Cost, Time and Quality, Two Best Guesses and a Phenomenon, Its Time to

Accept other Success Criteria, International Journal of Project Management, 17, 6, 337–342.

Austin, R. D. (2001) The Effects of Time Pressure on Quality in Software Development: An Agency Model,

Information Systems Research, 12, 2, 195–207.

Banker, R. D., Datar, S. M. and Kemerer, C. F. (1987) Factors Affecting Software Maintenance Productivity: an

Exploratory Study, in Proceedings of the International Conference on Information Systems, Association for

Information Systems, Pittsburgh, 160-175.

Basten, D. and Sunyaev, A. (2014) A Systematic Mapping of Factors Affecting Accuracy of Software Development

Effort Estimation, Communications of the Association for Information Systems, 34, Article 4, 51–86.

Beck, K. (2000) Extreme Programming Explained: Embrace Change, Addison-Wesley, Reading.

Boehm, B. (2002) Get Ready for Agile Methods, with Care, IEEE Computer, 35, 1, 64-69.

Bourque, P. and Fairley, R. E. (2014) Swebok. Guide to the Software Engineering Body of Knowledge, IEEE

Computer Society, Los Alamitos.

Braun, V. and Clarke, V. (2006) Using Thematic Analysis in Psychology, Qualitative Research in Psychology, 3, 2,

77-101.

Cao, L. and Ramesh, B. (2008) Agile Requirements Engineering Practices: An Empirical Study, IEEE software, 25,

1, 60-67.

Cooper, C., Dewe, P. and O'driscoll, M. (2001) Organizational Stress: A Review and Critique of Theory, Research,

and Applications, Sage, Thousand Oaks.

Deak, A., Stålhane, T. and Sindre, G. (2016) Challenges and Strategies for Motivating Software Testing Personnel,

Information and Software Technology, 73, May 2016, 1-15.

Demarco, T. (1982) Controlling Software Projects. Management, Measurement & Estimation, Prentice Hall, New

York.

Dennis, A. R. and Valacich, J. S. (2014) A Replication Manifesto, AIS Transactions on Replication Research, 1,

Article 1, 1-4.

Do, H., Mirarab, S., Tahvildari, L. and Rothermel, G. (2010) The Effects of Time Constraints on Test Case

Prioritization: A series of Controlled Experiments, IEEE Transactions on Software Engineering, 36, 5, 593-

617.

Dybå, T. and Dingsøyr, T. (2008) Empirical Studies of Agile Software Development: A Systematic Review,

Information and Software Technology, 50, 9-10, 833–859.

Fisher, C. W., Chengalur-Smith, I. and Ballou, D. P. (2003) The Impact of Experience and Time on the Use of Data

Quality Information in Decision Making, Information Systems Research, 14, 2, 170–188.

Flick, U. (2009) An Introduction to Qualitative Research, Sage, Los Angeles.

Gersick, C. (1988) Time and Transition in Work Teams: Toward a new Model of Group Development, Academy of

Management Journal, 31, 1, 9-41.

Gevers, J., Rutte, C. and Van Eerde, W. (2006) Meeting Deadlines in Work Groups: Implicit and Explicit Mechanisms,

Applied Psychology: An International Review, 55, 1, 52-72.

Glass, R. L. (2004) Anarchy and the Effects of Schedule Pressure, IEEE Software, 21, 5, 112.

Grimstad, S., Jørgensen, M. and Moløkken-Østvold, K. (2006) Software Effort Estimation Terminology: The Tower

of Babel, Information and Software Technology, 48, 4, 302–310.

Hwang, M. I. (1994) Decision Making under Time Pressure: A Model for Information Systems Research, Information

& Management, 27, 4, 197-203.




Kappelman, L. A., Mckeeman, R. and Zhang, L. (2006) Early Warning Signs of IT Project Failure: The Dominant

Dozen, Information Systems Management, 23, 4, 31–36.

Kelly, J. and Mcgrath, J. (1985) Effects of Time Limits and Task Types on Task Performance and Interaction of Four-

person Groups, Journal of Personality and Social Psychology, 49, 2, 395-407.

Kitchenham, B. (2007) Guidelines for performing Systematic Literature Reviews in Software Engineering,

Technical Report, Keele University.

Kitchenham, B. A., Mendes, E. and Travassos, G. H. (2007) Cross versus Within-company Cost Estimation Studies:

A Systematic Review, IEEE Transactions on Software Engineering, 33, 5, 316-329.

Kocher, M. G. and Sutter, M. (2006) Time is Money - Time Pressure, Incentives, and the Quality of Decision-making,

Journal of Economic Behavior & Organization, 61, 3, 375–392.

Levina, N. (2005) Collaborating on Multiparty Information Systems Development Projects: A Collective Reflection-

in-Action View, Information Systems Research, 16, 2, 109–130.

Linberg, K. R. (1999) Software Developer Perceptions about Software Project Failure: A Case Study, Journal of

Systems and Software, 49, 2-3, 177–192.

Lohan, G., Acton, T. and Conboy, K. (2014) An Investigation into Time Pressure, Group Cohesion and Decision

Making in Software Development Groups, in Australasian Conference on Information Systems, December

8-10, Auckland,

Mahaney, R. C. and Lederer, A. L. (2003) Information Systems Project Management: An Agency Theory

Interpretation, Journal of Systems and Software, 68, 1, 1–9.

Mahaney, R. C. and Lederer, A. L. (2006) Agency Theory Implications for Information Systems Project Management,

in Fred Niederman & Thomas W. Ferratt (eds.) IT Workers. Human Capital Issues in a Knowledge-based

Environment, Information Age Pub., Greenwich, 85–104.

Malgonde, O., Collins, R. and Hevner, A. (2014) Applying Emergent Outcome Controls to Mitigate Time Pressure in

Agile Software Development, in Proceedings of Americas Conference on Information Systems, Association

for Information Systems, Savannah, 1-7.

Mäntylä, M. V. and Itkonen, J. (2013) More Testers – The Effect of Crowd Size and Time Restriction in Software

Testing, Information and Software Technology, 55, 6, 986–1003.

Mäntylä, M. V., Petersen, K., Lehtinen, T. O. A. and Lassenius, C. (2014) Time Pressure: A Controlled Experiment

of Test Case Development and Requirements Review, in A. C. M. Special Interest Group on Software

Engineering (ed.) Proceedings of the 36th International Conference on Software Engineering, ACM, New

York, 83–94.

Marks, M. A., Mathieu, J. E. and Zaccaro, S. J. (2001) A Temporally Based Framework and Taxonomy of Team

Processes, Academy of Management Review, 26, 3, 356-376.

Maruping, L., Venkatesh, V., Thatcher, S. and Patel, P. (2015) Folding under Pressure or Rising to the

Occasion? Perceived Time Pressure and the Moderating Role of Team Temporal Leadership, Academy of


Miles, M. B. and Huberman, M. (1994) Qualitative Data Analysis: An Expanded Sourcebook, SAGE Publications,

Thousand Oaks, California.

Mukhopadhyay, T., Vicinanza, S. S. and Prietula, M. J. (1992) Examining the Feasibility of a Case-based Reasoning

Model for Software Effort Estimation, MIS Quarterly, 16, 2, 155–171.

Nan, N. and Harter, D. E. (2009) Impact of Budget and Schedule Pressure on Software Development Cycle Time and

Effort, IEEE Transactions on Software Engineering, 35, 5, 624–637.

Niederman, F. and March, S. (2015) Reflections on Replications, AIS Transactions on Replication Research, 1, Article

7, 1-16.

Palmquist, M. S., Lapham, M. A., Miller, S., Chick, T. and Ozkaya, I. (2013) Parallel Worlds: Agile and Waterfall

Differences and Similarities, Carnegie Mellon University, Technical Report.

Pankratz, O. and Basten, D. (2015) One Size Does Not Fit All – Contingency Approach on Relevance of IS Project

Success Dimensions, in Hawaii International Conference on System Sciences January, 5-8, Kauai, IEEE

Computer Society, 4416-4425.

Pennington, R. and Tuttle, B. (2007) The Effects of Information Overload on Software Project Risk Assessment,

Decision Sciences, 38, 3, 489-526.

Pinto, J. K. (2004) The Elements of Project Success, in David I. Cleland (ed.) Field Guide to Project Management,

Wiley, Hoboken, 14–27.

Project Management Institute (2013) A Guide to the Project Management Body of Knowledge (PMBOK Guide),

Project Management Institute, Newton Square.

Schwaber, K. and Beedle, M. (2002) Agile Software Development with Scrum, Prentice Hall, Upper Saddle River.




Shah, H., Harrold, M. J. and Sinha, S. (2014) Global Software Testing under Deadline Pressure: Vendor-side

Experiences, Information and Software Technology, 56, 1, 6–19.

Shao, B. B. M., Yin, P.-Y. and Chen, A. N. K. (2014) Organizing Knowledge Workforce for Specified Iterative

Software Development Tasks, Decision Support Systems, 59, 15–27.

Siau, K., Long, Y. and Ling, M. (2010) Toward a Unified Model of Information Systems Development Success,

Journal of Database Management, 21, 1, 80–101.

Sojer, M., Alexy, O., Kleinknecht, S. and Henkel, J. (2014) Understanding the Drivers of Unethical Programming

Behavior: The Inappropriate Reuse of Internet-accessible Code, Journal of Management Information

Systems, 31, 3, 287-325.

Topi, H., Valacich, J. S. and Hoffer, J. A. (2005) The Effects of Task Complexity and Time Availability Limitations

on Human Performance in Database Query Tasks, International Journal of Human-Computer Studies, 62, 3,

349–379.

Waller, M., Zellmer-Bruhn, M. and Giambatista, R. (2002) Watching the Clock: Group Pacing Behavior Under

Dynamic Deadlines, Academy of Management Journal, 45, 5, 1046-1055.

Wang, E. T. G., Ju, P.-H., Jiang, J. J. and Klein, G. (2008) The Effects of Change Control and Management Review

on Software Flexibility and Project Performance, Information & Management, 45, 7, 438–443.

Webster, J. and Watson, R. T. (2002) Analyzing the Past to Prepare for the Future: Writing a Literature Review, MIS

Quarterly, 26, 2, 13-23.

Williams, L. and Cockburn, A. (2003) Agile Software Development: It's About Feedback and Change, IEEE

Computer, 36, 6, 39-43.

Diegmann & Rosenkranz Requirements Changes, Time Pressure, Diversity, and Performance



Team Performance in Agile Software Development Projects: The Effects of Requirements Changes, Time

Pressure, Team Diversity, and Conflict

Phil Diegmann


[email protected]

Christoph Rosenkranz


[email protected]

ABSTRACT

Information system development has traditionally been accompanied by changing requirements throughout projects.

While recent research clarifies how time pressure affects team performance, the interplay between time pressure,

requirements changes, and various other important factors such as team diversity is unclear. In this paper, we evaluate

a novel and unified model based on extant research explaining the interactions of requirements changes, time pressure,

temporal leadership, team diversity, and conflict as well as their effect on team performance. Further, we differentiate

between the overall team performance and the team’s ability to respond both efficiently and extensively to

requirements changes. The proposed model helps in composing and steering teams to increase their resilience towards

requirements changes and time pressure. A first evaluation is based on a quantitative field study in multiple agile

software development projects of student teams.

Keywords

Team Performance, Agile Software Development, Requirements Changes, Time Pressure, Diversity, Conflict

INTRODUCTION

Agile methods for information system development (ISD) are increasingly popular in industry (Conboy 2009; Dybå

and Dingsøyr 2008; Fitzgerald et al. 2006; Lee and Xia 2010; Williams 2012) and see wide-spread adoption

(VersionOne 2017). Agile ISD methods, however, are no guarantee that a team will be successful (Fraser and Mancl

2008), and our understanding of what affects team performance and of the mechanisms of action in agile ISD

(henceforth: AISD) teams is lacking (Lee and Xia 2010; Persson et al. 2012; Sarker et al. 2009).

Team-level research in AISD, however, is scarce (Lee and Xia 2010), although AISD is mostly conducted in teams

and is quintessentially a team effort (Siau et al. 2010). Moreover, results are inconsistent. Some studies suggest that

AISD methods work best for highly cohesive and similar (i.e., non-diverse) teams (Cao et al. 2009; Fruhling and de

Vreede 2006), and that cohesiveness could be the main reason for successful ISD. Others find that diversity amplifies

creativity and communication, and therefore contributes to the success of AISD methods (Bear and Woolley 2011;

Lee and Xia 2010; Phillips et al. 2006). However, some studies identified an overhead in communication due to

diversity in teams, which hinders performance (Ely and Thomas 2001; Leonard et al. 2004; MacMillan et al. 2004).

Similar to diversity, time pressure has been found to both hinder and facilitate team performance, depending on the

temporal leadership, which helps to mitigate negative effects of time pressure (Maruping et al. 2015).

Research on teams and team performance therefore has identified a need to move beyond the simple diversity-affects-

performance model (Van Der Vegt and Bunderson 2005, p. 542), with calls for more empirical research on how

different factors affects team performance (henceforth: performance) in AISD (Lee and Xia 2010), and on team-level

effects in AISD (Conboy 2009; Mangalaraj et al. 2009; McAvoy and Butler 2009; McAvoy et al. 2013).

In this study, we aim to (1) identify the effects of diversity in AISD teams, (2) and to consolidate previous findings

on team performance (especially regarding time pressure and temporal leadership) into a unified and richer

understanding of team performance in AISD. Explaining team performance in a unified, consolidated, and

parsimonious model will ultimately help to understand AISD better, and to reduce the number of failed AISD projects.

Therefore, we enrich our understanding of team performance in AISD by including and adapting findings of team-

and organizational-behavior research as well as established findings from the information systems (IS) research

community.




We tested our model with a sample from eight student teams comprising 33 students and engaged in AISD projects,

using partial-least square (PLS) structural equation modeling. We found that team performance is affected by

requirements changes, temporal leadership, and team diversity. Time pressure has been found to increase affective

conflict, which in turn decreased team performance. Further we found that response efficiency precedes and improves

response extensiveness, which in turn showed to be beneficial for team performance.

Our results corroborate our unified model and indicate that in an enriched and extended model of team performance

interdependencies and effects can manifest differently from more contained models as found in extant research. We

therefore expand previous research on team performance and AISD by taking the bigger picture of AISD into account.

The remainder of this paper is structured as follows. First, we lay out related work and establish the theoretical

background. Second, we argue for our hypotheses and lay out our research model. Third, we present our research

design and explain the details of data analyses. These results are then discussed. Finally, we discuss the findings and

limitations of this study, give an outlook to future research and give a conclusion of this paper.

RELATED WORK

Information Systems Development & Agile Approaches

IS are often developed in the form of projects (Hirschheim et al. 1995, p. 33), with many involved stakeholders and

project team members (Chae and Poole 2005). The nature of ISD is in many aspects intangible (Cule et al. 2000). As

a result, many problems of ISD projects are not so much technological as sociological in nature (DeMarco and Lister

1987, p. 4). Coordination and communication between various stakeholders are necessary for successful

implementation (Corvera Charaf et al. 2013; Gallivan and Keil 2003; Ko et al. 2005), and creating a shared

understanding between involved stakeholders is deemed to be a major driver for ISD success (Bittner and Leimeister

2014; Gallivan and Keil 2003; Rosenkranz et al. 2013; Rosenkranz et al. 2014; Tan 1994).

In practice, methods for developing IS range from sequential approaches (Royce 1970) to more cyclic, iterative

approaches (Boehm 1988). The contemporary state-of-the-art AISD methods (Cao et al. 2009; Vidgen and Wang

2009), which are increasingly adopted in industry (VersionOne 2017), trade strict control for more flexibility and

autonomy within the team, the overall development process is not planned upfront, and progress is made in small

iterative phases, while encouraging change and constant feedback (Cockburn and Highsmith 2001; Highsmith and

Cockburn 2001). Planning becomes a permanent task, and team leadership is established via collaboration (Dybå and

Dingsøyr 2008; Dybå and Dingsøyr 2009).

While the team thus is highlighted as crucial to AISD in practice, extant research in the field of AISD methods has

investigated mainly specific, individual, or organizational phenomena, such as the use and effects of specific agile

practices (Balijepally et al. 2009; Holmqvist and Pessi 2006; Maruping et al. 2009b), and effects regarding whole

projects or organizations, such as the adoption of AISD methods (Cao et al. 2009; Heeager 2012; Hong et al. 2011;

Kotlarsky 2007; Mangalaraj et al. 2009).

As research thus covers the individual and organization-wide level of effects on AISD, team-level effects are covered

less so. Likewise, team research in organizational behavior has included technology as an influencing factor of team

work (e.g., Kozlowski and Ilgen 2006), but specific features of ISD have not been observed. Research found that

cohesive teams are the optimal base for applying agile practices (Cao et al. 2009; Fruhling and de Vreede 2006), while

other studies suggest that diversity – the differences among team members regarding visible (i.e., surface-level; e.g.,

ethnicity, age) and invisible (i.e., deep-level; e.g., experience, education) characteristics (Bear and Woolley 2011; Lee

and Xia 2010; Phillips et al. 2006) – amplifies creativity and problem-solving ability (Bear and Woolley 2011; Lee

and Xia 2010; Phillips et al. 2006) and therefore might provide benefits for ISD. These inconsistencies are especially

important for AISD, as AISD teams rely heavily on efficiency (to respond quickly to requirements changes; Conboy

2009) and problem solving ability (to complete complex, non-routine tasks; Lee and Xia 2010).

AISD explicitly acknowledges the importance of being able to respond to requirements changes and even embrace

change and an ever-changing environment (Beck et al. 2001). Each change imposes difficulties for the team.

Therefore, AISD teams have to have the capacity to recover quickly from these changes and resulting difficulties.

Extant research proposed this ability to consist of response efficiency (i.e., responding to and implementing of

requirements changes with minimal time, cost, personnel, and resources) and response extensiveness (i.e., the




proportion of requirements changes that a team responds to and implements) – both have been found to be important

predictors of overall performance (Lee and Xia 2010).

As AISD embraces requirements changes and aims at responding efficiently and extensively, changing requirements

are leading to additional work. Therefore, AISD teams are exposed to time pressure.

Time Pressure & Temporal Leadership

Time pressure is defined as the perceived scarcity of time to complete a task (Cooper et al. 2001). It is important to

differentiate time pressure from performance pressure (the shared accountability for outcomes, high scrutiny of work,

and significant consequences of performance outcomes; Gardner et al. 2012), as well as from urgency (a concern for

time and a feeling of being continuously hurried; Mohammed and Nadkarni 2011). Extant research (Maruping et al.

2015) found that perceived time pressure (in the following simply named “time pressure”) negatively affects team

processes. These processes in turn contribute to performance. With increased time pressure and therefore weakened

team processes, performance is bound to decrease.

Actions which structure, organize, or manage a team and its tasks are conceptualized as temporal leadership

(Maruping et al. 2015). This concept has been found to moderate the effect of time pressure, meaning that high

temporal leadership offsets negative effects on processes and ultimately performance (Maruping et al. 2015).

Temporal leadership therefore plays an important role in AISD, due to its change-embracing nature.

Changing requirements lead to additional work and new tasks. Typically, deadlines cannot be moved – which leads

to more work per time. While requirements changes are therefore affecting time pressure and project failure being

partly attributed to changing requirements (Zowghi and Nurmuliani 2002), recent research has not yet integrated

requirements changes into the interactions of time pressure, temporal leadership, and performance.

Similar to requirements changes, findings in organizational research have not yet been fully integrated in ISD research,

although diversity in AISD teams becomes increasingly important, due to outsourcing and globally distributed teams.

Diversity & Conflict

Behavioral research on team work has focused mainly on outcomes of performance before shifting from input-process-

output models to cyclic input-mediation-output-input models (Ilgen et al. 2005). A notion of teams as complex,

context-sensitive, and evolving systems has emerged (Ilgen et al. 2005; Kozlowski and Bell 2003).

As ISD projects are becoming more distributed and diverse (e.g., Persson et al. 2012; Ramesh et al. 2012; Sarker et

al. 2009; Sarker and Sarker 2009), research on AISD has started adapting diversity concepts, and calling for a better

understanding of effects of diversity in ISD (Lee and Xia 2010). Extant research applied theories of organizational

psychology while being focused on IT use than on ISD (e.g., Gorecki et al. 2008; Nan 2011; Wang and Hahn 2015).

In organizational psychology, diversity has emerged as an important predictor of performance and research found

contradictions (del Carmen Triana et al. 2014; Hülsheger et al. 2009; Joshi and Roh 2009; Milliken and Martins 1996;

Phillips et al. 2006; Post 2012; Van Der Vegt and Bunderson 2005). Some studies find a positive relation between

diversity and performance (see Bear and Woolley 2011; Phillips et al. 2006; Van Der Vegt and Bunderson 2005), but

outlined a dependency on specific contextual circumstances, such as the competitive threat-level (del Carmen Triana

et al. 2014), team identification, and climate (Van Der Vegt and Bunderson 2005). Team identification and climate

have been found to play an important role in generating positive effects from diversity (Van Der Vegt and Bunderson

2005). Studies which identified a negative effect describe an overhead of communication and a risk for conflict (Ely

and Thomas 2001; Leonard et al. 2004; MacMillan et al. 2004).

Scholars differentiate between deep-level (DLD; i.e. education, experiences) and surface-level diversity (SLD; i.e.

ethnicity, age) (Aggarwal and Woolley 2013; Hülsheger et al. 2009; Phillips et al. 2006). These two types act

differently: while SLD highlights dissimilarities and encourages sharing of unique information (Phillips et al. 2006),

DLD might lead to harmful conflict (Jehn et al. 1999) or facilitate performance by providing different educational

backgrounds and skillsets (Joshi and Roh 2009).




Furthermore, diversity can be grouped (Harrison and Klein 2007) into separation (differences in opinions etc.),

disparity (differences in socially valued assets), and variety (differences in knowledge etc.). In the scope of this

research, we are most interested in variety, as differences in knowledge can help overcome crises.

Diversity entails a risk of increased conflict and a need for increased communication among team members. Research

distinguishes between affective conflict (i.e., conflict on an emotional or personal level that is not task-related; also

named relationship conflict) versus task conflict (i.e., disagreements about ideas and strategies regarding the current

task) (Jehn et al. 2008). While a medium level task conflict has been found to be beneficial to non-routine tasks,

affective conflict has been found to negatively affect performance (Jehn et al. 2008).

In sum, no integrated model exists that explains the relationships between factors such as diversity, temporal

leadership, conflict, requirements changes, and time pressure. This becomes especially important if the inconsistent

findings of effects of diversity are taken into account. A holistic model integrating the findings of organizational

research into extant ISD research helps in explaining interdependencies and interactions of existing models.

RESEARCH MODEL & HYPOTHESES

Based on the literature laid out above, we argue for a novel research model that integrates these streams for AISD (see

Figure 1). Table 1 provides detailed definitions for each construct.

Figure 1. Research Model.




Construct Definition

Requirements Changes

(Maruping et al. 2009a)

Reflects changes to the intended functionality of the to-be-developed IS

during the process.

Time Pressure

(Cooper et al. 2001; Kelly and McGrath

1985; Maruping et al. 2015)

A (perceived) scarcity of time available to complete a task, relative to the

demands of the task at hand.

Temporal Leadership

(Maruping et al. 2015; Mohammed and

Nadkarni 2011)

Leader behaviors that help in structuring, coordinating, and managing

the pacing of task accomplishment within the team.

Response Efficiency

(Lee and Xia 2010)

Minimal time, cost, personnel, and resources that the team requires to

respond to and implement a specific requirement change.

Response Extensiveness

(Lee and Xia 2010)

Proportion of changing user requirements that a software team responds

to and implements.

Team Diversity

(Aggarwal and Woolley 2013;

Hülsheger et al. 2009; Lee and Xia

2010; Phillips et al. 2006)

The extent to which team members are different in terms of their

functional backgrounds, skills, expertise, and (work) experience.

Affective Conflict

(Jehn et al. 2008; Maruping et al. 2015)

Conflict on an emotional or personal level that is not task-related. Also

named relationship conflict.

Team Performance

(Lee and Xia 2010; Maruping et al.

2015; Wallace et al. 2004)

The extent to which a team’s project deliverable is produced on time,

within budget, within functionality requirements, and is of high quality.

Grading The grade achieved by each participant. The grades are based on the

industry partner’s and the teaching assistant’s evaluation of each

participant. Table 1. Construct Definitions.

Due to the change-embracing nature of AISD (Beck et al. 2001), we focus on requirements changes first.

Requirements changes are conceptualized as a change in the customer’s understanding of their own needs over the

course of the project (Maruping et al. 2009a). Likewise, time pressure is defined as the perceived scarcity of available

time to finish a task (Maruping et al. 2015). As requirements changes have been found to increase time pressure due

to increased work amounts (Maruping et al. 2015), we propose:

H1: Increased requirements changes increase time pressure.

With increased time pressure, confusion might arise over who is responsible for which task, due to limited resources

(Maruping et al. 2015). Furthermore, this results in limited time to resolve existing conflicts or inhibits to blights

upcoming conflicts. This further increases frustration and in turn conflict (Maruping et al. 2015) – more specifically,

affective conflict, that is, conflict on an emotional or personal level, which is not directly task-related (Jehn et al. 2008).

Following this argument, we state:

H2: More time pressure leads to more affective conflict.

In line with the argumentation of Maruping et al. (2015), we propose a moderation of temporal leadership on the effect

of time pressure on affective conflict. Temporal leadership is defined as “leader behaviors that aid in structuring,

coordinating, and managing the pacing of task accomplishment within the team” (Mohammed and Nadkarni 2011, p.

492); temporal leadership plays an important role to utilize time pressure as a motivator. As we focus on affective

conflict (i.e., the negative effects of time pressure due to increased confusion about who should complete what tasks

(Maruping et al. 2015)), we propose that strong temporal leadership leads to less time-pressure-related conflicts.

Therefore, we propose:

H3: Higher levels of temporal leadership decrease the effect of time pressure on affective conflict.

Diversity has been found to have both positive (Bear and Woolley 2011; Lee and Xia 2010; Phillips et al. 2006) and

negative effects (Cao et al. 2009; Fruhling and de Vreede 2006) on performance – the fulfillment of requirements,

functionality, and quality. This depends on the level of diversity and the type of resulting conflict (Jehn et al. 1999;




Joshi and Roh 2009; Phillips et al. 2006). As we focus on diversity in skillsets and experiences (Joshi and Roh 2009)

to tackle shocks resulting from requirements changes, we are especially interested in deep-level diversity, which has

been found to increase the need for communication and entailing a risk of misunderstanding and conflicts (Jehn et al.

1999). Therefore, we propose:

H4: Higher levels of diversity lead to more affective conflict.

As extant research found, affective conflict is hindering performance (e.g., by requiring additional time to resolve

conflicts; Jehn et al. 2008) which is why we state:

H5: Increased affective conflict decreases performance.

Coming back to the top of our model, we further expect requirements changes to increase response efficiency. The

more requirements changes are brought forward by a customer, the more potential a team has to respond efficiently.

Therefore, we posit:

H6: Higher levels of requirements changes lead to more response efficiency.

Extant research found that with increasing time pressure, developers engage in less productive, inefficient tasks,

constraining their ability to efficiently complete their task (Durham et al. 2000; Perlow 1999). If time pressure rises,

the ability to turn requirements changes into response efficiency (see H5) is being limited. If H1 is supported, this

assembles a control-loop: increased requirements changes increase the potential of response efficiency which in turn

is limited if the increased requirements changes raise the time pressure. We expect this to ultimately prevent teams

from responding efficiently for high time pressure.

H7: More time pressure decreases the enabling effect of requirements changes on response efficiency.

Regarding temporal leadership (i.e., “leader behaviors that aid in structuring, coordinating, and managing the pacing

of task accomplishment within the team” (Mohammed and Nadkarni 2011, p. 492)), we expect temporal leadership to

increase response efficiency. Contrary to extant literature (Maruping et al. 2015), we do not posit time pressure to

have a direct effect on response efficiency (and therefore temporal leadership not having a moderating effect on

response efficiency). Instead of replacing it, we modify and transform the previous model. H3 resembles the

moderating and mitigating effect of temporal leadership on the negative effects of time pressure. We further argue

that temporal leadership increases response efficiency due to the structuring, coordinating, and managing (i.e.,

optimizing) actions associated with strong temporal leadership. Therefore, we propose:

H8: Higher levels of temporal leadership lead to increased response efficiency.

With the ability to respond efficiently to requirements changes, we expect teams to be able to also respond more

extensively. While extant research found a negative effect of response extensiveness on response efficiency (Lee and

Xia 2010), an inverted relationship so far has neither been supported nor dismissed. We argue that with high response

efficiency, resulting from strong temporal leadership, a team is able to response more extensive than otherwise. We

acknowledge that an overly extensive response can have adverse effects on response efficiency (i.e. due to an

overwhelming effect (Lee and Xia 2010)), but we argue that this situation would not have happened if a strong

temporal leadership was in place (e.g., due to a better structuring and organization of tasks). Therefore, we state:

H9: Increased response efficiency increases response extensiveness.

As a team is able to respond extensively to requirements changes, performance is bound to increase as well, as this

results in more software functionality being implemented as initially needed by the client (Lee and Xia 2010):

H10: Increased response extensiveness increases performance.

As our sample consists of students of a graded course, we expect an increased performance to lead to better grades:

H11: Increased performance leads to better grading.




RESEARCH DESIGN

Survey Design & Data Collection

As our research model is based on extant literature and all constructs were already used by previous literature, we

were able to reuse parts of existing measurement instruments.

In accordance with the quantitative nature of our study we used a questionnaire to gather data. Over the course of an

undergraduate class in which students had to develop software for practitioners following AISD principles (Scrum),

we provided two different surveys at two different times. First and at the very beginning of an iteration, we asked for

general demographics and static information and control variables, such as the experience developing software.

Second and just after finishing the iteration, we asked the participants for all outcome-related constructs. Third, we

measured the grading of the outcome by the teaching assistants and the industry partner at the end of the project. With

this approach, we hope to get an as unbiased result as possible, as we gather static information (e.g., diversity) without

distortion from current, quite possibly stressed, emotions, while still gather time-pressure-sensitive data during the

most stressful part of AISD (i.e., sprint completion).

All participants were granted anonymity and did not receive any rewards for participation. The grades were added to

our dataset by an otherwise not involved researcher without access to any identifying properties aside from the student-

identification number.

Measurement Scales

Table 2 lists all constructs used in our research model as well as the measurement items for each construct. To ensure

a common understanding of all items, we applied the back translation method (Brislin 1970), as all participants were

more proficient in German than in English.

Construct Item

(RC)

Requirements Changes

(Maruping et al. 2009a)

Requirements fluctuated quite a bit in early phases of the project

Requirements fluctuated quite a bit in later phases of the project

Requirements identified at the beginning of the project were quite different from those

toward the end

(TP)

Time Pressure

(Maruping et al. 2015)

We are often under a lot of pressure to complete our tasks on time

We are not afforded much time to complete our tasks

The amount of time provided to complete our tasks is short

Task durations are often short

(TL)

Temporal Leadership


To what extent does the team leader remind members of important deadlines?

To what extent does the team leader prioritize tasks and allocate time to each task?

To what extent does the team leader prepare and build in time for contingencies,

problems, and emerging issues?

To what extent does the team leader pace the team so that work is finished on time?

To what extent does the team leader urge members to finish sub-tasks on time?

To what extent does the team leader set milestones to measure progress on the project?

To what extent is the team leader effective in coordinating the team to meet customer

deadlines?

(RE)

Response Efficiency

(Lee and Xia 2010)

How much additional effort was required by the team to incorporate the following

changes? (Effort includes time, cost, personnel, and resources)

System Scope

System Input Data

System Output Data

Business Rules & Processes

Data Structure

User Interface

(RX)

Response Extensiveness

(Lee and Xia 2010)

How much additional effort was required by the team to incorporate the following

changes? (Effort includes time, cost, personnel, and resources)

System Scope




Construct Item

System Input Data

System Output Data

Business Rules & Processes

Data Structure

User Interface

(TD)

Team Diversity

(Lee and Xia 2010)

The members of the team were from different areas of expertise

The members of the team had skills that complemented each other

The members of the team had a variety of different experiences

The members of the team varied in functional backgrounds

(AC)

Affective Conflict


How much have you managed friction among members of your project team?

How much have you managed personality conflicts between team members during the

project?

How much have you dealt with tension among members of your project team?

How much have you managed emotional conflict among members of your project team?

(PE)

Team Performance

(Lee and Xia 2010;

Maruping et al. 2015)

The client perceives that the system meets intended functional requirements

The overall quality of the developed system is high

The software delivered by the project achieved its functional goals

The software delivered by the project met end-user requirements

The capabilities of the software fit end-user needs

The software met technical requirements

(GR)

Grading

The final grade (in points) for this sprint. Based on functionality implemented, bugs

fixed, and code quality, as rated by the lecturer and practice partner. Table 2. Constructs & corresponding items.

DATA ANALYSIS & RESULTS

We gathered data from 33 voluntarily partaking students. Table 3 describes the sample characteristics. The group to

which the students were assigned did only correlate with one item – the functional background diversity (#4 of the

diversity construct; r(31) = -.380, p < .05) –, indicating variations in perceived functional backgrounds among groups.

Participants (n = 33)

Gender

Female (N = 5; 15.2%)

Male (N = 28; 84.8%)

Other (N = 0; 0%)

Age 22.41 years average (range: 20-28)

Experience in

working agile

No previous experience (N = 21; 63.6%)

One year (N = 7; 21.2%)

Two or more years (N = 4; 12.2%)

No answer (N = 1; 3.0%)

Group Sizes Four to six students per Group (M = 5.00, SD = .5) Table 3. Sample Description

In the following we test our model using partial least squares (PLS) structural equation modeling. PLS is better suited

for exploratory research and predict key target constructs using latent variables, and for complex structural models

than a covariance-based approach (Hair et al. 2011). Our results were calculated with SmartPLS 3.2.6 (Ringle et al.

2015).

Our measurement model contains reflective and formative constructs. As the grading is a single-item and – in this

context – less subjective construct compared to other success measures such as self-report performance, we do not

check this construct for reliability or validity. We first checked the reflective constructs (i.e., all but response

extensiveness and response efficiency) for reliability and validity. First, internal consistency was evaluated using

Cronbach’s alpha and composite reliability which need to exceed .70 (Nunnally 1978; Werts et al. 1974). The

constructs fulfill both criteria (see Table 5). Second, indicators are considered reliable if the associated latent construct




explains more than half of the indicator’s variance (Henseler et al. 2009); our model passes this criterion (see Table

6). Therefore, we presume indicator reliability.

Third, Table 5 shows that the composite reliabilities of all constructs exceed the required minimum of .80 and that the

AVE values of all constructs exceed the threshold of .50. Additionally, all item loadings exceed the threshold of .70.

Thus, convergent validity conditions are met (Fornell and Larcker 1981).

Fourth, the square root of each construct’s AVE needs to exceed the correlations with the other constructs to indicate

discriminant validity (Fornell and Larcker 1981) which is the case for all of our constructs (see Table 4). Moreover,

we examined the factor loadings of each indicator (Fornell-Larcker criterion). Each indicator needs to load higher on

the associated construct compared to all other factors (Chin 1998) which is the case for our data (see Table 6). In

addition to the Fornell-Larcker criterion, the Heterotrait-monotrait (HTMT) ratio of correlations is suggested as a new

criterion to assess discriminant validity (Henseler et al. 2015). The highest HTMT value for our model of .78 is below

a conservative threshold of .85 (Henseler et al. 2015). Combining the results, we posit discriminant validity (Voorhees

et al. 2015).

RC TP TL TD AC PE GR C CR AVE

RC .86 RC .82 .90 .74

TP .35 .88 TP .90 .93 .77

TL -.07 .14 .83 TL .93 .94 .70

TD -.16 -.14 -.14 .76 TD .76 .84 .58

AC .33 .73 .11 -.47 .93 AC .95 .97 .87

PE .01 -.06 -.02 .35 -.32 .85 PE .92 .94 .71

GR .03 -.07 .25 -.03 -.04 .39 1.00 GR 1.00 1.00 1.00 Left: Table 4. Construct correlations & the square root of average variance extracted (AVE, bold).

Right: Table 5. Cronbach’s alpha (C), composite reliability (CR) & average variance extracted (AVE).

RC TP TL TD AC PE GR

RC1 .94 .34 -.03 -.04 .33 .10 -.02

RC2 .83 .34 -.13 -.20 .33 -.12 -.02

RC3 .81 .22 -.03 -.22 .18 .02 .16

TP1 .38 .86 .10 -.02 .66 -.17 -.10

TP2 .36 .90 .22 -.14 .64 -.14 -.02

TP3 .23 .82 -.06 -.15 .61 .11 -.01

TP4 .25 .92 .22 -.18 .63 .03 -.10

TL1 -.05 .01 .87 -.19 .00 -.03 .27

TL2 -.21 .24 .82 -.14 .16 .04 .20

TL3 -.08 .03 .90 .01 -.05 -.03 .23

TL4 .03 .10 .87 -.13 .12 -.06 .18

TL5 -.24 -.01 .71 -.28 -.01 -.13 .02

TL6 .01 .11 .92 -.09 .11 .02 .34

TL7 -.07 .34 .79 -.07 .31 .05 .14

TD1 -.29 -.19 .08 .82 -.44 .13 -.07

TD2 -.20 .04 -.19 .74 -.29 .38 -.11

TD3 .05 -.03 -.15 .81 -.35 .26 -.11

TD4 -.02 -.20 -.24 .72 -.31 .35 .23

AC1 .47 .61 .06 -.40 .90 -.24 .01

AC2 .24 .69 .10 -.46 .95 -.32 -.08

AC3 .27 .69 .19 -.46 .94 -.34 -.02

AC4 .29 .72 .07 -.42 .95 -.28 -.08

PE1 .15 .15 .14 .34 -.16 .76 .32

PE2 .06 .09 .09 .14 -.16 .86 .26

PE3 -.03 -.15 -.11 .41 -.29 .88 .25

PE4 .04 -.15 .02 .35 -.37 .82 .39

PE5 -.11 -.15 -.16 .32 -.39 .85 .36

PE6 -.11 -.16 -.11 .21 -.28 .90 .38

GR1 .03 -.07 .02 -.03 -.04 .39 1.00




Left: Table 6. Factor loadings (bold) & cross-loadings

Right: Figure 2. Path weights & significances.

*: p < .050, **: p < .010, ***: p <.001

In the following, we check the formative indicators (i.e., response efficiency and response extensiveness). We

followed Petter et al. (2007) for assessing the validity and reliability of the formative constructs. The traditional

evaluation criteria such as factor loadings and AVE are not applicable for evaluating formative measurement models.

Because these measures assume high internal consistency (high intercorrelating indicators), they are inappropriate for

formative indicators, where no theoretical assumption is made about inter-item correlation (Petter et al. 2007; Straub

et al. 2004). We assessed construct validity by using principal components analysis to examine the item weights for

the measurement model (Petter et al. 2007). Table 7 depicts the inter-item and item-to-construct correlations for the

formative indicators. If the majority of inter-item correlations and item-to-construct correlations for a given latent

construct are significant, the measures achieve convergent validity. As can be seen, all items correlate with one another

within the same construct higher than with items of the other construct with only a few exceptions which indicates

discriminant validity. While only one item (RE3) shows a significant outer weight (see Table 9), and one might drop

the other items, all items share more variance with their respective construct than any other item which is why we

keep the items (Cenfetelli and Bassellier 2009). Furthermore, small absolute and insignificant weights should not

inevitably be misinterpreted as a poor measurement model (Chin 1998; Hair et al. 2011). Following this analysis, we

assume convergent validity.

In line with Lee and Xia (2010), RX3 showed an above-threshold (Diamantopoulos and Siguaw 2006) value for the

variance inflator factor (VIF, see Table 8). As Lee and Xia (2010) argue, removing RX3 would not benefit the

measurement and the item was retained. Therefore, we ensure that no multicollinearity issue exists and that reliability

is given.

RX1 RX2 RX3 RX4 RX5 RX6 RX RE1 RE2 RE3 RE4 RE5 RE6 RE

RX1 1.00

RX2 .58* 1.00

RX3 .66* .70* 1.00

RX4 .72* .76* .72* 1.00

RX5 .50* .60* .51* .43* 1.00

RX6 .51* .56* .67* .52* .58* 1.00

RX .80* .86* .87* .84* .74* .79* 1.00

RE1 .40* .24 .43* .275 .45* .52* .47* 1.00

RE2 .29 .49* .51* .44* .13 .27 .44* .39* 1.00

RE3 .59* .50* .50* .61* .27 .45* .59* .40* .60* 1.00

RE4 .66* .53* .45* .63* .23 .32 .57* .29 .70* .60* 1.00

RE5 .25 .36* .40* .39* .41* .41* .45* .54* .46* .62* .26 1.00

RE6 .33 .43* .31 .35* .21 .26 .38* .34 .62* .39* .55* .43* 1.00

RE .55* .56* .58* .59* .37* .49* .64* .65* .84* .81* .74* .75* .73* 1.00

Table 7. Inter-Item and Item-to-Construct Correlation Matrix for Formative Items.

* p < .05; EX: Response Extensiveness, EF: Response Efficiency

Having established our model as valid and reliable, we can now turn to our hypotheses. As can be seen in Figure 2,

all hypothesized paths but one are significant. Hypotheses H3 and H9 cannot be accepted. As diversity does not increase

affective conflict in our sample but actually decreases it, we cannot accept H3. Regarding the moderating effect of

temporal leadership on the effect of time pressure on affective conflict, we cannot accept the hypothesis, as it is not

significant (p = .080).

Table 7 displays R2 values, the achieved power as well as the effect sizes and respective f2 values. As can be seen,

most constructs provide medium or even large effects and high power in spite of the small sample size of 33.




Construct R2 Power f2 Effect size Construct Item Weight VIF

RC -> RE --

.999 .703 Large

Response

Extensiveness

RX1 .012 3.33

RC -> TP .677 .142 Small RX2 -.347 3.04

TP .280 .762 .178 Small RX3 .363 3.75

TL -- .999 .721 Large RX4 .597 2.47

RE .645 1.00 1.669 Large RX5 .202 1.98

RX .625 .859 .237 Medium RX6 .334 2.13

TD -- .988 .489 Large

Response

Efficiency

RE1 -.417 2.69

AC .698 .756 .175 Small RE2 .348 2.58

GR .151 -- -- -- RE3 .716* 2.65

TL * TP -- .589 .112 Small RE4 .302 1.48

TP * RC -- .979 .433 Medium RE5 .243 2.31

RE6 .044 1.87 Left: Table 8. Interaction effects

R2 values, Power, f2 values, and effect sizes (Cohen 1988; Cohen 1992)

Right: Table 9. Outer Weight and Variance Inflator Factor (VIF) Statistics for Formative Indicators

* p < .05

DISCUSSION & CONCLUSION

We were able to support most of our hypotheses. Large effect sizes, high power, and high explained variance indicate

that our small sample size of 33 participants is sufficient to draw meaningful conclusions. The model suggests that

AISD is affected by requirements changes in regard to time pressure, affective conflict, and ultimately performance.

Furthermore, the results suggest that diversity can reduce affective conflict and therefore mitigate some negative

effects of time pressure, and that response efficiency, response extensiveness, as well as performance are linked to

temporal leadership.

In contrast to our expectation, diversity decreased affective conflict in our sample. We assume this to be due to a

medium level of diversity present in our sample. Age (SD = 2.18), experience (SD = .66), and educational background

(SD = .55) were more homogeneous than in many AISD teams, as all participants were undergraduate students from

the same university. This homogeneity might have reduced the likelihood of affective conflicts by providing a common

ground and a feeling of belonging to the in-group (Brewer 1979). Another explanation would be that the in-group was

perceived as more complex and diverse than other groups (Park and Rothbart 1982) and therefore, due to the self-

reported characteristic, distort the measurement.

Another unexpected result was that no moderation of temporal leadership could be identified for the effect of time

pressure on affective conflict. Another limitation and explanation for this might be that this sample was set in an

educational context. While the class is designed to prepare students for real-life projects in cooperation with real-life

practitioners, we cannot rule out a distortion. This might also have reduced the effect of affective conflict due to a

sense of community among students (Cheng 2004; Cicognani et al. 2008).

Therefore, we call for replications in real-world scenarios with larger sample sizes. Replications would not only

increase the reliability, but also increase the transferability to other contexts. Due to the small sample size and the

participants being students, generalizability is not given. Future research could also investigate, whether or not the

self-report items on diversity significantly deviate from the actual diversity to clear the mixed results regarding

diversity. Furthermore, we measured different projects but only over one iteration. Including multiple iterations might

result in further insights regarding the effect of time pressure.

Regarding theoretical contributions of this paper, we found supporting evidence for the importance of time pressure

and temporal leadership for performance as outlined by previous research. Further, we integrated diversity and

requirements changes to provide a more holistic view and are able to reduce the ambiguity of effects regarding

diversity, requirements changes, and performance.

In regard to practical contributions, we laid the groundwork for a deeper understanding of the effects at play in AISD

teams which are operating under constant requirements changes. The proposed model helps practitioners compose

and steer teams to increase a team’s resilience towards requirements changes and time pressure.




In this paper, we presented the results of a quantitative study. We added explanation to the effects and interactions

between performance, requirements changes, time pressure, affective conflict, diversity and temporal leadership. We

provided reasoning for the hypothesized relations and argued for deviations and discussed the contributions to both

research and practice and derived future research opportunities from the limitations of this study.

REFERENCES

Aggarwal, I., and Woolley, A. W. 2013. "Do You See What I See? The Effect of Members’ Cognitive Styles on Team

Processes and Errors in Task Execution," Organizational Behavior and Human Decision Processes (122:1),

pp. 92-99.

Balijepally, V., Mahapatra, R., Nerur, S., and Price, K. H. 2009. "Are Two Heads Better Than One for Software

Development? The Productivity Paradox of Pair Programming," MIS Quarterly (33:1), pp. 91-119.

Bear, J. B., and Woolley, A. W. 2011. "The Role of Gender in Team Collaboration and Performance," Interdisciplinary

Science Reviews (36:2), pp. 146-153.

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J.,

Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., and

Thomas, D. 2001. "Manifesto for Agile Software Development." Manifesto for Agile Software Development

Retrieved February 24, 2016, from http://www.agilemanifesto.org/

Bittner, E. A. C., and Leimeister, J. M. 2014. "Creating Shared Understanding in Heterogeneous Work Groups: Why

It Matters and How to Achieve It," Journal of Management Information Systems (31:1), pp. 111-144.

Boehm, B. W. 1988. "A Spiral Model of Software Development and Enhancement," IEEE Computer (21:4), pp. 61-

72.

Brewer, M. B. 1979. "In-Group Bias in the Minimal Intergroup Situation: A Cognitive-Motivational Analysis,"

Psychological bulletin (86:2), p. 307.

Brislin, R. W. 1970. "Back-Translation for Cross-Cultural Research," Journal of Cross-Cultural Psychology (1:3), pp.

185-216.

Cao, L., Mohan, K., Xu, P., and Ramesh, B. 2009. "A Framework for Adapting Agile Development Methodologies,"

European Journal of Information Systems (18:4), pp. 332-343.

Cenfetelli, R. T., and Bassellier, G. 2009. "Interpretation of Formative Measurement in Information Systems

Research," MIS quarterly), pp. 689-707.

Chae, B., and Poole, M. S. 2005. "The Surface of Emergence in Systems Development: Agency, Institutions, and

Large-Scale Information Systems," European Journal of Information Systems (14:1), pp. 19-36.

Cheng, D. X. 2004. "Students' Sense of Campus Community: What It Means, and What to Do About It," NASPA

journal (41:2), pp. 216-234.

Chin, W. W. 1998. "The Partial Least Squares Approach to Structural Equation Modeling," Modern methods for

business research (295:2), pp. 295-336.

Cicognani, E., Pirini, C., Keyes, C., Joshanloo, M., Rostami, R., and Nosratabadi, M. 2008. "Social Participation,

Sense of Community and Social Well Being: A Study on American, Italian and Iranian University Students,"

Social Indicators Research (89:1), pp. 97-112.

Cockburn, A., and Highsmith, J. 2001. "Agile Software Development: The People Factor," IEEE Computer (34:11),

pp. 131-133.

Cohen, J. 1988. "The Effect Size," Statistical power analysis for the behavioral sciences), pp. 77-83.

Cohen, J. 1992. "A Power Primer," Psychological bulletin (112:1), p. 155.

Conboy, K. 2009. "Agility from First Principles: Reconstructing the Concept of Agility in Information Systems

Development," Information Systems Research (20:3), pp. 329-355.

Cooper, C. L., Dewe, P. J., and O'Driscoll, M. P. 2001. Organizational Stress: A Review and Critique of Theory,

Research, and Applications. Sage.

Corvera Charaf, M., Rosenkranz, C., and Holten, R. 2013. "The Emergence of Shared Understanding: Applying

Functional Pragmatics to Study the Requirements Development Process," Information Systems Journal

(23:2), pp. 115-135.

Cule, P., Schmidt, R., Lyytinen, K., and Keil, M. 2000. "Strategies for Heading Off Is Project Failure," Information

Systems Management (17:2), pp. 65-73.

del Carmen Triana, M., Miller, T. L., and Trzebiatowski, T. M. 2014. "The Double-Edged Nature of Board Gender

Diversity: Diversity, Firm Performance, and the Power of Women Directors as Predictors of Strategic

Change," Organization Science (25:2), pp. 609-632.




DeMarco, T., and Lister, T. 1987. Peopleware: Productive Projects and Teams. Dorset House Publishing Co., Inc.

New York, NY, USA.

Diamantopoulos, A., and Siguaw, J. A. 2006. "Formative Versus Reflective Indicators in Organizational Measure

Development: A Comparison and Empirical Illustration," British Journal of Management (17:4), pp. 263-

282.

Durham, C. C., Locke, E. A., Poon, J. M., and McLeod, P. L. 2000. "Effects of Group Goals and Time Pressure on

Group Efficacy, Information-Seeking Strategy, and Performance," Human Performance (13:2), pp. 115-138.

Dybå, T., and Dingsøyr, T. 2008. "Empirical Studies of Agile Software Development: A Systematic Review,"

Information and software technology (50:9), pp. 833-859.

Dybå, T., and Dingsøyr, T. 2009. "What Do We Know About Agile Software Development?," IEEE Software (26:5),

pp. 6-9.

Ely, R. J., and Thomas, D. A. 2001. "Cultural Diversity at Work: The Effects of Diversity Perspectives on Work Group

Processes and Outcomes," Administrative Science Quarterly (46:2), pp. 229-273.

Fitzgerald, B., Hartnett, G., and Conboy, K. 2006. "Customising Agile Methods to Software Practices at Intel

Shannon," European Journal of Information Systems (15:2).

Fornell, C., and Larcker, D. F. 1981. "Evaluating Structural Equation Models with Unobservable Variables and

Measurement Error," Journal of Marketing Research (18:1), pp. 39–50.

Fraser, S., and Mancl, D. 2008. "No Silver Bullet: Software Engineering Reloaded," IEEE Software (25:1).

Fruhling, A., and de Vreede, G.-J. 2006. "Field Experiences with Extreme Programming: Developing an Emergency

Response System," Journal of Management Information Systems (22:4), pp. 39-69.

Gallivan, M. J., and Keil, M. 2003. "The User-Developer Communication Process: A Critical Case Study,"

Information Systems Journal (13:1), pp. 37-68.

Gardner, H. K., Gino, F., and Staats, B. R. 2012. "Dynamically Integrating Knowledge in Teams: Transforming

Resources into Performance," Academy of Management Journal (55:4), pp. 998-1022.

Gorecki, J., Berthon, P., DesAutels, P., Donnellan, B., and Teigland, R. 2008. "The Multinational's Nemesis: The Rise

of Ict-Enabled Distributed Collective Intelligence?," in: ICIS 2008 Proceedings. pp. 1-6.

Hair, J. F., Ringle, C. M., and Sarstedt, M. 2011. "Pls-Sem: Indeed a Silver Bullet," Journal of Marketing Theory and

Practice (19:2), pp. 139-152.

Harrison, D. A., and Klein, K. J. 2007. "What's the Difference? Diversity Constructs as Separation, Variety, or

Disparity in Organizations," Academy of management review (32:4), pp. 1199-1228.

Heeager, L. T. 2012. "Introducing Agile Practices in a Documentation-Driven Software Development Practice: A

Case Study," Journal of Information Technology Case and Application Research (14:1), pp. 3-24.

Henseler, J., Ringle, C. M., and Sarstedt, M. 2015. "Testing Measurement Invariance of Composites Using Partial

Least Squares," Forthcoming in: International Marketing Review).

Henseler, J., Ringle, C. M., and Sinkovics, R. R. 2009. "The Use of Partial Least Squares Path modeling in

International marketing," Advances in International Marketing (20:IV), pp. 277–319.

Highsmith, J., and Cockburn, A. 2001. "Agile Software Development: The Business of Innovation," IEEE Computer

(34:9), pp. 120-122.

Hirschheim, R., Klein, H., and Lyytinen, K. 1995. Information Systems Development and Data Modeling. Conceptual

and Philosophical Foundations. Cambridge, England: Cambridge University Press.

Holmqvist, M., and Pessi, K. 2006. "Agility through Scenario Development and Continuous Implementation: A

Global Aftermarket Logistics Case," European Journal of Information Systems (15:2).

Hong, W., Thong, J. Y. L., Chasalow, L. C., and Dhillon, G. 2011. "User Acceptance of Agile Information Systems:

A Model and Empirical Test," Journal of Management Information Systems (28:1), pp. 235-273.

Hülsheger, U. R., Anderson, N., and Salgado, J. F. 2009. "Team-Level Predictors of Innovation at Work: A

Comprehensive Meta-Analysis Spanning Three Decades of Research," Journal of Applied Psychology (94:5),

pp. 1128-1145.

Ilgen, D. R., Hollenbeck, J. R., Johnson, M., and Jundt, D. 2005. "Teams in Organizations: From Input-Process-Output

Models to Imoi Models," Annual Review of Psychology (56), pp. 517-543.

Jehn, K. A., Greer, L., Levine, S., and Szulanski, G. 2008. "The Effects of Conflict Types, Dimensions, and Emergent

States on Group Outcomes," Group Decision & Negotiation (17:6), pp. 465-495.

Jehn, K. A., Northcraft, G. B., and Neale, M. A. 1999. "Why Differences Make a Difference: A Field Study of

Diversity, Conflict and Performance in Workgroups," Administrative Science Quarterly (44:4), pp. 741-763.

Joshi, A., and Roh, H. 2009. "The Role of Context in Work Team Diversity Research: A Meta-Analytic Review,"

Academy of Management Journal (52:3), pp. 599-627.




Kelly, J. R., and McGrath, J. E. 1985. "Effects of Time Limits and Task Types on Task Performance and Interaction

of Four-Person Groups," Journal of Personality and Social Psychology (49:2), p. 395.

Ko, D.-G., Kirsch, L. J., and King, W. R. 2005. "Antecedents of Knowledge Transfer from Consultants to Clients in

Enterprise System Implementations," MIS Quarterly (29:1), pp. 59-85.

Kotlarsky, J. 2007. "Re-Engineering at Lecroy Corporation: The Move to Component-Based Systems," Journal of

Information Technology (22:4), pp. 465-478.

Kozlowski, S. W., and Bell, B. S. 2003. Work Groups and Teams in Organizations. London: Wiley.

Kozlowski, S. W., and Ilgen, D. R. 2006. "Enhancing the Effectiveness of Work Groups and Teams," Psychological

Ccience in the Public Interest (7:3), pp. 77-124.

Lee, G., and Xia, W. 2010. "Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data on

Software Development Agility," MIS Quarterly (34:1), pp. 87-115.

Leonard, J. S., Levine, D. I., and Joshi, A. 2004. "Do Birds of a Feather Shop Together? The Effects on Performance

of Employees' Similarity with One Another and with Customers," Journal of Organizational Behavior (25:6),

pp. 731-754.

MacMillan, J., Entin, E. E., and Serfaty, D. 2004. "Communication Overhead: The Hidden Cost of Team Cognition,"

in Team Cognition: Understanding the Factors That Drive Process and Performance, E.S.S.M. Fiore (ed.).

Washington, DC, US: American Psychological Association, pp. 61-82.

Mangalaraj, G., Mahapatra, R., and Nerur, S. 2009. "Acceptance of Software Process Innovations - the Case of

Extreme Programming," European Journal of Information Systems (18:4), pp. 344-354.

Maruping, L. M., Venkatesh, V., and Agarwal, R. 2009a. "A Control Theory Perspective on Agile Methodology Use

and Changing User Requirements," Information Systems Research (20:3), pp. 377-400.

Maruping, L. M., Venkatesh, V., Thatcher, S. M., and Patel, P. C. 2015. "Folding under Pressure or Rising to the

Occasion? Perceived Time Pressure and the Moderating Role of Team Temporal Leadership," Academy of

Management Journal (58:5), pp. 1313-1333.

Maruping, L. M., Zhang, X., and Venkatesh, V. 2009b. "Role of Collective Ownership and Coding Standards in

Coordinating Expertise in Software Project Teams," European Journal of Information Systems (18:4), pp.

355-371.

McAvoy, J., and Butler, T. 2009. "A Failure to Learn by Software Developers: Inhibiting the Adoption of an Agile

Software Development Methodology," Journal of Information Technology Case and Application Research

(11:1), pp. 23-46.

McAvoy, J., Nagle, T., and Sammon, D. 2013. "Using Mindfulness to Examine Isd Agility," Information Systems

Journal (23:2), pp. 155-173.

Milliken, F. J., and Martins, L. L. 1996. "Searching for Common Threads: Understanding the Multiple Effects of

Diversity in Organizational Groups," Academy of Management Review (21:2), pp. 402-433.

Mohammed, S., and Nadkarni, S. 2011. "Temporal Diversity and Team Performance: The Moderating Role of Team

Temporal Leadership," Academy of Management Journal (54:3), pp. 489-508.

Nan, N. 2011. "Capturing Bottom-up Information Technology Use Processes: A Complext Adaptive Systems Model,"

MIS Quarterly (35:2), pp. 505-540.

Nunnally, J. C. 1978. Psychometric Theory, (2nd ed.). New York: McGraw-Hill.

Park, B., and Rothbart, M. 1982. "Perception of out-Group Homogeneity and Levels of Social Categorization:

Memory for the Subordinate Attributes of in-Group and out-Group Members," Journal of Personality and

Social Psychology (42:6), p. 1051.

Perlow, L. A. 1999. "The Time Famine: Toward a Sociology of Work Time," Administrative science quarterly (44:1),

pp. 57-81.

Persson, J. S., Mathiassen, L., and Aaen, I. 2012. "Agile Distributed Software Development: Enacting Control through

Media and Context," Information Systems Journal (22:6), pp. 411-434.

Petter, S., Straub, D., and Rai, A. 2007. "Specifying Formative Constructs in Information Systems Research," MIS

quarterly), pp. 623-656.

Phillips, K. W., Northcraft, G. B., and Neale, M. A. 2006. "Surface-Level Diversity and Decision-Making in Groups:

When Does Deep-Level Similarity Help?," Group processes & intergroup relations (9:4), pp. 467-482.

Post, C. 2012. "Deep-Level Team Composition and Innovation: The Mediating Roles of Psychological Safety and

Cooperative Learning," Group & Organization Management (37:5), pp. 555-588.

Ramesh, B., Mohan, K., and Lan, C. 2012. "Ambidexterity in Agile Distributed Development: An Empirical

Investigation," Information Systems Research (23:2), pp. 323-340.

Ringle, C. M., Wende, S., and Becker, J.-M. 2015. "Smartpls 3." Retrieved 2017/05/22, from

http://www.smartpls.com/




Rosenkranz, C., Charaf, M. C., and Holten, R. 2013. "Language Quality in Requirements Development: Tracing

Communication in the Process of Information Systems Development," Journal of Information Technology

(28:3), pp. 198-223.

Rosenkranz, C., Vranesic, H., and Holten, R. 2014. "Boundary Interactions and Motors of Change in Requirements

Elicitation: A Dynamic Perspective on Knowledge Sharing," Journal of the Association for Information

Systems (15:6), pp. 306-345.

Royce, W. W. 1970. "Managing the Development of Large Software Systems: Concepts and Techniques,"

Proceedings of WesCon.

Sarker, S., Munson, C. L., Sarker, S., and Chakraborty, S. 2009. "Assessing the Relative Contribution of the Facets of

Agility to Distributed Systems Development Success: An Analytic Hierarchy Process Approach," European

Journal of Information Systems (18:4), pp. 285-299.

Sarker, S., and Sarker, S. 2009. "Exploring Agility in Distributed Information Systems Development Teams: An

Interpretive Study in an Offshoring Context," Information Systems Research (20:3), pp. 440-462.

Siau, K., Long, Y., and Ling, M. 2010. "Toward a Unified Model of Information Systems Development Success,"

Journal of Database Management (21:1), pp. 80-101.

Straub, D., Boudreau, M.-C., and Gefen, D. 2004. "Validation Guidelines for Is Positivist Research," The

Communications of the Association for Information Systems (13:1), p. 63.

Tan, M. 1994. "Establishing Mutual Understanding in Systems Design: An Empirical Study," Journal of Management

Information Systems (10:4), pp. 159-182.

Van Der Vegt, G. S., and Bunderson, J. S. 2005. "Learning and Performance in Multidisciplinary Teams: The

Importance of Collective Team Identification," Academy of Management Journal (48:3), pp. 532-547.

VersionOne. 2017. "11th State of Agile Report." from https://explore.versionone.com/state-of-agile/versionone-11th-

annual-state-of-agile-report-2

Vidgen, R., and Wang, X. 2009. "Coevolving Systems and the Organization of Agile Software Development,"

Information Systems Research (20:3), pp. 355-376.

Voorhees, C. M., Brady, M. K., Calantone, R., and Ramirez, E. 2015. "Discriminant Validity Testing in Marketing:

An Analysis, Causes for Concern, and Proposed Remedies," Journal of the Academy of Marketing Science

(44), pp. 119-134.

Wallace, L., Keil, M., and Rai, A. 2004. "How Software Project Risk Affects Project Performance: An Investigation

of the Dimensions of Risk and an Exploratory Model," Decision Sciences (35:2), pp. 289-321.

Wang, Z., and Hahn, J. 2015. "Crowd Experience and Performance: An Empirical Analysis of Crowdsourced New

Product Development," in: ICIS 2015 Proceedings. pp. 1-20.

Werts, C. E., Linn, R. L., and Jöreskog, K. G. 1974. "Intraclass Reliability Estimates: Testing Structural Assumptions,"

Educational and Psychological Measurement (34:1), pp. 25–33.

Williams, L. 2012. "What Agile Teams Think of Agile Principles," Communications of the ACM (55:4), pp. 71-76.

Zowghi, D., and Nurmuliani, N. 2002. "A Study of the Impact of Requirements Volatility on Software Project

Performance," Software Engineering Conference, 2002. Ninth Asia-Pacific: IEEE, pp. 3-11.

Liu et al. Knowledge Holes in IS Project



Spanning Knowledge Holes In IS Projects

Gloria H.W. Liu

National Central University

[email protected]

Cecil E.H. Chua

The University of Auckland

[email protected]

Eric T.G. Wang

National Central University

[email protected]

Abstract

Prior studies have demonstrated the importance of bridging structural holes across functional groups in IS projects.

In this study, we argue that bridging structural holes is necessary but insufficient for ensuring project success. An

additional requirement is that knowledge holes across functional groups need to be bridged to enable effective

problem-solving across functional groups. We propose and empirically study the concept of knowledge holes in a

case study of an ERP upgrade. Our findings suggest that complementary to the concept of structural holes, the concept

of knowledge holes is useful for explaining different project outcomes. Our findings also demonstrate methods for

bridging knowledge holes. Contributions of this study are manifold.

Keywords

Knowledge holes, structural holes, boundary spanner, IS projects.

Introduction

The proliferation of knowledge communities and the need for their integration result in the emergence of flexible

organizational forms, such as cross-functional projects (e.g., ERP implementations). During cross-functional projects,

people representing different communities coordinate to achieve organizational goals. However, there is no guarantee

that by assigning people to projects, knowledge will be transmitted/created for achieving goals.

This paper introduces the idea of knowledge holes. The literature has documented the important role of boundary

spanners who use weak ties to bridge structural holes across organizations’ functional boundaries (Hargadon and

Sutton, 1997). The boundary spanner literature has generally focused on their relationship structures and how they

help bridge structural holes. We show that boundary spanners must also bridge knowledge holes (Pawlowski and

Robey, 2004). Each function contains within it specialized knowledge. When boundary spanners perform their role,

some knowledge is transmitted across the boundary. We show such knowledge does not translate successfully unless

boundary spanners understand the knowledge within the transmitting boundary. Thus, boundary spanners must span

not only the structural hole, but the knowledge hole.

We demonstrate our claim through a cross-case analysis of two departments participating in an ERP upgrade project.

In one case, boundary spanners between IT and the function understood knowledge across the functional boundary,

including syntax/meanings/consequences. Thus, solutions were localized around problems faced in the department,

and jointly implemented. In the other, this knowledge was poorly understood resulting in incomplete solutions and

unresolved problems. Our contribution is a more nuanced theorization for analyzing events and actions within and

across IS project boundaries. Our findings further suggest a shift of focus from boundary spanners’ appropriating

boundary objects for bridging knowledge holes (Carlile, 2002, 2004) to their practices and interaction for creating

common narratives about those events and actions.

Knowledge spaces of an IT project

Cross-functional IT projects involve designing/implementing IT artifacts where at least two organizational

departments are involved (Simon and Newell, 1971). In most such projects, one cross-boundary problem occurs

where the project team (i.e., internal IT members and/or consultants) must understand the non-IT problem (i.e., the

problem space) and construct IT solutions to the problem (i.e., the design space) (Purao, Rossi and Bush, 2002).

The problem space is a metaphorical space containing the team’s interpretation of user requirements in the face of a

task environment (Purao et al., 2002). It includes a mental model of “a subset of the real world with which a computer




system is concerned” (Guindon, 1990: 317). To construct the problem space, there must be an understanding of the

task/requirements, and a conceptual match between information about the task/requirements and IT technologies’

capacities/advantages/limitations/impact (Bassellier, Reich and Benbasat, 2001). Conceptual mismatch can cause

major difficulty in constructing the problem space.

The design space, also known as the implementation domain (Blum, 1989), is a metaphorical space that contains

mental representations of the team’s solutions to the problem, based on which the team creates formal

models/specifications for building systems (Purao et al., 2002). The team can explore diverse solutions based on

current IS methods/techniques (Oxman, 1997). For example, information systems can be developed in-house,

outsourced, or customized from application packages. Or an IT project can follow open source or agile development.

Different solutions can generate distinct consequences. The project team and departments involved share the

consequences of a solution (Carlile, 2002, 2004).

The knowledge domains in the problem and design space are often different (Iivari, Hirschheim and Klein, 2004).

The knowledge domain of the problem space (i.e., application domain knowledge) is often associated with the

departments/functions. For example, in an accounting-based IT project, lots of the necessary problem-space

knowledge will be associated with accounting. The literature has emphasized the importance of application domain

knowledge for solving problems in the real world. High application domain knowledge is found to prompt IT teams

to engage in strategies contingent upon the nature of a problem: a focused search for solving simple problems, and an

exploratory search for complex, ill-defined problems; in contrast, teams with low application domain knowledge tend

to be distracted by simple problems’ surface features (e.g., the order of prompts in a problem description), and cannot

meaningfully code information for solving complex problems (Khatri and Vessey, 2016).

In contrast, the knowledge domain of the design space is often technical/IT related (i.e., IS domain knowledge).

Algorithms, hardware configurations, programming languages, design languages and databases are often associated

with the design space. Technical complexity can be a barrier for departments to understand IT’s language/meanings,

and to envision consequences associated with solutions. The literature has documented the way IT projects and their

impacts is communicated to departments is consequential (Lapointe and Rivard, 2005). Further, departments’

knowledge for designing workarounds and understanding of costs/benefits/risks associated with operating an IS can

impact their choices about how to engage with the system, leading to organization-wide consequences (e.g.,

errors/inefficiencies/shadow systems) (Alter, 2014). Given the two kinds of knowledge are possessed by different

departments, it is often necessary to have individuals perform boundary spanning to bridge departments.

Boundary Spanning

Boundary spanning refers to activities, occurring at functional boundaries (Pawlowski and Robey, 2004). It is about

creating/maintaining linkages to “monitor, exchange with, or represent” (Mange and Eisenberg, 1987: 313) a group

to its environment. Boundary-spanning can be responses to the environment, or proactive moves for managing

interdependencies (Cross, Yan and Louis, 2000).

It involves a two-step process: searching out relevant information on one side, and disseminating it on the other

(Tushman and Scanlan, 1981). Each department only knows things under its purview, so departments need

information from others to adapt/coordinate goals and activities to meet organizational/environmental demands.

However, searching without disseminating creates internal silos (Roberts and O'Reilly, 1979). Thus, successful

boundary spanning must also fulfill the external representation function to important outsiders, such as

customers/suppliers/the board of directors for obtaining their support/resources (Ancona and Caldwell, 1988).

Boundary spanning can only be accomplished by those who are well connected externally/internally. Specific

boundary spanning activities include environmental scanning, contractual negotiation, task coordination (Choi, 2002),

building relationships (Druskat and Wheeler, 2003), representing projects to stakeholders (Marrone, 2010), and

routinizing information searching/acquiring/storing activities (Hargadon and Sutton, 1997).

The boundary spanning literature principally employs network structure as a proxy for information flow and assumes

connections lead to information processing across boundaries (Granovetter, 1973, 1983; Hargadon and Sutton, 1997;

Podolny and Baron, 1997; Xiao and Tsui, 2007). How the substance of the network structure is

moved/combined/transformed across structural holes is rarely studied. An exception is the work of Pawlowski and

Robey (2004) who argue that boundary spanners need to reframe/translate information from one group in terms of the




perspective of another, deliberately ask why to challenge current processes, and build cases to generate support for

their proposals.

Knowledge Hole

Structural hole theory highlights the information and control benefits boundary spanners can create in an ill-connected

network (Burt, 1992, 2005). Boundary spanners are often the main channel to access knowledge and to negotiate

solutions across boundaries. Their network position exposes them to information that reveals conditions/opportunities

otherwise invisible to those within boundaries. That information can possibly inform strategies to negotiate solutions.

A structural view of boundary spanning thus must be augmented by considering the knowledge understood by

boundary spanners in the network. Other research finds while knowledge diversity is correlated with network

structure, there is considerable variance unexplainable by network structure (Rodan and Galunic, 2004). We therefore

argue just having individuals perform boundary spanning is insufficient to bridge the problem space/design space gap.

We introduce the concept of knowledge holes, arguing that knowledge holes should be spanned so that knowledge

can be applied on both sides of the hole to solve shared problems. Knowledge holes refer to the absence of shared

syntaxes/interpretations/consequences that impedes problem-solving across boundaries. They can be considered as a

complement to “structural holes” which are missing relations that inhibit information flow between people (Burt,

1992).

Based on Carlile (2002; 2004), we argue knowledge across boundaries comprises three elements: shared

syntax/interpretations/consequences. First, a shared syntax is a medium for representing/storing/retrieving knowledge

with fixed meaning (Boland and Tenkasi, 1995; Vilhena et al., 2014). It is vocabulary specific to situations (Khatri,

Vessey, Ramesh, Clay and Park, 2006). For example, the ER model’s symbols (e.g., rectangles/diamonds) are the

syntax to represent objects, abstract concepts and their relationships in a system. While shared syntax is always

necessary to analyze problems, it is insufficient to represent semantic differences and dependencies, particularly when

novel conditions emerge (Boland and Tenkasi, 1995; Carlile, 2002). Even under stable conditions, the same concept

can have different connotations for different people. For example, the concept of production cost means different

things for the accounting and manufacturing departments. For accounting, production cost involves calculating the

accurate actual cost with consideration of equipment/machinery depreciation. For manufacturing, production cost

emphasizes the variance analysis between predefined and actual cost for monitoring/intervention.

Second, shared interpretation means there is consensus of meaning (Boland and Tenkasi, 1995; Carlile, 2002). Shared

interpretation is situated in the context and contains a group’s systems of meaning and cognitive repertoires, i.e., what

they know and how they know it. It cannot be easily transferred across boundaries, and requires translation into

another group’s perspective (Carlile, 2004). Shared interpretation can only be reached by understanding the

nuances/details of actual practice (Brown and Duguid, 1991), learning from different interpretive communities (Fish,

1980), or enhancing mental models by using cognitive support tools (Vitharana, Zahedi and Jain, 2016). Shared

interpretation recognizes even if shared syntax exists, interpretations can be different and evolve over time/space

(Carlile, 2002). For example, through interacting with users, a team discovers “data availability” not only means data

available “at users’ request” but “the liberty” to retrieve/update data when needed.

Third, shared consequences recognizes the purposive nature of knowledge as people create/apply knowledge to solve

problems (Carlile, 2002). Shared consequences involve developing common interests and making trade-offs between

actors (Brown and Duguid, 1991). Common interests motivate joint problem-solving, whereas when interests are in

conflict (i.e., solving a problem does good for one, but does harm for the other), one of the parties may be unwilling

to make changes; likewise, projected positive consequences of a solution motivate people to adopt the solution,

whereas negative ones imply the need to alter the solution or create a new one, and validate it (Carlile, 2002, 2004).

Thus, shared consequences can be achieved by identifying actors involved, convincing them they have common

problems, and persuading them to accept responsibilities and outcomes associated with the solution (e.g., learning or

transforming skills/knowledge) (Callon, 1986).

Constructing the problem space/design space requires shared syntax/interpretations/consequences, so that common

issues and potential solutions can be identified/debated/understood. Problems not represented, translated and resolved

can prove consequential over time. For example, many ERP workarounds are performed because the problem being

worked around is not represented in the system. Likewise, solutions not understood, negotiated and valued will not

receive attention and support needed to implement them. For example, users who are not well trained may ignore an

ERP system’s querying facilities in favor of doing their own analysis in MS Excel.




As we move from shared syntax, to shared interpretations, and to shared consequences, complexity increases. Shared

consequences require the existence of shared syntaxes and interpretations (Carlile, 2004). However, it is also likely

that given shared syntaxes and interpretations, actors are unwilling to make trade-offs and negotiate

solutions/responsibilities, because transforming or learning new skills can be costly.

Table 1 presents our preliminary conception of the intersection between the problem/design space and knowledge

holes (Liu, Chua and Wang, 2016). A hypothetical knowledge failure in any of the quadrants could lead to difficulties

implementing IT projects.

Problem Space Design Space

Syntactical

hole

Definition: IT’s failure to comprehend

terms/labels that describe the problem a

department faces in their task environment.

Example: IT is not clear about what the

consolidated financial statement is composed

of, such as which companies are subsidiaries or

associates, which accounting items are

included, which currencies are used etc.

Definition: departments’ failure to comprehend

terms/labels that describe IT solutions.

Example: Accounting thinks of data storage as a

group of Excel spreadsheets and does not

appreciate the additional complexity of querying

a database. They thus neglect to specify

important data cubes they need

Interpretation

hole

Definition: IT’s failure to adjust their

interpretation of the problem a department faces

in related contexts.

Example: IT fails to understand that “price” is

negotiated between buyer and seller and

assumes everything has a fixed price under all

conditions.

Definition: departments’ failure to evaluate

potential IT solutions and their implications.

Example: Purchasing is not aware that input is

required from them for IT to develop solutions to

effectively integrate with suppliers.

Consequence

hole

Definition: IT’s failure to envision how a

problem influences the departments involved

and agree on the scope of the problem.

Example: IT understands a requirement, but

thinks of the requirement as of low priority to

be delayed to the next implementation cycle.

They don’t understand not implementing this

violates accounting principles.

Definition: departments’ failure to envision how

the adopted IT solution impacts the departments

and accept ensuing responsibilities and

outcomes.

Example: Marketing thinks of an IT

implementation as a new physical device used by

data-entry people. They don’t understand the

new system will impact those who aren’t using

the system (e.g., by impacting commission

calculations). Table 1. Syntactical/interpretation/consequence holes in the problem/design space

Methodology

We conducted a cross-case analysis of a 10-month long ERP upgrade project in two functions of a Taiwanese

manufacturer (ElectroCom) (Yin, 2003). An upgrade is the replacement of an installed version with a new one from

the software vendor (Khoo and Robey, 2007). It varies in terms of scope (technical and/or functional upgrade) and

version (minor or major) (Ng, 2001). The project involved a major version and functional upgrade of a highly

customized system. Hence, bringing together diverse knowledge was needed to decide what the upgraded system

would look like. We compared how knowledge domains (i.e., application/IS domains) understood by representative

users (i.e., boundary spanners) in the two functions affected the construction of the problem/design space, and

ultimately the IT project outcome for the departments concerned.

Research site

ElectroCom is a Taiwanese manufacturer, with headquarters in Taiwan, factories in Taiwan and China, and sales

offices across Pacific Asia/Europe/the US. At the time of study, it employed over 2,500 employees worldwide.

An ERP system had been used across ElectroCom in Taiwan and China since its first implementation in 1999. The

upgrade project was expected to affect offices and factories in Taiwan and China. This project was in response to the

local Taiwanese government’s adoption of International Financial Reporting Standards (IFRS) two years later (i.e., in

2013). It upgraded the database (from Oracle 9i to 11g) and ERP version (R11.5.10 to R12.1.3) from Oracle EBS.




The upgrade was scheduled for 10 months. However, because of problems encountered, the upgrade for the marketing

division was delayed by 3 months. Three modules (finance, sales and distribution, and production) were upgraded

across 4 divisions (SCM, marketing, general administration, and manufacturing).

The upgrade project was the largest IT project in ElectroCom at the time, involving 6 internal IT members and 4

consultants. The internal IT members were highly skilled (an average company tenure about 10 years), with the most

junior one having work experience with the Oracle ERP system for about 5 years. The consultants were hired

principally to facilitate training. The ERP upgrade cost approximately 150 thousand US dollars, including an annual

fee for the maintenance/support from Oracle, and the training fee paid to Taiwanese consultants. The amount excludes

new hardware, internal IT personnel costs, and the opportunity costs of users participating in the project.

Data collection

The first researcher accessed the site about 1 year after project completion to collect retrospective data. We collected

data from multiple sources (management/non-management/consultants) and used multiple methods. Data collection

methods include (1) interviews, (2) documentation, and (3) on-site observation (Table 2). The documentation,

especially, helped combat the retrospective nature of data collection as document contents do not change over time.

Documents

Project proposal

Minutes of meetings including the kickoff and review meetings

Project schedule

Project-related training materials

On-site observation

Interviews

Stakeholders # of interviews # of distinct interviewees

Top management (including CIO) 4 2

SCM representatives 3 2

Marketing representatives 2 2

IT 7 5

Consultants (project manager) 1 1

Total 17 12

Table 2. Breakdown of data sources

We first queried two knowledgeable IT members (IT project manager-CIO and project coordinator) about divisions

affected by the implementation. Two departments (marketing/supply chain management) had the strongest differences

in outcomes. Specifically, the implementation in the marketing department was described as “a total disaster” and

“appalling” (IT project manager), whereas the supply chain management (SCM) department described the new ERP

as “richer” and the project helped “connect more dots” (SCM user). The first author thus focused data collection on

those two departments to observe contrasting implementation processes. As data collection proceeded, we

serendipitously discovered representative users’ (i.e., boundary spanners) understanding of the IT domain knowledge

affected the construction/implementation of IT solutions (i.e., bridged vs. unbridged knowledge holes).

During data collection, the first author was assigned a meeting room in ElectroCom’s Taiwan premises to conduct

interviews. Interviews with two former employees and one consultant who were key project participants were

conducted outside of the company premises.

We developed an interview protocol and adapted it to reflect interviewees’ positions and issues as the research

progressed. Interview questions focused on issues related to project management (e.g., planning/execution/control

and coordination/problem-solving/evaluation). We asked interviewees (1) their roles in the organization/project, (2)

tasks they involved, and (3) their experiences/perceptions in the project.

Data analysis

Within each case, we asked initial interviewees to identify potential boundary spanners who had more interaction

across departments. Representative users (i.e., key users) from both functions were nominated as boundary spanners.




They were required to acquire knowledge about user needs, relay knowledge to IT, and help implement IT solutions.

Based on preliminary definitions of knowledge holes in Table 1, we then focused on coding the three types of

knowledge holes in the problem space/design space. Table 3 has sample quotes. New concepts were also allowed to

emerge, and were categorized. These new codes captured contextual factors associated with knowledge holes, causal

mechanisms explaining bridged/unbridged holes, and project outcomes. The analysis followed the constant

comparison logic (Eisenhardt, 1989; Yin, 2003).

Code definition & Quote

Syntactical

hole

(problem space) Syntactical holes existed (1) if there were no common terms/labels to describe

problems/concerns departments faced, or (2) if IT failed to understand terms/labels departments used

to describe their problems/concerns; syntactical holes were bridged if IT shared and understood

terms/labels that departments used to describe problems they faced.

Many obsolete data [suppliers who they stopped trading with] were still around… They were

becoming a burden to the system. (Consultant) [hole bridged because both IT and department

described data of suppliers who they stopped trading with as the major problem]

(design space) Syntactical holes existed (1) if there were no common terms/labels to describe IT

solutions, or (2) if departments failed to understand terms/labels IT used to describe solutions;

syntactical holes were bridged if departments shared and understood terms/labels IT used to describe

IT solutions. IT told us the changed data structure a bit…we didn’t discuss much about the structure…[we’re]

thinking that this would be just another minor upgrade… (Marketing key user) [holes not bridged

because the department did not grasp the connotation of a changed data structure]

Interpretation

hole

(problem space) Interpretation holes existed, if IT failed to adjust their interpretation of the problem

a department faced in different settings; interpretation holes were bridged when IT had a mental

extension or an awareness of contingencies that could change the interpretation of the problem.

…each of [the users] dealt with distinct suppliers. Some were in charge of purchasing raw

materials, and some in charge of purchasing tools or equipment…They were exclusive contacts for

distinct suppliers. (IT, manufacturing module) [hole bridged because IT understood contingencies,

i.e., data ownership, that might require alteration of IT solutions]

(design space) Interpretation holes existed, if departments could not evaluate potential IT solutions

and their implications according to their local situations; interpretation holes were bridged when

departments had a mental extension or an awareness of contingencies that could possible change the

meaning of potential IT solutions. Users complained about why IT couldn’t just migrate the data and save them efforts and time. I

explained even if IT could do so, the changed data structure meant we had to check the data

[manually]…(SCM key user) [hole bridged because the department could evaluate alternative IT

solutions according to local situations and their implications]

Consequence

hole

(problem space) consequence holes existed, if IT failed (1) to understand how a problem or project

task influenced the department, or (2) to reach an agreement on the problem/task scope; consequence

holes were bridged, when IT (1) understood the impact of a problem/project task to departments,

and (2) reached an agreement on the problem/task scope.

...We helped migrate data of clients and orders…[users] filled extra fields manually…it’s just

garbage in, garbage out. (IT, distribution module) [hole not bridged because IT was only willing

to map out part of the problem scope and offered a partial solution]

(design space) consequence holes existed, if departments failed (1) to understand how adopted

solutions impacted the departments and (2) to accept ensuing responsibilities and outcomes;

consequence holes were bridged, when departments (1) understood the impact of adopted IT

solutions, and (2) accepted ensuing responsibilities/outcomes.




…To enter that amount of data…I kind of underestimated efforts required…also some sales orders

were to be re-entered and checked…torrential workload in the last week…(Marketing key user)

[hole not bridged because the department underestimated their responsibilities associated with

adopted IT solutions] Table 3. Representative quotes grouped according to codes

Due to space constraints, we present only one problem that provided us with rich insights (i.e., data management

problem). The problem in the SCM division is counterbalanced by a similar problem in the marketing division. This

contrast demonstrates how knowledge holes were (not) bridged. For each case, we highlight the knowledge holes in

the problem/design space.

Findings

When the project began, key users from all departments attended training sessions about the new ERP. They were

introduced to the ERP’s new features and the new financial regulations. Initially, they thought the project was mainly

to “help the finance people out” (Marketing key user) and knew “some effortful participation” (SCM key user) was

required from them.

The SCM and marketing key user had worked with IT on other projects before. They were trusted by the department

head and empowered to make decisions associated with the project.

Master data quality

Master data is a single source of common data shared across systems/applications/processes. It describes attributes

of business entities (e.g., products/sites/clients/suppliers), and is rarely changed. Different business domains thus can

use master data for their own functional needs. Managing master data to enable the use of accurate, timely and relevant

data across systems/applications is essential (Spruit and Pietzka, 2015).

ElectroCom had accumulated a large amount of master data in the ERP over time, and protected it from unauthorized

changes. The common narrative was the master data constituted “the foundation” (SCM key user) and “a critical

point of control” (SCM user) for many IT applications/systems. However, the new ERP’s data structure was more

complex. It had more fields to fill, and was presented differently (HTML pages vs. a Windows-based form).

Vignette: supplier master data

Bridging knowledge holes in the problem space: After the kick-off, IT informed the SCM key user about the task

of managing the master data (e.g., cleansing/updating/enriching). The key user then expressed her concern about

users’ unwillingness to do the task, especially if users could not foresee its benefits. After the discussion, the key user

and IT agreed the major problem with the supplier master data lay in its obsolescence which could cause inefficiencies

in daily routines and slow down the system. “Obsolescence” became the buzzword used by the SCM and IT divisions

to describe the problem.

Many obsolete data [suppliers who they stopped trading with] were still around… They were becoming a burden to

the system. (Consultant)

The key user further probed to identify areas in supply chain the new data could possibly improve. She discussed

with IT/consultants during training and informally. IT thus understood the key user anticipated the new data would

be applied to enhance supply chain’s analytical capability.

… [the SCM key user] asked consultants lots of questions…how those new data could possibly be useful…how to use

those data to streamline their process…improve their analysis…we communicated a lot informally via phone or in

person… (Project coordinator)

Because of the conversations, the team realized the data-entry interface might compromise data quality, which would

then reduce data analysis quality. The key user identified specific problems, including the lack of user familiarity

with the interface and the language barrier (i.e., Taiwanese users using an English interface). IT thus could realistically




imagine the specific difficulties users would face, and understood that users “needed some process to ensure its

quality” (IT, manufacturing module).

The key user also elaborated how users coordinated daily tasks in the SCM division. She made explicit her concern

that specific users would be overwhelmed by additional data-entry tasks. Also, she highlighted unless something was

done, these data-entry users would be unable to obtain other SCM users’ support. The key user thus lobbied IT to

allow users to directly modify certain master data elements rather than seeking changes through the organizational

bureaucracy.

The key user explained to me that users deal with distinct suppliers…They are exclusive contacts for distinct suppliers.

(IT, manufacturing module)

Bridging knowledge holes in the design space: IT and users shared assumptions about the master data, including

that it was “the foundation” (SCM key user) and “a critical point of control” (SCM user). IT initially confined the

master data task to the key user. However, the key user formed a team to sell the project across the division and roll

out training for managing master data to users.

…explained to [3 relatively junior users] what I saw in this project…we four acted like a gang, demonstrating what

to do to other users… (SCM key user)

Only [the key user] and I attended the training session [for managing master data]. We then came up with our

individual versions of SOP [standard operating procedures]. Each of us then taught another user one-on-one, asking

the user to follow the SOP to input data of two suppliers…and wrote up their own SOPs…after this, these two users

showed their SOPs to other two users and taught them…the teaching and learning snowballed from two to four, to

six, to all users… (SCM user)

Due to the training/guidance users received, they understood the data structure and access methods. IT agreed to

extend SCM users’ access to the master data. Seven SCM users participated. IT proposed two routes for solving the

problem: (1) IT would migrate data to the new ERP, and users would update/correct data; or (2) users would compile

data in Excel spreadsheets and then copy/paste the data to the new system. The key user realized the first option

would create more risk. The key user and IT used the metaphor of house renovation vs. house building to explain the

options to users.

…I explained even if IT could do so [migrated data on users’ behalf], the changed data structure meant we had to

check the data [manually].…it’s like building a new house vs. renovating one in very bad condition…we agreed with

the “house building” solution. (SCM key user)

The key user was mindful the increased workload could be a point of resistance with users. She identified users with

more critical jobs, and decreased their responsibilities.

To achieve desired data quality, the key user helped develop procedures (e.g., feedback loops) and solicited

management support to remove distractions.

…spending one whole week…in a meeting room without disruption…users formed 2-person groups…both entered

data of their suppliers, and had the other check the accuracy… (SCM key user)

Consequently, SCM users accomplished the master data task on time and with high quality, and solved a “recurrent

problem with converting PR [purchase requests] into PO [purchase orders]” (SCM user).

Counter-vignette: Client master data

Knowledge holes in the problem space: In the beginning of the project, IT informed the marketing key user about

managing client master data. IT warned the key user about the changed data structure and attendant risks (e.g.,

mismatched data). Because the marketing key user perceived the system would provide minimal enhanced

functionality to marketing, she considered the upgrade as “another minor upgrade” and the master data issue purely

as a data-entry task for solving no specific problems. She did not further probe why new data would be needed, how

it could be useful, and how historical data could be better managed.




Users didn’t see many improved system functionalities...didn’t fully grasp associated changes underneath… (IT,

distribution module)

Instead, because of the tremendous amount of client data, the marketing key user was more concerned if they could

finish this task within an assigned deadline and in a consistent format. The issue of data quality was considered a

luxury hard to achieve. In retrospect, the IT project manager described this as “a huge cognitive gap” between IT and

marketing.

…new fields to be filled…in a consistent format…three persons would render three different formats…very limited

time to verify data… (Marketing key user)

The marketing key user was the only person from the division to make decisions. To contain the project’s impact, she

hoarded project information and assigned a junior administrative assistant to manage the data-entry task on her behalf.

The marketing key user worked in her silo. She did not consult those affected by the data-entry task. She did not

communicate expectations/concerns of the new system with others. IT thus did not know activities users were

involved in and underestimated the impact of the data-entry task on their routines.

…We told them about this early, hoping they could coordinate their efforts…we didn’t find the efforts were seriously

underestimated until very late…kind of too late to react at the end… (IT, distribution module)

Knowledge holes in the design space: IT saw the project as “a reimplementation of a new ERP” (IT project

coordinator) in which master data should be reviewed/maintained. However, the marketing key user expected the

upgrade to maintain status quo, and was satisfied “as long as data didn’t cause processes to stop.” Therefore, training

was not taken seriously, and knowledge not mapped to daily practices.

IT would tell us to note down something…some terms I didn’t even understand at that time… (Marketing key user)

In addition, the key user considered users as a threat to data consistency, and wanted to minimize their participation.

IT thus suggested automatic migration of client master data to the new ERP, and one designated user to manage the

data. The key user sent the junior administrative assistant to enter and verify the data. However, the assistant received

limited training prior to starting the task. She did not understand the importance of the master data, and had little

knowledge about on-the-ground processes.

…I mainly learnt the data structure on-the-job…Later, another admin assistant was assigned to join the task…she

didn’t know much about information systems. (Marketing administrative assistant)

The marketing key user adopted the IT solution as is without considering its impact on the assistant and the support

the assistant needed. Due to the lack of other users’ support/cooperation, the assistant could only perform the task

perfunctorily. IT described this situation as “garbage in, garbage out” (IT, distribution module)

…we sent checklists to sales assistants to ask for their help to verify data…not many of them replied... (Marketing

administrative assistant)

Thus, the task was delayed and quality was below par. The junior assistant and several sales assistants were forced to

work during national holidays and experienced tremendous stress.

Table 4 summarizes knowledge holes and boundary spanning activities associated with the data management problem.




Problem space Boundary spanning Design space

SCM division

Syntactical

hole (bridged)

IT and key user

described supplier data

as obsolete

Key user discussed with IT

about operation anomalies (e.g.,

recurrent problems, slow

systems)

Key user probed future

usage/benefits of new data

Key user explained work

procedures and discussed with

IT contingency factors in their

task environment (e.g.,

distributed data, non-

participants’ lack of support)

Key user was walked through

data-entry processes to visualize

difficulties users would face

(e.g., unfamiliar system

environment, work overload,

tedious task)

Key user formed a team to sell

the project and mobilize users

Key user shared with IT the

discourse about master data

(e.g., a critical point of control)

Key user shared with IT the

metaphors to describe IT

solutions (i.e., house building

vs. renovation)

Key user shared IT’s data

quality concern given the

system environment (i.e.,

interface and language)

Interpretation

hole (bridged)

IT understood users’

expectation for better

analytics in the future

IT understood users’

need for extensive data

access

Key user understood potential

IT solutions and attendant risks

Consequence

hole (bridged)

IT understood the

impact of the data-entry

task to users

Key user was aware of the

importance of training and

guidance for users to assure

data quality

Marketing division

Syntactical

hole

IT was concerned with

data quality, but the key

user was concerned with

the deadline and format

Key user did not probe to

understand implications of the

changed data structure (e.g.,

potentials, risks)

Key user was overwhelmed and

distracted by the amount of data

Key user maintained the status

quo

Key user worked in her silo

(e.g., barring users’ participation

and feedback)

Key user described the project

as “another minor upgrade”

(vs. “a reimplementation” by

IT)

Interpretation

hole

IT lacked knowledge

about activities user

were involved

Key user accepted the

proposed IT solution as is

without questioning it or

adding her perspective

Consequence

hole

IT underestimated the

impact of the data-entry

task on users

Key user ignored

training/support/cooperation

required for data-entry tasks Table 4. Knowledge holes and associated boundary spanning activities

Discussion and implications

Our study of an ERP upgrade project across two divisions in a large manufacturer reveals the importance of bridging

knowledge holes for cross-functional IT projects. Within the ERP upgrade project, key users and IT (i.e., IT

representatives for individual modules) brought in diverse knowledge, and served the role as boundary spanners.

Research on structural holes shows boundary spanners are exposed to alternative ways of thinking, and are important

for combining/synthesizing information across boundaries (Burt, 2005). The SCM division case particularly reveals

how boundary spanners (the key user & IT representative) jointly synthesized information to develop common

narratives in the problem/design space to guide or regulate their actions. The narratives were built on common syntax

with intricacies of actual work practices (e.g., exclusive data ownership) and considerations of mutual interests

(concerns of data quality/user workload). In contrast, the marketing key user and IT representative failed to

integrate/interpret the information. They were overwhelmed by information and could not filter irrelevant information

and identify important information for actions. Therefore, either wrong/incomplete problems were identified or

wrong/incomplete solutions were imposed.

Our findings suggest bridging knowledge holes in the problem/design space is required for positive project outcomes.

First, syntactical holes need to be bridged by common words/language in the problem/design space. The SCM key

user and IT both recognized the problem was “obsolete data.” Because the two were able to exchange information

successfully, they could grasp the implications of this from the SCM users and develop plans to manage contingencies.




Specifically, they realized to make this work would mean opening up data so SCM users could self-query, and that

SCM users would need to be coached to understand how updated master data would benefit them.

Being able to visualize these consequences, in turn required both the SCM key user and IT appreciated how the

changes would affect the SCM department. This in turn meant they had to understand the words the other used,

translate words when needed to communicate consequences, and use the right words to persuade SCM users to take

attendant responsibilities (e.g., acquiring skills for managing data).

In contrast, when the same scenario played in the marketing department, IT did not appreciate how the data-entry task

would affect marketing users. Similarly, the marketing key user did not appreciate the changed data structure’s

implications. Therefore, simple solutions with damaging consequences (e.g., assigning untrained assistants to

enter/verify data) were implemented. The failure of both IT and marketing to appreciate the on-the-ground situation

and consequences of their actions similarly stemmed from different language and understanding of each other.

Our findings thus confirm the importance of spanning syntax, interpretation, and consequence holes. Our findings

also suggest ways to bridge said holes.

Our findings suggest one way of bridging the syntax hole is via using common words/labels to build common

narratives. Common narratives connect characters with a sequence of events that have shared meanings (Cunliffe and

Coupland, 2012). Within organization studies, narratives are found to be a means of making sense of (Boje, 1995) or

giving sense to (Currie and Brown, 2003) a situation. In the SCM department, the key user and IT used common

words (obsolete data, a critical point of control, house building) to construct narratives to describe the problem/design

space. They thus could make sense of and give sense to the difficulties users faced (e.g., concerns of other users’

commitment) and IT solutions.

Second, at the interpretation level, more particularistic/local clues need to be integrated to the common narratives

about the problem/design space. Through probing contingency factors and processes (discussed/walked through

users’ data-entry procedures), the SCM key user and IT gained insight into users’ task environment, including direct,

indirect, distal and near causes (e.g., system interface, task coordination, distractions) of some failure situations (e.g.,

data quality concern, perceived stress). IT thus could refine IT solutions accordingly (e.g., extensive data access for

users).

Finally, consequence holes can be bridged by creating venues for stakeholders to negotiate problem scopes and learn

new knowledge/skills. Because the SCM key user and IT routinely shared information, sought opinions from each

other, and helped each other, a community of practice was formed beyond functional boundaries. The SCM key user

also articulated her vision to users, arranged venues for their learning/working together, and consulted their opinions

about decisions that would affect them. IT and SCM department thus could see mutual benefits in the project,

collectively learn skills and knowledge, and value their new competence.

Our contributions build on a conceptualization of knowledge holes that is empirically studied in a real-life IS project.

We demonstrate knowledge holes cannot be bridged before the syntactical, interpretation, and consequence holes in

the problem/design space are bridged. Based upon Carlile (2002, 2004), our conceptualization provides a more

nuanced theorization for analyzing events and actions within and across IS project boundaries. Our findings further

suggest a shift of focus to boundary spanners’ active practices and interaction for creating common narratives about

those events and actions.

Our findings concur with the foundational role of shared syntax in bridging knowledge holes (Carlile, 2004). Shared

syntax can not only be used to transfer information accurately, but help develop common narratives with local details

and considerations of mutual interests to regulate one’s thought/action.

Practically, this study explains how boundary spanners in big IS projects (e.g., key users/IT) may act to bridge

knowledge holes. Our findings demonstrate boundary spanners bridge knowledge holes via building common

narratives in the problem/design space. That is, boundary spanners use common labels/words/language to construct

common narratives; integrate local clues from users’ work context to said narratives; and create venues for negotiating

problems and learning new knowledge.




Conclusion

The proliferation of specialized knowledge communities highlights the importance of boundary spanning. In this

study, we propose and empirically study the concept of knowledge holes in a case study of an ERP upgrade. Our

findings suggest bridging knowledge holes is a necessary condition for positive project outcomes. The concept of

knowledge holes thus complements the concept of structural holes for explaining distinct project outcomes.

Conditions for bridging the knowledge holes is to bridge syntactical, interpretation and consequence holes separating

functional groups in large IS projects.

References

Alter, S. (2014). Theory of workarounds. Communications of the Association for Information Systems, 34, 1, 1041-

1066.

Ancona, D. G. and Caldwell, D. F. (1988). Beyond task and maintenance defining external functions in groups. Group

& Organization Management, 13, 4, 468-494.

Bassellier, G.Reich, B. H. and Benbasat, I. (2001). Information technology competence of business managers: A

definition and research model. Journal of Management Information Systems, 17, 4, 159-182.

Blum, B. I. (1989). A paradigm for the 1990s validated in the 1980s. Proceedings of the American Institute of

Aeronautics and Astronautics Conference.

Boje, D. M. (1995). Stories of the storytelling organization: A postmodern analysis of Disney as “Tamara-Land”.

Academy of Management Journal, 38, 4, 997-1035.

Boland, R. J. and Tenkasi, R. V. (1995). Perspective making and perspective taking in communities of knowing.

Organization Science, 6, 4, 350-372.

Brown, J. S. and Duguid, P. (1991). Organizational learning and communities-of-practice: Toward a unified view of

working, learning, and innovation. Organization Science, 2, 1, 40-57.

Burt, R. S. (1992). The social structure of competition. In N. Nohria & R. G. Eccles (Eds.), Networks and

Organizations: Structure, Form, and Action (pp. 57-91). Harvard Business School Press,Boston.

Burt, R. S. (2005). Brokerage and Closure: An Introduction to Social Capital. Oxford University Press, Oxford, UK.

Callon, M. (1986). Some elements of a sociology of translation: domestication of the scallops and the fishermen of St

Brieuc Bay. Power, Action and Belief: A New Sociology of Knowledge, 32, 196-233.

Carlile, P. R. (2002). A pragmatic view of knowledge and boundaries: Boundary objects in new product development.

Organization Science, 13, 4, 442-455.

Carlile, P. R. (2004). Transferring, translating, and transforming: An integrative framework for managing knowledge

across boundaries. Organization Science, 15, 5, 555-568.

Choi, J. N. (2002). External Activities and Team Effectiveness Review and Theoretical Development. Small Group

Research, 33, 2, 181-208.

Cross, R. L.Yan, A. and Louis, M. R. (2000). Boundary activities in boundaryless' organizations: A case study of a

transformation to a team-based structure. Human Relations, 53, 6, 841-868.

Cunliffe, A. and Coupland, C. (2012). From hero to villain to hero: Making experience sensible through embodied

narrative sensemaking. Human Relations, 65, 1, 63-88.

Currie, G. and Brown, A. D. (2003). A narratological approach to understanding processes of organizing in a UK

hospital. Human Relations, 56, 5, 563-586.

Druskat, V. U. and Wheeler, J. V. (2003). Managing from the boundary: The effective leadership of self-managing

work teams. Academy of Management Journal, 46, 4, 435-457.

Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review, 14, 4, 532-

550.

Fish, S. E. (1980). Is There a Text in This Class?: The Authority of Interpretive Communities. Harvard University

Press, Cambridge, MA.

Granovetter, M. (1973). The strength of weak ties. American Journal of Sociology, 78, 6, 1360-1380.

Granovetter, M. (1983). The strength of weak ties: A network theory revisited. Sociological Theory, 1, 1, 201-233.

Guindon, R. (1990). Designing the design process: Exploiting opportunistic thoughts. Human-Computer Interaction,

5, 2-3, 305-344.

Hargadon, A. and Sutton, R. I. (1997). Technology brokering and innovation in a product development firm.

Administrative Science Quarterly, 42, 4, 716-749.

Iivari, J.Hirschheim, R. and Klein, H. K. (2004). Towards a distinctive body of knowledge for Information Systems

experts: Coding ISD process knowledge in two IS journals. Information Systems Journal, 14, 4, 313-342.




Khatri, V. and Vessey, I. (2016). Understanding the Role of IS and Application Domain Knowledge on Conceptual

Schema Problem Solving: A Verbal Protocol Study. Journal of the Association for Information Systems, 17,

12, 759-803.

Khatri, V.Vessey, I.Ramesh, V.Clay, P. and Park, S.-J. (2006). Understanding conceptual schemas: Exploring the role

of application and IS domain knowledge. Information Systems Research, 17, 1, 81-99.

Khoo, H. M. and Robey, D. (2007). Deciding to upgrade packaged software: A comparative case study of motives,

contingencies and dependencies. European Journal of Information Systems, 16, 5, 555-567.

Lapointe, L. and Rivard, S. (2005). A multilevel model of resistance to information technology implementation. MIS

Quarterly, 29, 3, 461-491.

Liu, G. H.Chua, C. E. and Wang, E. T. (2016). Managing knowledge holes in large IS projects. Pacific Asia

Conference on Information Systems, Chiayi, Taiwan.

Mange, P. and Eisenberg, E. (1987). Emergent communication networks. In F. M. Jablin, L. L. Putnam, K. H. Roberts

& L. W. Porter (Eds.), Handbook of Organizational Communication: An Interdisciplinary Perspective (pp.

304-342). Sage Publications,Beverly Hills, CA, .

Marrone, J. A. (2010). Team boundary spanning: A multilevel review of past research and proposals for the future.

Journal of Management, 36, 4, 911-940.

Ng, C. S. P. (2001). A decision framework for enterprise resource planning maintenance and upgrade: A client

perspective. Journal of Software Maintenance, 13, 6, 431-468.

Oxman, R. (1997). Design by re-representation: A model of visual reasoning in design. Design Studies, 18, 4, 329-

347.

Pawlowski, S. D. and Robey, D. (2004). Bridging user organizations: Knowledge brokering and the work of

information technology professionals. MIS Quarterly, 28, 4, 645-672.

Podolny, J. M. and Baron, J. N. (1997). Resources and relationships: Social networks and mobility in the workplace.

American Sociological Review, 62, 673-693.

Purao, S.Rossi, M. and Bush, A. (2002). Towards an understanding of the use of problem and design spaces during

object-oriented system development. Information and Organization, 12, 4, 249-281.

Roberts, K. H. and O'Reilly, C. A. (1979). Some correlations of communication roles in organizations. Academy of


Rodan, S. and Galunic, D. C. (2004). More than network structure: How knowledge heterogeneity influences

managerial performance and innovativeness. Strategic Management Journal, 25, 6, 541-556.

Simon, H. A. and Newell, A. (1971). Human problem solving: The state of the theory in 1970. American Psychologist,

26, 2, 145-159.

Spruit, M. and Pietzka, K. (2015). MD3M: The master data management maturity model. Computers in Human

Behavior, 51, 1068-1076.

Tushman, M. L. and Scanlan, T. J. (1981). Boundary spanning individuals: Their role in information transfer and their

antecedents. Academy of Management Journal, 24, 2, 289-305.

Vilhena, D. A.Foster, J. G.Rosvall, M.West, J. D.Evans, J. and Bergstrom, C. T. (2014). Finding cultural holes: How

structure and culture diverge in networks of scholarly communication. Sociological Science, 1, 221-238.

Vitharana, P.Zahedi, M. F. and Jain, H. K. (2016). Enhancing analysts' mental models for improving requirements

elicitation: A two-stage theoretical framework and empirical results. Journal of the Association for

Information Systems, 17, 12, 804-840.

Xiao, Z. and Tsui, A. S. (2007). When brokers may not work: The cultural contingency of social capital in Chinese

high-tech firms. Administrative Science Quarterly, 52, 1, 1-31.

Yin, R. K. (2003). Case Study Research: Design and Methods. Sage Publications, London.

Niederman & Chudoba Implementing Strategy Through IS Projects



Implementing Strategy Through IS Projects: A Theory Building Literature Review

Fred Niederman

St. Louis University

[email protected]

Katherine M. Chudoba

Utah State University

[email protected]

ABSTRACT

In project management, a growing area of importance is “benefits realization”, including techniques to achieve on

time and on budget efficiency. Broadly, it refers to aligning efforts with strategic purpose, realizing the purposes for

which the project was selected, and gaining benefits from its effectiveness. There is a dearth of writing about how

strategy is realized through IS projects, particularly at the program or project level. Our purpose is to create a clear,

more detailed and predictive linkage between organizational strategies and IS project enactments by addressing the

question, “How do organizations translate strategy through IT-enabled strategic initiatives?” In this RIP paper, we

lay the foundation for our review and describe the process for our examination. By examining mechanisms for

executing strategy, findings should be relevant both to academics in terms of providing insights for further testing

and/or refinement, as well as practice for forming a basis for predicting outcomes and selection of execution process

techniques.

Keywords

Project management, IS project development, strategy, IS project outcomes

INTRODUCTION

Project management, information systems (IS), and strategy are domains that cross organizational functions.

Researchers often draw on one domain to inform research in a second. For example, research at the intersection of

project management and IS has found that even when project management best practices such as user engagement are

followed, IS development projects are not always successful (e.g., Gallivan and Keil, 2003). Similarly, there is a large

corpus around IS alignment with corporate strategy (e.g., Chakravarty, Grewal, and Sambamurthy, 2013; Setia,

Sambamurthy, and Closs, 2008), and researchers have examined strategic management processes to formulate and

implement strategy at the corporate level (i.e., Hill & Jones, 2001; Mintzberg and Quinn, 1996; Thompson, 2001).

What is missing is how corporate strategy gets translated into implementation, particularly at the program or project

level. In practice, the two sets of activities are well connected; projects and programs are important ways for strategy

to be implemented in the enterprise and we ought to understand much better how this occurs (Kaiser et al., 2015). As

expressed by Näsholm and Blomquist (2015, p. 60),“Programs are often of a strategic nature for the organization and

have broad long-term implications (Artto and Kujala, 2008) and they can even be considered as tools for strategy

implementation to achieve organizational objectives (van Buuren, Buijis, and Teisman, 2010)”. Examining the

intersection of these three domains offers the opportunity for new insights into best practices for more impactful IT-

enabled projects and organizational strategy. The overarching objective is to address the question, “How do

organizations translate strategy through IT-enabled strategic initiatives?”

In this research in progress (RIP) paper, we lay the foundation for our review and describe the process for our

examination. In the background section, we elaborate on the goal of our investigation, define key terms, establish its

boundaries, and present a set of guiding questions that expand on our research objective. Next, we briefly describe

our methods, and then present the results of an initial and very preliminary analysis. We conclude with a description

of the expected contribution of our review and theory building effort.

BACKGROUND

After an initial examination, we find no literature in any of the three key domains that directly addresses the question

presented above. Ashurst and colleagues (2008) proposed the benefits realization capability model, which posits that




benefits from systems implementation are derived from following a series of best practices, based on their evaluation

of successful IT project implementations. Our interest is broader, including the initial decision to address

organizational strategy through IT systems, and considering both successful and failed projects. The academic and

popular presses are full of articles that describe failures across project management and strategy domains (e.g., Sull

and Sull, 2015; Workfront, 2014). This is an enduring problem in practice, and an investigation across the three

domains may yield theoretical and practical insights to address this problem (Lyytinen and Grover, 2017). The idea

that projects are a mechanism for implementing organizational strategy is so deeply embedded in common thinking

that it is rarely questioned or studied. As phrased by Pinto (2015) in a popular project management textbook: “Projects

are building blocks in the design and execution of organizational strategies” (p. 6).

Teams working on particular tasks (e.g. doing projects) is intuitively a key to achieving strategic goals, but this is not

necessarily the same as guiding projects to on-time and on-budget outcomes. Nor does it guarantee that projects will

fulfill their ultimate objective to advance organizational strategy even when efficiently delivered (Hjelmbrekke,

Laedre, and Lohne, 2014). Our purpose is to create a clear, more detailed and predictive linkage between

organizational strategies and IT-enabled project enactments. We are particularly focused on the “how” question

regarding how strategies can be effectively moved forward by IS projects. Assuming that no extant theories will be

found that provide theoretical explanation and predictive power relative to the question of interest, we will draw on

insights from our review and analysis of the literature to offer a theoretical model and set of propositions to guide

future research.

This study uses two perspectives to examine implementation of strategy through IT-enabled projects. First, it

examines the broader issue of what has been learned so far, particularly addressing whether there are mechanisms

designed to implement strategy through projects and evidence about their effectiveness. Second, it addresses how

such knowledge might be applicable in the realm of projects focused primarily on the development and

implementation of IS. The topic represents the confluence of three streams of thought pertaining to strategy, IS

projects, and project management broadly. We will scan each of these literature streams for reference to the

implementation of strategy through IS projects, to note linkages or missing links in the extant knowledge base, and to

use these insights to suggest a theoretical model in the form of propositions to guide future research.

We follow Webster and Watson’s (2002) guidance by first describing the key concepts and delineating the boundaries

of our research, along with a set of questions driving our investigation. Next, we describe our methods, followed by

a short example of how the analysis might unfold. Moving from this RIP to the full paper, this will be followed by a

model and propositions to guide future research. Our process is congruent with Vom Brocke and colleagues’ description of how to conduct an MIS review. Our objective is explanation building through a theoretical review.

Our scope is broad, and sources of material will include both conceptual and empirical research. Further, we assume

knowledge exists regarding organizational strategy and its enactment in general, with execution through projects as

one approach. We assume knowledge exists about better ways to implement IT-enabled projects, although not

necessarily ones that aim to maximize strategic goals. In sum, we will review the following literatures: project

management in terms of enacting strategic purposes, strategy pertaining to implementation, and IT implementation

and IT project management. We will also evaluate the enterprise project governance literature (e.g., Dinsmore and

Rocha, 2012), which integrates organizational strategy and effective project conduct.

Organizational strategy will be considered mainly from a top-down formal strategy planning perspective. This is a

dominant perspective on strategy and is most likely to initiate a strategic push toward the design and execution of IS

projects. Some scholars view strategy as emergent, most notably Mintzberg (1996), and we will examine issues of de

facto strategy that may be emergent from IS project processes and deliverables.

Projects are activities with a beginning and end aimed at creating particular products and/or services that did not exist

before. They vary on many dimensions including size, the nature of the product/service, their complexity, the

membership and structure of teams, the work packages, the risks, and the stakeholder characteristics (Project

Management Institute, 2013). More specifically, IT-enabled projects are focused activities with a beginning and end

aimed at creating, deploying, changing, organizing, or otherwise structuring the computing and information resources

of an organization. Such projects may address the range of levels of the technology stack from platform to content,

with software applications somewhere in between. IS projects are generally of a socio-technical nature, implying

some adjustment to the technical state or tools available within an organization as well as to the skills, approaches,




assignments, and understandings of the humans interacting with this technology. Thus, project management “is the

application of knowledge, skills, tools, and techniques to project activities to meet the project requirements” (Project

Management Institute, 2013).

We bound our investigation by only looking at details of IS project implementation as they apply to the enactment of

strategy. Among the distinctions we make are to focus on strategic initiatives and projects, rather than compliance or

emergency project development (e.g., Larson and Gray, 2014). Issues of strategic alignment of organizations and IS

departments are largely be outside the boundary of this study, other than where they suggest or discuss projects per se

as a mechanism for integrating alignment. General knowledge about how to run effective IS projects, such as critical

success factors (CSFs) for agile or traditional approaches will be outside the scope of the study other than where such

CSFs affect the ability to implement strategic goals.

Guiding Questions

The following questions guide our investigation and theory building.

• What is known about how IT-enabled projects can be used to enact organizational strategy?

• What is missing in the general project management, IS implementation, and organizational strategy

literatures relative to IS project execution and strategy realization?

• Are there processes, factors, techniques, or approaches that differentiate more from less successful

enactment of firm strategy through the use of IS projects?

• Do IT-enabled projects differ from other projects relative to more effective strategy execution?

• Are there macro processes for handling the class of IS projects or micro processes for actions within IS

projects that make them more effective at enacting organizational strategy?

• Can we integrate different directions of influence: how IS project management capabilities constrain the

range of strategic foci for an organization as well as how organizational strategy can influence the

organization and execution of IS projects toward manifesting strategic vision?

METHODS

Because there is little research directly targeting the mechanics of implementing strategy through projects and

programs, our review will examine three separate literature streams: organizational strategy, IS projects, and project

management. Each of these offers the possibility of presenting direct observations of the interaction between

organizational strategies and IS projects. We will search various digital libraries, most notably ABI Inform, ACM

digital library and Business Source Premier, based on key words focused on all three topics and each pair of topics.

In anticipation of large numbers of “hits”, we will select articles from 3-10 top journals in each of these literature

streams. For example, in MIS, we will select articles from the eight journals in the senior scholars’ basket, and

Information and Organization and Information and Management, which both have a significant number of

manuscripts that address organizational level IS issues. In project management, we will select articles from the

discipline’s three top journals - International Journal of Project Management, Project Management Journal, and

International Journal of Managing Projects in Business. We will make a similar selection for strategy including

Organization Science, Academy of Management Journal, Academy of Management Review, Journal of Management,

Journal of Strategic Management, Management Science, and Strategic Management Journal.

We will extend our search using a snowball technique by reviewing the reference lists in the articles we examine for

additional relevant articles. Finally, we will use ABI Inform and/or Google Scholar to identify papers that have cited

seminal articles within the boundary of our review to find less obvious but important references to our research

question. We expect the vast majority of citations of these key articles to not offer much new information regarding

our research question, but consider them worthy of scanning for the sake of completeness.




Analysis

Each paper is reviewed for information relevant to our research question. Where such relevant information is found

we (1) extract those ideas, findings, definitions, and/or comments that apply to our research question; (2) qualitatively

use techniques as described by Miles and Huberman (1994) and Corbin and Strauss (2014) to compare and contrast,

to categorize, to quantify (where applicable), and to find patterns and observe the absence of extant knowledge; and

(3) integrate these observations into a theoretical model and generate new propositions to guide future research.

Specifically, we rely on abductive logic to sort and order the extracted content of these papers into a coherent pattern

to facilitate the organization of related knowledge. We use a number of recommended theory building techniques

including problematiztion (Alvesson and Sandberg, 2011) and contrastive explanation (Tsang and Ellsaesser, 2011).

Analysis is supplemented with tactics of memoing, discussion to consensus, and theoretical saturation relative to a

stopping rule for consideration of additional literature. We will provide a chain of evidence to illustrate how we

triangulated and moved from an analysis of articles to conclusions. The objective is to find a categorization scheme

that holds value as a way to organize the literature on this topic and, thereby, create theory based on the collected

observations to date from the field. We have started with the project management literature as it seemed the most

likely place to find answers already extant to our research question, but early examination shows that while this is a

sometimes discussed phenomenon, there is little development of a detailed theoretical account for how this linkage is

created and maintained.

Level of Analysis

The methodological level of analysis is the article or study. We examine each of these with a primarily qualitative

approach, although some quantification may meaningfully arise from the analysis. We expect that the content of the

articles may span various levels of analysis. Some literature may link strategy with organizational outcomes at a firm

level. Other literature may link particular IS projects with strategic alignment. We do not anticipate research that

integrates project and firm level results, but hold open the possibility. Any theoretical model we present will address

this issue and discuss associated measurement issues (Klein and Kozloski, 2000).

INITIAL ANALYSIS

We have generated a set of 27 papers in the project management domain, published in the three targeted premier

journals in the field. These are included in the Reference List. Initial analysis by one author has revealed (1) that no

identified project management journal articles directly address the interaction of IS project management and strategy

implementation in a thorough, theory-oriented, and compelling manner and that (2) the accumulated knowledge about

project management, IS projects, and strategy execution present tantalizing glimpses and possibilities for extrapolation

and theory building.

Our preliminary analysis surfaced two important distinctions or dimensions that need to be specified to understand

the contribution of individual studies. These are the level of aggregation of projects and the actions, policies, and

plans for varied project stages. We anticipate finding additional dimensions when examining further literature and

will consider issues such as long term and short term effects, effects of strategy types and/or quality. For example, a

poorly formulated strategy may be more difficult to guide even well run IS projects. Another promising avenue may

derive from the directionality of influence: how different strategies affect the design of IS projects versus how

variation in the execution of IS projects may enable or constrain strategy implementation at a firm level.

Temporality is another interesting dimension. Targeting variations based on project phase, for example, we can see

that the work packages associated with a particular project may vary in their independence. Where they are highly

independent, they may be performed in any order. Where they are highly interdependent they must be performed in

a particular order. At a detailed work level, a program must be coded before it can be tested, and tested before

debugged. However, for most projects at least a moderate level of interdependence creates a fairly regular series of

types of work package execution in a particular order. These can be viewed in terms of (1) project planning and

initiation, (2) project execution, and (3) project follow up. In terms of executing the organization’s strategic plans

through project activity, each of these stages holds risks and opportunities.




The first stage involves what Pinto (2015, p. 13) calls conceptualization and planning. We combine the two in

considering the first stage as all activities prior to the beginning of execution. The line between conceptualization and

planning in practice is a thin one particularly considering how much variation there is in actual implementation of

projects versus normative description of key activities. An important portion of project planning involves project

selection: (1) strategies for selection; (2) goal and objective selection of a larger scale than individual projects (e.g.

how selection can add up to a set of projects that through synergy provide benefits beyond the sum of the products of

each project singly); and (3) consideration of particular projects with go-no-go decisions and where they may be along

the continuum of high to zero alignment with strategic aims. Strategy operates relative to project planning in two

simultaneous ways. First, it implicitly or explicitly suggests an alignment of the project’s goals and activities with

those of the larger organization. Second, it suggests internal strategies for approaching the mechanisms by which the

project operates to retain efficiency while effectuating its goals.

The second stage addresses project execution. A stream of literature pertaining to global project management suggests

that communication about overall global strategy is one of four keys to global project success (Aarseth, Rolstadås,

and Andersen, 2014). This study distinguishes between a global strategy and a global project strategy. The former

refers to a global business strategy, while the latter refers to the local adjustments needed to enact that overall strategy

(such that projects adjust to local culture, preferences, labor, government, regulations, yet still support the overall

business strategy). The authors advocate relationship management approaches toward customizing projects, or

portions of large global ones, to local environments. Three particular activities are promoted – identifying key local

stakeholders (who may have very different attitudes from one location to another), develop global human resource

management policies, and define global systems such as decision making, communication and reporting structures as

well as information and format standards.

The third stage involves project follow up. This may include change management whereby the organization changes

its personnel, structure, and/or processes in order to take advantage of the new capabilities created through the project.

This is typically a fluid interplay where the organization changes and the project products may also be adjusted.

Moving forward, we will methodically examine the three literature streams. The second author will review these

already identified articles for verification and extraction of additional content; both authors will extend this review to

IS and organizational strategy literatures.

CONTRIBUTION AND CONCLUSION

This literature review will examine what has been learned so far about mechanisms designed to implement strategy

through IS projects and whether there is evidence that these techniques have been effective. It addresses how such

knowledge might be applicable specifically in the realm of projects focused primarily on the development and

implementation of information technology. It is clear that (1) a very high percentage of projects, particularly those

creating new products and/or services internally or externally to firm involve in part or whole the development or

deployment of information technologies; (2) that by their nature much of the process of developing IS is of an

intangible nature and functions differently (e.g. stakeholders, risks, schedule, and assessing partial completion of

tasks) from projects; and (3) that IS projects present a very rich target where understanding, predictability, and

helpfulness can have a significant positive impact on practice. In summary, it is always difficult to be precise on what

will be found with a work in process. Initial searching of the literature shows: (1) that indeed this is a topic not

explicitly addressed often; (2) that generates new and interesting questions; and (3) that promises new insights through

the arranging of and extrapolation among extant materials.

Both IS and strategy are part of the central core of interest for the SIGITPROJMGMT community. This study will

illuminate the connection between project management, an organization’s strategy, and specifically how IS projects

may or may not instantiate them. The topic, therefore, is a formidable complement to the study of systems and how

they lead to advancing organizational strategies. By examining mechanisms for executing strategy, findings should

be relevant both to academics in terms of providing insights for further testing and/or refinement as well as practice

for forming a basis for predicting outcomes and selection of execution process techniques. The study pertains to

consideration of a topic not well covered but one that appears on “the shop floor” consistently in practice. We are

focused on theory building but also on providing utilitarian understanding of the phenomenon (Galliers, Jarvenpaa,

Chan, and Lyytinen, 2012). We believe implications of the study’s findings will be relevant broadly to those interested




in project management generally, IS management, and in strategy, particularly in terms of its execution. We fully

expect that future work will include the potential for (1) empirically testing the propositions we put forth and (2)

further exploring parallel or even conflicting alternative approaches to executing strategy through IS projects.

In project management, a growing area of importance pertains to benefits realization: techniques to achieve on time

and on budget efficiency (Ashurst et al., 2008). However, in the broader sense it refers to aligning efforts with strategic

purpose and realizing the purposes for which the project was selected and gaining benefits from its effectiveness. How

strategy is realized through IS projects represents a timely and important area of study. Our contributions are to (1)

collect what is known about this phenomenon in current literature; (2) emphasize the mechanisms and processes by

which such strategic benefits are realized; and (3) consider specifically the role of IS and both behavioral and technical

issues that may impact the effectiveness of particular mechanisms.

REFERENCES

Aarseth, W., Rolstadås, A., and Andersen, B. (2014) Managing organizational challenges in global projects,

International Journal of Managing Projects in Business ,7,1, 103-132.

Ashurst, C., Doherty, N. F. and Peppard, J. (2008) Improving the Impact of IT Development Projects: The Benefits

Realization Capability Model, European Journal of Information Systems, 17, 4, 352-370.

Alvesson, M. and Sandberg, J. (2011) Generating research questions through problematization, Academy of

Management Review, 36,2, 247–271.

Artto, K. and Kujala, J. (2008) Project business as a research field, International Journal of Managing Projects in

Business, 1,4, 469-497.

Chakravarty, A., Grewal, R., and Sambamurthy, V. (2013) Information technology competencies, organizational

agility, and firm performance: Enabling and facilitating roles, Information Systems Research, 24,4, 976-997,

1162-1163,1166.

Corbin, J. and Strauss, A. (2014) Basics of qualitative research, 4th Edition, Sage Publications.

Dess, G., McNamara, G., and Eisner, A. (2016) Strategic management: Text and cases, McGraw Hill, New York.

Dinsmore, P. C. and Rocha, L. (2012) Enterprise Project Governance. A Guide to the Successful Management of

Projects Across the Organization, American Management Association, New York.

Galliers, R., Jarvenpaa, S., Chan, Y., Lyytinen, K. (2012) Strategic information systems: Reflections and prospectives,

The Journal of Strategic Information Systems, 21, 2, 85-90.

Hill, C. and Jones, G. (2001) Strategic management: An integrated approach, Houghton Mifflin.

Hjelmbrekke, H., Lædre, O., Lohne, J. (2014) The need for a project governance body, International Journal of

Managing Projects in Business, 7, 4, 661-677.

Klein, K. and Kozlowski, S. (2000) From micro to meso: Critical steps in conceptualizing and conducting multilevel

research, Organizational Research Methods, 3, 3, 211-236.

Larson, E., & Gray, C. (2014) Project Management: The Managerial Process (6th ed.). New York: McGraw-Hill.

Lyytinen, K. and Grover, V. (2017) Management misinformation systems: A time to revisit? Journal of the

Association for Information Systems, 18, 3 (Mar 2017), 206-230.

Miles, M. and Huberman, A. (1994) Qualitative data analysis: An expanded sourcebook, 2nd ed., Sage Publications,

1994.

Mintzberg, H. and Quinn, J. (1996) The strategy process: Concepts, contexts, cases. Prentice Hall.

Näsholm, M. and Blomquist, T. (2015) Co-creation as a strategy for program management, International Journal of


Pinto, J. (2015) Project management: Achieving competitive advantage, 4th Ed., Pearson, New York.

Project Management Institute (2013). A guide to the project management body of knowledge, 5th Ed., Newtown

Square, PA, USA.

Setia, P., Sambamurthy, V., and Closs, D. (2008) Realizing business value of agile IT applications: Antecedents in

the supply chain networks, Information Technology and Management, 9, 1, 5-19.

Sull, D., Homkes, R., and Sull, C. (2015) Why strategy execution unravels and what to do about it, Harvard Business

Review, March.

Thompson, J. (2001) Understanding corporate strategy. London: Thompson Learning.

Tsang, E. and Ellsaesser, F. (2011) How contrastive explanation facilitates theory building,” Academy of Management

Review, 36, 2, 404-419.

http://search.proquest.com.ezp.slu.edu/abicomplete/docview/1467825081/9EA6101031EE4876PQ/4?accountid=8065




van Buuren, A., Buijs, J. and Teisman, G. (2010) Program management and the creative art of coopetition: dealing

with potential tensions and synergies between spatial development projects, International Journal of Project

Management, 28, 7, 672-682.

Vom Brocke, J., Simons, A., Riemer, K., Niehaves, B., Plattfaut, R. and Cleven, A. (2015) Standing on the Shoulders

of Giants: Challenges and Recommendations of Literature Search in Information Systems Research,

Communications of the Association for Information Systems, 37, 1, 205-224.

Webster, J. and Watson, R. (2002) Analyzing the past to prepare for the future: Writing a literature review, MIS

Quarterly, 26, 2, xiii-xxiii.

Workfront (2014) https://resources.workfront.com/project-management-blog/project-failure-10-famous-failures-and-

5-ways-to-spot-them-before-they-happen?proxy=/blog/

Results of Search on Key Words - ABI Inform May 4, 2017 “Project Management” and “Strategy Implementation” in Project Management Journal, International Journal

of Project Management, and International Journal of Business Project Management

Aarseth W., Rolstadås, A., and Andersen, B. (2014) Managing organizational challenges in global projects,

International Journal of Managing Projects in Business, 7, 1, 103-132.

Aramo-Immonen, H., Koskinen, K., and Porkka, P. (2011) The significance of formal training in project-based

companies, International Journal of Managing Projects in Business, 4, 2, 257-273.

Artto, K. and Kujala, J. (2008) Project business as a research field, International Journal of Managing Projects in

Business, 1, 4, 469-497.

Bower, D. and Finegan, A. (2009) New approaches in project performance evaluation techniques, International

Journal of Managing Projects in Business, 2, 3, 435-444.

Carrillo, P., Robinson, H., Al-Ghassani, A., and Anumba, C. (2004) Knowledge management in UK construction:

Strategies, resources, and barriers, Project Management Journal, 35, 1, 46-56.

Grundy, T. (1988) Strategy implementation and project management, International Journal of Project Management,

16, 1, 43-50.

Hauc, A. and Kovac, J. (2000) Project management in strategy implementation: Experiences in Slovenia,

International Journal of Project Management, 18, 1, 61-67.

Hjelmbrekke, H., Lædre, O., Lohne, J. (2014) The need for a project governance body, International Journal of


Ika, L., Diallo, A., and Thuillier, D. (2010) Project management in the international development industry: The

project coordinator's perspective, International Journal of Managing Projects in Business, 3, 1, 61-93.

Ives, M. (2005) Identifying the Contextual Elements of Project Management within Organizations and Their Impact

on Project Success, Project Management Journal, 36, 1, : 37-50.

Julie B. (2009) Managing delivery of sanitation infrastructures for poor communities: Decentralizing without

penalizing, International Journal of Managing Projects in Business, 2, 3, 355-369.

Kaiser, M., El Arbi, F., and Ahlemann, F. (2015) Successful project portfolio management beyond project selection

techniques: Understanding the role of structural alignment, International Journal of Project Management,

33, 1, 126.

Killen, C. and Hunt, R. (2010) Dynamic capability through project portfolio management in service and

manufacturing industries, International Journal of Managing Projects in Business, 3, 1, 157-169.

Lau, E. and Rowlinson, S. (2011) The implications of trust in relationships in managing construction projects,


Leybourne, S. (2007) The Changing Bias of Project Management Research: A Consideration of the Literatures and

an Application of Extant Theory, Project Management Journal, 38, 1, 61-73.

Morris, P. and Jamieson, A. (2005) Moving From Corporate Strategy to Project Strategy, Project Management

Journal, 36, 4, 5-18.

Näsholm, M. and Blomquist, T. (2015) Co-creation as a strategy for program management, International Journal of


Nils O., Stein F., Jakobsen, E., and Jessen, S. (2010) In search of project substance: how do private investors evaluate

projects?, International Journal of Managing Projects in Business, 3.2, 257-274.

Nogeste, K. (2008) Dual cycle action research: a professional doctorate case study, International Journal of Managing

Projects in Business, 1, 4, 566-585.

Sanchez, H., Benoit, R., Bourgault, M., and Pellerin, R. (2009) Risk management applied to projects, programs, and

portfolios, International Journal of Managing Projects in Business, 2, 1, 14-35.

https://resources.workfront.com/project-management-blog/project-failure-10-famous-failures-and-5-ways-to-spot-them-before-they-happen?proxy=/blog/

https://resources.workfront.com/project-management-blog/project-failure-10-famous-failures-and-5-ways-to-spot-them-before-they-happen?proxy=/blog/




Sanchez, H., Robert, B., and Pellerin, R. (2008) A Project Portfolio Risk-Opportunity Identification Framework,

Project Management Journal, 39, 3, 97-109.

Sicotte, H., Drouin, N., and Delerue, H. (2012) Marketing and technology strategies for innovative performance,


Small, J. and Walker, D. (2011) Providing structural openness to connect with context, International Journal of


Teece, D., Pisano, G. and Shuen, A. (1997) Dynamic capabilities and strategic management, Strategic Management

Journal, 18, 7, 509-33.

Turner, N., Maylor, H., and Swart, J. (2013) Ambidexterity in managing business projects - an intellectual capital

perspective, International Journal of Managing Projects in Business, 6, 2, 379-389.

Unger, B., Kock, A., Gemünden, H., and Jonas, D. (2012) Enforcing strategic fit of project portfolios by project

termination: An empirical study on senior management involvement, International Journal of Project

Management, 30, 6 , 675.

Williams, T. and Samset, K. (2010) Issues in Front-End Decision Making on Projects, Project Management Journal,

41, 2 (Apr 2010), 38-49.

Identified but not yet Evaluated Relevant Articles by “Snowball” Consideration of Citations of Key Articles

Archibald, R. (2003) Managing high-technology programs and projects (3rd ed.). New York: John Wiley & Sons Inc.

Artto, K., Kujala, J., Dietrich, P. and Martinsuo, M. (2008) What is project strategy?, International Journal of Project

Management, 26, 1, 4-12.

Artto, K., Martinsuo, M., Gemünden, H. and Murtoaro, J. (2009) Foundations of program management: a bibliometric

view, International Journal of Project Management, 27, 1, 1-18.

Artto, K., Dietrich, P. and Nurminen, M. (2004) Strategy implementation by projects, in Slevin, D., Cleland, D. and

Pinto, J. (Eds), Innovations: Project Management Research 2004, Project Management Institute, Newtown

Square, PA.

Artto, K., Kijala, J., Dietrich, P. and Martinsuo, M. (2007) What is project strategy?, Paper presented at the EURAM

Conference, Paris, May.

Aubry, M., Hobbs, B. and Thuillier, D. (2007) A new framework for understanding organisational project management

through PMO, International Journal of Project Management, 25, 328-36.

Aubry, M., Sicotte, H., Drouin, N., Vidot-Delerue, H., and Besner, C. (2012) International Journal of Managing

Projects in Business, 5, 2, 180-194.

Barrett, S.(2004) Implementation studies: time for a revival? Personal reflections on 20 years of implementation

studies, Public Administration, 82, 2, 249-62.

Cicmil, S. (1997) Critical factors of effective project management, The TQM Magazine, 96, 390-396.

Cicmil, S. (1999) An insight into management of organizational change projects, Journal of Workplace Learning, 11,

1, 5-15.

Cicmil, S. (2000) Quality in project environments: A non-conventional agenda, International Journal of Quality &

Reliability Management, 17, 4/5, 554-570.

Grundy, T. (1998) Strategy implementation and project management, International Journal of Project Management,

16, 1, 43–50.

Kreiner, K. (1995) In search of relevance: project management in drifting environments, Scandinavian Journal of

Management, 11, 4, 335-346.

Kuruppuarachchi, P., Mandal, P., and Smith, R. (2002) IT project implementation strategies for effective changes: a

critical review, Logistics Information Management, 15, 2, 126-137.

McElroy, W. (1996) Implementing strategic change through projects, International Journal of Project Management,

14, 6, 325–329.

Morris, P. (2009) Implementing strategy through project management: The importance of managing the project front-

end. In T. Williams, K. Samset, and K. Sunnevåg (Eds.), Making essential choices with scant information

(pp. 39–67), Basingstoke, UK: Palgrave MacMillan.

Sicotte, H., Drouin, N., and Delerue, H. (2014/2015) Organisational project management as a function within the

organization, Project Management Journal, 45, 6 (Dec /Jan), 58.

Turner, J. and Müller, R. (2003) On the nature of the project as a temporary organization, International Journal of

Project Management, 21, 1, 1-8.

Turner, N., Maylor, H., and Swart, J. (2015) Ambidexterity in projects: An intellectual capital perspective,

International Journal of Project Management, 33, 1, 177.




van Buuren, A., Buijs, J. and Teisman, G. (2010) Program management and the creative art of coopetition: dealing

with potential tensions and synergies between spatial development projects, International Journal of Project

Management, 28, 7, 672-682.

Vereecke, A., Pandelaere, E., Deschoolmeester, D. and Stevens, M. (2003) A classification of development

programmes and its consequences for programme management, International Journal of Operations &

Production Management, 23, 10, 1279-1290.

Whittaker, B. (1999) What went wrong? Unsuccessful information technology projects, Information Management &

Computer Security, 7, 1, 23-29.

Winklhofer, H. (2002) Information systems project management during organizational change, Project Management

Journal, 14, 2, 33-39.

O Connor et al. Temporality in ISD: A systematic literature review


Seoul, South Korea, December 9th, 2017

55

Temporality in Information Systems Development (ISD) Research: A Systematic Literature Review

Mairead O Connor

Lero - The Irish Software Research Centre,

National University of Ireland, Galway

[email protected]

Kieran Conboy

Lero - The Irish Software Research Centre,

National University of Ireland, Galway

[email protected]

Denis Dennehy

Lero - The Irish Software Research Centre, National University of Ireland, Galway

[email protected]

ABSTRACT

While time is central to the way we work and live our lives, it is often viewed overly simply or overlooked completely.

Time is highly complex, polymorphous, socially constructed and context dependent. Time is also experienced

differently across cultures, sub-cultures, organisations, teams and individuals. Many researchers have attempted to

classify the complexities of time. However, there is no overarching framework which is commonly agreed upon. We

reviewed the temporality literature and particularly the existing frameworks which attempt to classify time. This

research-in-progress paper uses the well regarded Ancona et al., (2001) framework to classify time into three

categories: conceptions of time, mapping activities to time and actors relating to time. Guided by this framework, the

extant literature on information systems development (ISD) research was reviewed. Preliminary findings were found,

conclusions, limitations and future research is also considered.

Keywords

Time, temporality, information systems development, systematic literature review.

INTRODUCTION

No matter the topic, or the context, time is always a prominent, multifaceted and complex concept (Ancona, Okhuysen

& Perlow, 2001). Information systems development (ISD) is no exception. In fact, ISD usually takes place in a

relentlessly dynamic, complex and unpredictable environment (Abdel-Hamid & Madnick,1990; Benbya & McKelvey,

2006; Cockburn & Highsmith, 2001; Conboy, 2009). In such an environment, time becomes even more critically

important (Nanadhakumar, 2002).

Contemporary and emergent ISD literature is filled with temporal characteristics but neglect the complex and subtle

nature of time. Time as a construct is related to other constructs for example, in ISD literature pace (Vidgen & Wang,

2009), rhythm (Sarker & Sahay, 2004), velocity (Power & Conboy, 2015), speed (Conboy, 2009), just-in-time (Lee,

1999), on-time delivery (Sarkar, Munson, Sarker, & Chakraborty, 2009), completion rates (Yetton, Martin, Sharma,

& Johnston, 2000), lead time (Patnayakuni & Ruppel, 2006), time management (Nandhakumar, 2002), planning

(Shmueli Pliskin, & Fink, 2016), time pressure (Austin, 2001) rapid change (Ramesh, Cao, & Baskerville, 2010),

temporal dissonance (Conway & Limayem, 2011), and late deliveries (Austin, 2001) are all illustrations of temporal

terms in ISD literature.

Yet, those studying and experiencing ISD conceive time as clock time. This over reliance on clock time overshadows

ISD perspectives and theories (Nanadhakumar, 2002). As a result, traditional time management techniques are ill

prepared for ISD projects (Nanadhakumar, 2002). This is illustrated by frequent late deliveries of ISD projects with

continuous and problematic failure rates (Bartis & Mitev, 2008; Carlton, 2014; Pervan, 1998; Whittaker, 1999). In

contemporary and emergent ISD method literature, time has not been studied as comprehensively as it should. Yet,

time is the single differentiating factor between ISD methods to date (i.e, speed, sprints, daily stand ups, cycle time,

lead time, velocity).




56

Considering the importance of time in ISD and following numerous calls to research temporality within the context

of ISD teams and under dynamic conditions, it has not been explored explicitly or sufficiently in information systems

(IS) research (Lee & Liebenau 2000; Saunders & Kim 2007; Waller, Conte, Gibson, & Carpenter, 2001).

Building on the comprehensive temporality framework proposed by Ancona et al., (2001), the aim of this research is

to understand the various components of temporality within the context of ISD. For example, clock time is placed in

such importance in all ISD projects, but an important question to ask is whether clock time is the best way to

conceptualise time in ISD projects. Perhaps other categorises of time would improve ISD project success. This

research will examine the concept of temporality within ISD teams and produce a systematic literature review which

will give the reader an up-to-date analysis of temporality in ISD. This research contributes to research and practice by

identifying any gaps, misconceptions or general conceptual issues in the application of temporal concepts to ISD to

date.

This research-in-progress paper describes the research objective, background literature, concept of temporality,

research approach to examining time in ISD literature, and preliminary literature review findings.

RESEARCH OBJECTIVE

We aim to address the call from ISD researches which found: (i) time is understudied; (ii) time is dominated by clock

time and neglects all other conceptions of time; (iii) ISD is inherently characterised by time but studies which address

time explicitly is lacking.

A fundamental motivation for this research is: (i) frequent late deliveries of ISD projects with continuous and

problematic failure rates show little signs of improvement; (ii) traditional time management techniques are ill prepared

for ISD projects; (iii) those studying and experiencing ISD conceive time as clock time; (iv) clock time overshadows

ISD perspectives and theories; (v) time is the single differentiating factor between ISD methods to date (i.e, speed,

sprints, daily stand ups, cycle time, lead time, velocity). Yet, in contemporary and emergent ISD method literature,

time has not been studied as comprehensively (Ancona et al., 2001 framework) as it should; (vi) no literature review

of time in ISD research has previously been published. Thus, we aim to address if the complexity of time is studied in

ISD.

The objective of the review is to answer the following research questions:

RQ1 What has been reported about temporality in ISD in the existing literature?

RQ1.1 What component of temporality is being studied?

RQ2 How is temporality studied in ISD?

RQ2.1 What methodology is used to study temporality?

RQ3 How has temporality research contributed to ISD literature?

RQ 3.1 What was the contribution to temporality?

In addition to enhancing findings on the complexity of time within ISD, the review also aims to contribute to

conducting information systems systematic literature review methodology. A further contribution will be that of a

study which conducts a systematic literature review: (i) where the complexity and subtle nature of time is incorporated

into a search strategy; (ii) to find relevant papers; (iii) which are then systematically analysed based on a conceptual

framework.




57

BACKGROUND LITERATURE

Over the past twenty-five centuries, the complexities of time have been studied in many disciplines such as psychology

(Friedman, 1990), physics (Einstein, 1905; Hawking, 1993), and anthropology (Durkheim, 1915). There has been a

renewed interest in time and timing in organisational theory (Crossan, Cunha, Vera, & Cunha, 2005; Kamp, Lambrecht

Lund, & Søndergaard Hvid, 2011; Roe, 2008). This can be attributed to the emergence of global businesses and the

urgent nature of production demands (Orlikowski & Yates, 2004). In organisational studies, one of the first and most

famous studies to explicitly concentrate on time was by Taylor (1911). Taylor revolutionised the way in which

managers view time and much of his findings can still be seen across organisations today (Guerrier, 2016). However,

somewhat remarkably, very little research exists on time in an organisational setting over the years (Ancona et al.,

2001). Temporality studies should have been included in organisational theory; however, it has remained hidden for

decades (Sonnentag, 2012). However, in recent years, organisational researchers have begun acknowledging the

benefits of analysing organisations through a temporal lens (Ancona et al., 2001, Orlikowski & Yates, 2004;

Sonnentag, 2012).

Time underpins much of what we think about and do in IS. This is also reflected by the interest of time and IS in

organisational work (Saunders & Kim, 2007; Sarker & Sahay, 2004; Nandhukumar, 2002; Lee & Liebenau, 2000;

Lee, 1999). IS researchers regularly stress the time benefits of IS within the organisation. However, IS researchers are

slow to address this polymorphous, multi-dimensional, complex concept that is often masked subtlety and over-simply

in IS research (Saunders & Kim, 2007; Nandhakumar, 2002). As a result, research on time in IS is largely under-

explored (Lee & Liebenua, 2000) and there is a need for more research within the area (O’Riordan, Conboy & Acton,

2013; Saunders & Kim, 2007; Shen, Lyytinen & Yoo, 2014). The one-dimensional focus of clock time in IS research

means that temporal synonyms such as speed, pace, velocity, cost of delay, ignore the complexity around time which

permeate IS research. A multi-dimensional view of time would consider the perception of time and an actor’s

experience of time in IS teams (Shen et al., 2014). The need to produce temporality studies in IS which go beyond the

simple, one dimensional view of linear clock based time is ongoing (O Riordan et al., 2013).

ISD is a time pressure and highly complex environment where regular delays occur (Austin, 2001). There are frequent

innovative ISD methods introduced into the industry to solve delays. The rationale for this ever-emerging series of

ISD methods is time. For example, faster time to market. The timing and sequence of activities and not the actual

activities themselves have been to some degree, the differentiation between methods. It is not the activities but the

length of time and sequence of those activities that differentiate various methods such as waterfall, rapid development,

agile, lean, flow and continuous development from each other. For example, agile methods promote an ISD

environment where customer requirements can be changed more quickly than traditional methods (Dingsøyr &

Lindsjørn, 2013).

TEMPORALITY

Temporality refers to an individual’s experience of time (Caldas & Berterö 2012), which includes our relationship to

time (Heidegger, 1927), and how we react to time (Fraisse, 1963). There have been explicit attempts to add to

temporality theory within the past few decades (Ancona et al., 2001; Mosakowski & Earley, 2000; Orlikowski &

Yates, 2002; Standifer & Bluedorn, 2006). However, there is a lack of an overarching temporal framework. There are

several attempts to create an overarching theory on time, however no theory of time is universally accepted.

In organisational literature, several temporal frameworks have emerged over the last four decades, mostly within

organisational research (e.g., Bluedorn & Denhardt, 1988, Ancona et al., 2001, Mosakowski & Earley, 2000,

Orlikowski & Yates, 2002, Sonnentag, 2012). Scholars have used a range of temporal dimensions to describe

temporality in organisations. There are frameworks (Bluedorn & Denhardt, 1988; Ancona et al., 2001) which consider

the full extent of time and all its complexity. These studies not only consider all temporal dimensions but also

categorise them into an applicable structure. The Bluedorn & Denhardt (1988)) framework classifies time into three

categories; social time, mathematical time, and economic time. Ancona et al., (2001) classifies time into three

interrelated categories; conceptions of time, socially constructed time, and actors relating to time. However, a concept

analysis reveals that there are inconsistencies with the temporality literature that exists. There are inconsistent

definitions and use of temporal terms in these frameworks.




58

There are studies which examined temporal dimensions within a problem. These temporal dimensions vary. Schriber

& Gutek (1987) examined temporality within organisational culture and found thirteen main temporal dimensions;

time boundaries between work and non-work, sequencing of tasks, punctuality, allocation, awareness, synchronization

and coordination, variety versus routine, intra-organizational time boundaries, future orientation, schedules and

deadlines, work pace, autonomy of time use, and quality versus speed. Lee & Liebenau (2000) identified six temporal

dimensions that can be used to evaluate the temporal effects of IS: duration, sequence, temporal location, deadline,

cycle and rhythm. Zerubavel (1981) examined temporality in organisations and found four temporal dimensions:

sequential structure, duration, temporal location and rate of recurrence. Ancona et al., (2001), Schriber & Gutek

(1987), Lee & Liebenau (2000), and Zerubavel (1981) all examined temporality within an organisational context.

Schriber & Gutek (1987), Lee & Liebenau (2000), and Zerubavel (1981) contributed to temporal dimensions.

However, Ancona et al., (2001) framework is unique as it provides a holistic classification of temporal dimensions.

Classification of time

This study uses the Ancona et al., (2001) framework (Table 1) to firstly classify time and secondly to understand what

ISD literature on time exists to date. Ancona et al., (2001) reviewed the literature surrounding temporality within the

areas of organisational theory, sociology, social psychology, and anthropology and developed a framework to classify

time. The framework has three categories called conceptions of time, mapping activities to time and actors relating to

time (Ancona et al., 2001). The framework was chosen because it is a well-regarded classification of time (Shen et

al., 2014). Shen et al., (2001) also chose it because it “synthesizes a large swath of temporal concepts across diverse

areas of temporal study and provides a common organising framework for these temporal constructs and variables”.

It is also an easily applied structure that can be used as a lens to examine teams (Shen et al., 2014, p3). Thus, it is

suited to this research on ISD.

Category Subcategory Sample Variables

Conceptions of time Types of time Linear time, uniform time, cyclical

time, subjective time, event time

Socially constructed time Work organization (nine-to-five

workdays, work time and family

time), celebrations (Passover and/or

Easter), time as a renewing cycle,

time as linear continuity

Mapping activities to time Single activity mapping (a) Scheduling, rate of completion,

duration

Repeated activity mapping (aa) Cycle, rhythm, frequency, interval

Single activity transformation

mapping (aa')

Life cycles, midpoint transitions,

jolts, interrupts, deadline behavior

Multiple activity mapping (ab) Relocation of activities, allocation of

time, ordering, synchronization

Comparison and meshing of activity

maps (ab) versus (aa)

Entrainment, patterning, temporal

symmetry

Actors relating to time Temporal perception Experience of time, time passing,

time dragging, experience of

duration, experience of novelty

Temporal personality Temporal orientation, temporal style

Table 1. Classification of Categories and Subcategories, with Sample Variables (Ancona et al., 2001)




59

Conception of Time

The framework identifies three categories; conceptions of time, mapping activities to time and actors relating to time.

Each classification of time is now discussed in turn. A conception of time can be created by an individual. For example,

an employee in an organisation can conceptualise their own view of time (Medlin & Saren, 2012). There are different

types of time such as linear time, uniform time and cyclical time. However, the most popular and widely cited types

of time are clock time and event time (Mosakowski & Earley, 2000). Each society will conceptualise time differently.

For example, some may use clock-based time whereas others may use event-based time (Mosakowski & Earley, 2000).

Clock time versus event time can be associated with the Newton (1871) Vs Einstein (1945) debate. Newton perceived

time as absolute and Einstein perceived time as relative. Still, individuals can experience multiple types of time at

once (Ancona et al., 2001). Time is also revealed as a socially constructed phenomenon (Ancona et al., 2001; Saunders

et al., 2004). Even within these groups, time can be used in a way which is appropriate to the sub group (Ancona et

al., 2001). This means there can be different dimensions of time within a society (Saunders et al., 2004).

Mapping activities to Time

The main aim of mapping activities to time is to get a valid analysis of what happens over time during an activity

(Roe, 2008). This category explains that events and activities can be mapped to time. Mapping activities to time

explains when an activity will begin, how long it may take and any fluctuations or patterns over the interval (Ancona

et al., 2001). Single activity mapping maps a single activity to a time continuum (Ancona et al., 2001). Single activity

mapping entails the examination of a single event which is not usually repeated once the activity has taken place.

Repeated activity mapping has been researched far less than single activity mapping. Repeated activity mapping is

where an activity is repeated on multiple occasions and is mapped to time. Single activity transformation mapping

occurs when, during an activity, the old activity transforms into the new activity, changing the form of the activity

(Ancona et al., 2001). The single activity transformation mapping is catered for one single event. In multiple activity

mapping, activities are examined in relation to each other. The primary concern for multiple activity mapping is

allocating the correct amount of time towards the multiple activities (Ancona et al., 2001). Comparing multiple activity

mapping is used to understand the differences and similarities in temporal characteristics. Not all activities have the

same temporal characteristics.

Actors relating to time

Actors relating to time explain the actors which are involved in the previous two categories. Temporal perception

variables are used to reveal how actors perceive and act with regard to the continuum of time. The actors may refer to

the individual, team or the organisation (Ancona et al., 2001). The perception of time is different among the different

cultures around the world (Mosakowski & Earley, 2000). Individuals also have their own temporal personality (e.g.,

when an individual schedules his/her tasks). They will follow their own temporal personality while doing so (Avnet

& Sellier, 2011). Although our perception of time is influenced by our culture, it is also formed by our own individual

temporal personality. A temporal personality is unique to the distinctive individual and the way in which an individual

understands and experiences time will be exposed through their actions (Ancona et al., 2001).

RESEARCH METHOD

General temporality and time classification frameworks were examined. Having chosen the Ancona et al., (2001)

framework because of its broad application and easily applied structure, a number of pilot tests were carried out. We

used a systematic literature review approach and a brief analysis of temporal research in ISD was of a primary concern.

From that, some opening early stage preliminary findings were exposed.

In conducting our literature review, we chose an efficient scientific method; a systematic literature review. A

systematic literature review is a “means of identifying, evaluating and interpreting all available research relevant to a

particular research question, or topic area, or phenomenon of interest” (Kitchenham, 2004:1). This type of review

offers a high quality (Dyba & Dingsøyr, 2008), transparent and replicable review (Leidner & Kayworth, 2006). This

method offers the capability of summarising a large quantity of research publications (Fink, 2005), for studies which

aim to address a clearly formulated question (Petticrew & Roberts, 2006). Therefore, a systematic literature review

was chosen rather than a narrative literature review for four reasons: (1) our study aimed to answer a specific research

question; (2) our area of study will generate a large amount of literature; (3) our intention was to systematically extract




60

relevant temporal references from the publications in a transparent form; (4) the rigour and replicability it offers which

leads to an unbiased scientific paper.

Systematic literature reviews originated in health science (Fink, 2005) and have been applied in many diverse domains

including supply chain management (Gimenez & Tachizawa, 2012), nursing (Brady Germain & Cummings, 2010),

organisational management (Crossan & Apaydin, 2010), marketing (Antunes & Moreira, 2011) and air transport

(Ginieis et al., 2012). Within information systems, systematic literature reviews have been published within the top

journals (Grahlmann, Helms, Hilhorst, Brinkkemper, and Van Amerongen, 2012; Lavranos, Kostagiolas, Korfiatis, &

Papadatos, 2015). However, not to a large extent. Two reasons for this neglect has been that IS researchers are unaware

of the need for a rigorous and systematic literature review (Levy & Ellis, 2006) and many are unsure about the

methodology involved in conducting a systematic literature (Okoli & Schabram, 2010).

Systematic literature review guides have also been developed in a variety of different domains such as social science

(Petticrew & Roberts, 2006), software engineering (Kitchenham & Charters, 2007) and IS (Leidner & Kayworth,

2006; Levy & Ellis, 2006; Okoli & Schabram, 2010; Webster & Watson). IS research methods are different from

health sciences methods and require a specific systematic literature review guide (Okoli & Schabram, 2010). Within

IS, bespoke systematic literature reviews were developed in response to the shortage of appropriate guides which suit

the multidiscipline domain of IS. The domain is made up of social science, business, and computing science disciplines

(Okoli & Schabram, 2010).

We followed the systematic literature review approach based on work by Kitchenham & Charters (2007), Levy &

Ellis (2006), Okoli & Schabram (2010) and Webster & Watson (2002). The foundation of our guide was taken from

an IS guideline developed by Okoli & Schabram (2010). However, we drew from similar work by Kitchenham &

Charters (2007), Levy & Ellis (2006) and Webster & Watson (2002) to strengthen our scientific review.

Webster & Watson (2002) was one of the first attempts to create a systematic literature review guide within the IS

domain. This work has contributed to further systematic literature review guide within IS such as Levy & Ellis (2006)

and Okoli & Schabram (2010). However, it lacks the depth Levy & Ellis (2006) and Okoli & Schabram (2010) can

offer. Webster & Watson (2002) lacks rigour and explanation in which the novice researcher needs. Hence, Levy &

Ellis (2006) and Okoli & Schabram (2010) were chosen to add strength and further thorough guidelines to the

systematic literature review process.

Levy & Ellis (2006) developed a set of guidelines for IS doctoral researchers, early stage researchers and IS researchers

who have difficulties completing a successful literature review. Levy & Ellis (2006) took some features from Webster

& Watson (2002) such as the backward and forward search feature. However, it offers a more in-depth guide tailored

for the needs of the IS doctoral researchers.

Okoli & Schabram (2010) developed a bespoke methodological approach for IS researchers which offers a guideline

created from contributions within software engineering (Kitchenham & Charter, 2007), social sciences (Petticrew and

Roberts,2006), health sciences (Fink, 2005), management and organization science (Rousseau et al., 2008) IS (Levy

& Ellis, 2006; Webster & Watson,2002). This is an exhaustive guideline as it is adapted best practices from several

other domains. It offers a balanced approach of both qualitative and quantitative methods. This differs to Levy & Ellis

(2006) which is primarily qualitative based. This guide has more depth than Levy & Ellis (2006) and focuses on

guidelines for areas that previous methodologies have neglected.

Kitchenham (2004) developed a lengthy and thorough procedure for performing literature reviews. These guidelines

were progressed by Kitchenham & Charters (2007). Although Kitchenham & Charters (2007) is an extensive and

exhaustive guide, it was created for the software engineering domain. However, software engineering overlaps with

the IS domain and due to the guides large application within other fields such as business process management (Maita

et al., 2005), marketing (McHugh & Domgan, 2010), and nursing (Beraldi & Abades, 2014), it has been chosen for

the unique exhaustive contribution it can offer. One of its unique contribution is the protocol feature, in which we

implemented for this paper.

We followed an eight-step guideline which is required for completion of a systematic literature review. Although any

of these steps can be followed by researchers who complete a narrative literature review, following all steps are

essential to conduct a scientifically rigorous systematic literature review (Okoli & Schabram, 2010). This guide is




61

based on (Okoli & Schabram, 2010) but draws from similar best practices from three other systematic literature review

guides; Kitchenham & Charters (2007), Levy & Ellis (2006) and Webster & Watson (2002).

A keyword strategy (Table 2) was developed based on the temporal terms used in several temporality frameworks

(Ancona et al., 2001; Bluedorn & Allen, 1988; Kavanagh & Araujo, 1995; Lee &Liebenua, 2000; Mosakowki &

Early, 2000; Sonnentag, 2012). They keyword strategy was applied to Association for Information Systems (AIS)

senior scholars’ basket of IS journals and top two IS conferences (Table 3). The largest, most extensive and

information systems-specific databases were chosen (Table 4). The research questions (Table 5) were used to develop

the inclusion (Table 6) and exclusion (Table 7) strategy. The data extraction (Table 8) and quality assessment (Table

9) was used to develop preliminary findings.

Keyword strategy

TOPIC: (( system* OR software* )) AND TOPIC: (( method* OR design* OR develop* OR practice* OR project*

OR agile* OR scrum* OR "extreme programming" OR xp OR feature* OR crystal* OR lean* OR flow* OR team*

OR technique* OR approach* )) AND TOPIC: ((tim* OR temporal* OR *cycl* OR schedul* OR rate* OR duration*

OR rhythm* OR frequen* OR interval* OR jolt* OR interrupt* OR deadline* OR *sync* OR order* OR pattern*

OR entrain* OR novel* OR "relocation of activities" OR "mid-point* transition*" OR "midpoint* transition*" OR

clock* OR calendar* OR speed* OR slow* OR *prior* OR routine* OR fast* OR year* OR event* OR day* OR

plan* OR monochronic* OR polychronic* OR pace* OR lag* OR urgen* OR sequen*)) Table 2. Keyword Strategy

Conference/Journal Acronym

European Journal of Information Systems EJIS

Information Systems Journal ISJ

Information Systems Research ISR

Journal of the Association of Information Systems JAIS

Journal of Information Technology JIT

Journal of Management Information Systems JMIS

Journal of Strategic Information Systems JSIS

Management Information Systems Quarterly MISQ

International Conference on Information Systems ICIS

European Conference on Information Systems ECIS Table 3. Association for Information Systems (AIS) Senior Scholars’ Basket of IS Journals and Top Two IS Conferences

No. Database

(1) Association for Information Systems

(2) Scopus

(3) Web of Science Table 4. Literature Databases

ID Research Question Aim

RQ1 What has been reported about temporality in ISD

in the existing literature?

To provide a comprehensive review of time in ISD

literature

RQ1.1 What component of temporality is being studied? To establish what components of time are being

studied within ISD literature

RQ2 How is temporality studied in ISD? To identify how research on time in ISD is carried

out

RQ2.1 What methodology is used to study temporality? To establish what methodology is used in carrying

out research on time in ISD literature

RQ3 How has temporality research contributed to ISD

literature?

To identify the contribution temporality has made to

ISD literature

RQ 3.1 What was the contribution to temporality? To categorise the contribution of temporality in ISD

literature Table 5. Research Questions




62

No. Inclusion strategy

(1) Each study should relate to one or more of our research questions

(2) Each study should fall into the top eight IS journals and the top two IS conferences

(3) Each study should focus on temporality in ISD

(4) Each study should be empirical, theoretical, conceptual, literature review or

experimental

(5) Each study should be published between 2000 and 2016

(6) If the study has been published in more than one journal or conference, the most

recent version of the study is included Table 6. Inclusion Strategy

No. Exclusion strategy

(1) Duplicate articles will be excluded

(2) Papers not written in English will be excluded

(3) Lesson learned, research in progress, editor’s reports and

experience reports will be excluded

(4) Papers which use students as the sample study will be

excluded Table 7. Exclusion Strategy

Table 8. Data Extraction

ID Quality Question

Q1 Is this a research paper?

Q2 Is there are a clear statement of the aims of the research?

Q3 Is there an adequate description of the context in which the research was

carried out?

Q4 Was the research design appropriate to address the aims of the research?

Q5 Was the recruitment strategy appropriate to the aims of the research?

Q6 Was there a control group with which to compare treatments?

Q7 Was the data collected in a way that addressed the research issue?

Q8 Was the data analysis sufficiently rigorous?

Q9 Has the relationship between researcher and participants been considered

to an adequate degree? Table 9. Quality Assessment questions (source: Dybå and Dingsøyr, 2008)

No. Data extraction Related RQ

(1) What component of temporality is being studied? RQ1

(2) What methodology was used to study temporality? RQ2

(3) What was the contribution to temporality? RQ3

(4) Research setting Overview

(5) Article title Overview

(6) Author Overview

(7) Year Overview

(8) What ISD methodology does this cover? Overview

(9) Classification of study type Overview

(10) Source Overview




63

PRELIMINARY FINDINGS

While the systematic literature review has not been fully conducted to date, some notable findings have emerged. Each

finding is now discussed in turn. Firstly, preliminary findings associated with general temporality are summarised.

Then, preliminary findings associated with each category of time is discussed in Table 10.

Preliminary Findings Associated with General Temporality

Time in ISD

is studied

implicitly

rather than

explicitly

ISD literature ignores the depth and complexity of time, as depicted by Ancona et al., (2001).

Considering ISD methods such as agile and flow are time focused, there is a lack of research which

explicitly focuses on time in ISD. Analysis of the literature revealed that time is implicitly referenced

using temporal variables. Temporal variables can be found in the majority of ISD literature. For

example, pace (Vidgen & Wang, 2009), rhythm (Sarker & Sahay, 2004), velocity (Power & Conboy,

2015), speed (Conboy, 2009), just-in-time (Lee, 1999), on-time delivery (Sarker et al., 2009),

completion rates (Yetton et al., 2000), lead time (Patnayakuni & Ruppel, 2006), time management

(Nandhakumar, 2002), planning (Shmueli et al., 2016), time pressure (Austin, 2001), rapid change

(Ramesh et al., 2010), temporal dissonance (Conway & Limayem, 2011), and late deliveries (Austin,

2001). Collectively, these temporal variables are researched in some form, in every ISD method. They

are used in the research when describing the enabling of speed or used as a measurement. The issue

is that despite their importance in ISD, they are never studied in their own right but rather as a variable

or indirect measurement of some broader non-temporal study.

Preliminary Findings Associated with Conceptions of Time

One

dimensional

view of the

concept of

time

Ancona et al., (2001) uses over thirty-five sample variables of time. Of these, a linear objective form

of time is only used once. The analysis of the ISD literature revealed that very little research has been

focused on the other complex temporal variables of the framework. However, while there are some

references towards the other temporal variables e.g., rhythm (Sarker & Sahay, 2004) and interruptions

(Xia & Lee, 2005), most are measured quantifiably in hours and days. This means that the vast

majority of literature focuses on clock time. A Nandhakumar (2002) study similarly revealed that IS

research largely ignores time and within ISD projects, time is perceived as clock time. Furthermore,

the Nandhakumar (2002) study revealed that ISD perspectives and theories are also mainly

considered to be clock-based time. Thus, ISD research has failed to consider time as a complex

phenomenon.

Preliminary Findings Associated with Mapping Activities to Time

Lack of

research

involving

mapping

activities to

time

There is a rich body of knowledge around mapping activities to time. The literature review revealed

that ISD studies have mapped activities to time e.g., pace (Vidgen & Wang, 2009), rhythm (Sarker

& Sahay, 2004), and velocity (Power & Conboy, 2015). However, the literature reveals many gaps.

Of the ISD literature which maps activities to time, they are studied implicitly or are a variable within

a broader study. The literature also revealed that there is a focus towards a single activity mapping to

time. Studies are conducted around one task or one deadline. However, in reality, most teams are

involved in a portfolio of projects at once. One reason for this lack of research in mapping activities

to time is that researchers may not have access to organisations over a long period of time. This makes

it difficult for researchers who want to apply a temporal lens over the long term in order to include

temporal variables such as pacing styles, duration and sequencing (Ancona et al., 2001).

Preliminary Findings Associated with Actors Relating to Time

Lack of

research

involving

actors

relating to

time

The literature review revealed that ISD literature has examined ISD methods but also how these

methods of practice have been adapted (Fitzgerald, Harnett, & Conboy, 2006; Wang et al., 2012).

However, the literature rarely looks at how these methods of practice study actors relating to time.

Temporal individual differences are constantly overlooked. The actors experience and relationship to

time is also under-explored in ISD. For example, there is a lack of ISD studies which address

experience of time, the passage and flow of time, time pressure, temporal personality and temporal

orientation. As with the other classifications of time, time is studied implicitly and usually part of a

study which focuses on an alternative focus.

Table 10. Preliminary Findings




64

CONCLUSION AND FUTURE RESEARCH

The literature review to date shows that ISD research: (i) lacks explicit studies on time; (ii) adopts an overly simplistic

and one-dimensional view of time; (iii) only focuses on single activities e.g., a deadline and neglects the fact that

teams will be involved in multiple tasks and projects at once; and (iv) lacked studies which considered the actors

relating to time in ISD. The next research phase will include a more in-depth literature review on time in ISD. This

upcoming literature review will expose a fuller, truer and deeper analysis of ISD studies on time. The review will

firstly include an analysis of explicit studies on ISD time where temporal constructs are present and are the focus of

study. Secondly, the review will assess ISD research where time is implicit and subtly referenced. Findings will be

expanded and classified into each temporal category and within each subcategory. A limitation of the study is that our

systematic literature review does not include journal and conference papers which were outside of our sampling

criteria. The full systematic literature review aims to: (i) identify any misconceptions or general conceptual issues in

the application of temporal concepts to ISD to date.

ACKNOWLEDGMENTS

This work was supported with the financial support of the Science Foundation Ireland grant 13/RC/2094 and co-

funded under the European Regional Development Fund through the Southern & Eastern Regional Operational

Programme to Lero - the Irish Software Research Centre (www.lero.ie).

REFERENCES

Ancona, D. G., Okhuysen, G. A., and Perlow, L. A. 2001. "Taking Time to Integrate Temporal Research," Academy

of Management Review (26:4), pp. 512-529.

Antunes, V. and Moreira, J.P., 2011. Approaches to developing integrated care in Europe: a systematic literature

review. Journal of Management & Marketing in Healthcare, 4(2), pp.129-135.

Austin, R. D. 2001. "The Effects of Time Pressure on Quality in Software Development: An Agency Model,"

Information systems research (12:2), pp. 195-207.

Avnet, T. and Sellier, A.L. 2011. “Clock Time Vs. Event Time: Temporal Culture Or Self-Regulation?,” Journal of

Experimental Social Psychology, (47:3), pp.665-667.

Bartis, E., and Mitev, N. 2008. "A Multiple Narrative Approach to Information Systems Failure: A Successful System

That Failed," European Journal of Information Systems (17:2), pp. 112-124.

Baxter, P. and Jack, S., 2008. Qualitative case study methodology: Study design and implementation for novice

researchers. The qualitative report, 13(4), pp.544-559.

Beraldi, S.D. and Abades, P.M., 2014. Bibliographic study of bonding: caring for the mother-child attachment. Revista

de enfermeria (Barcelona, Spain), 37(1), pp.18-25.

Bluedorn, A. C., and Denhardt, R. B. 1988. "Time and Organizations," Journal of management (14:2), pp. 299-320.

Brady Germain, P., and Cummings, G.G., 2010. The influence of nursing leadership on nurse performance: a

systematic literature review. Journal of Nursing Management, 18(4), pp.425-439.

Caldas, C. P., and Berterö, C. 2012. "A Concept Analysis About Temporality and Its Applicability in Nursing Care,"

Nursing forum: Wiley Online Library, pp. 245-252.

Carlton, D. 2014. "Aaa-Rated Project Failures–Abdication, Avoidance and Apathy," Gartner Research document G

(262544).

Conboy, K. 2009. “Agility from First Principles: Reconstructing The Concept of Agility in Information Systems

Development,” Information Systems Research, 20(3), pp.329-354.

Conway, C. and Limayem, M., 2011. " You Want It When?" How Temporal Dissonance in IT Workers Contributes

to Project Failures.

Crossan, M.M. and Apaydin, M., 2010. A multi‐dimensional framework of organizational innovation: A systematic

review of the literature. Journal of management studies, 47(6), pp.1154-1191.

Crossan, M., Cunha, M.P.E., Vera, D., and Cunha, J. 2005. "Time and Organizational Improvisation," The Academy

of Management Review), pp. 129-145.

Dingsøyr, T. and Lindsjørn, Y., 2013, June. Team performance in agile development teams: Findings from 18 focus

groups. In International Conference on Agile Software Development (pp. 46-60). Springer, Berlin,

Heidelberg.

Durkheim, E. 1915. The Elementary Forms of the Religious Life. London: Allen & Unwin.

Dybå, T. and Dingsøyr, T. 2008. “Empirical Studies of Agile Software Development: A Systematic Review,”

Information and software technology, (50:9), pp.833-859.




65

Einstein, A. 1945. “A Generalization of the Relativistic Theory of Gravitation,” Annals of Mathematics) pp.578-584.

Einstein, A., 1905. On the special theory of relativity. Ann Phys, 17, pp.891-921.

Fink, A., 2005. Conducting research literature reviews: From the internet to paper. Sage.

Fitzgerald, B., Hartnett, G. and Conboy, K., 2006. Customising agile methods to software practices at Intel

Shannon. European Journal of Information Systems, 15(2), pp.200-213.

Fraisse, P. (1963). The psychology of time. New York: Harper.

Friedman, W. J. 1990. About Time: Inventing the Fourth Dimension. Cambridge, Mass.: MIT Press.

Garcia-Crespo, A., Colomo-Palacios, R., Soto-Acosta, P. and Ruano-Mayoral, M., 2010. A qualitative study of hard

decision making in managing global software development teams. Information Systems Management, 27(3),

pp.247-252.

George, J. M., and Jones, G. R. 2000. "The Role of Time in Theory and Theory Building," Journal of management

(26:4), pp. 657-684.

Gimenez, C and Tachizawa, M. (2012),"Extending sustainability to suppliers: a systematic literature review", Supply

Chain Management: An International Journal, Vol. 17 Iss 5 pp. 531 – 543

Ginieis, M., Sánchez-Rebull, M.V. and Campa-Planas, F., 2012. The academic journal literature on air transport:

Analysis using systematic literature review methodology. Journal of Air Transport Management, 19, pp.31-

35.

Grahlmann, K.R., Helms, R.W., Hilhorst, C., Brinkkemper, S. and Van Amerongen, S., 2012. Reviewing enterprise

content management: A functional framework. European Journal of Information Systems, 21(3), pp.268-286.

Guerrier, Y., 2016. 9 ModernDay ‘Schmidts’: The Legacy of Taylorism in Elite ‘Professional’Roles. Re-Tayloring

Management: Scientific Management a Century On, p.155.

Hawking, S, W. 1993. A Brief History of Time: From the Big Bang to Black Holes. New York: Bantam.

He, J., Butler, B.S. and King, W.R., 2007. Team cognition: Development and evolution in software project teams.

Journal of Management Information Systems, 24(2), pp.261-292.

Heidegger, M. 1927. "Being and Time," Oxford: Blackwell Publishing).

Kamp, A., Lambrecht Lund, H. and Søndergaard Hvid, H. 2011. “Negotiating Time, Meaning and Identity in

Boundaryless Work,” Journal of Workplace Learning, (23:4), pp.229-242.

Kavanagh, D., and Araujo, L. 1995. "Chronigami: Folding and Unfolding Time," Accounting, Management and

Information Technologies (5:2), pp. 103-121.

Keil, M., Mann, J., and Rai, A. 2000. "Why Software Projects Escalate: An Empirical Analysis and Test of Four

Theoretical Models," Mis Quarterly), pp. 631-664.

Kitchenham, B., 2004. Procedures for performing systematic reviews. Keele, UK, Keele University, 33(2004), pp.1-

26.

Kitchenham, B., Charters, S.M., 2007 Guidelines for performing systematic literature reviews in software engineering.

In Technical report, Ver. 2.3 EBSE Technical Report. EBSE. sn.

Lavranos, C., Kostagiolas, P., Korfiatis, N. and Papadatos, J., 2015. Information seeking for musical creativity: A

systematic literature review. Journal of the Association for Information Science and Technology.

Lee, H., 1999. Time and information technology: monochronicity, polychronicity and temporal symmetry. European

Journal of Information Systems, 8(1), pp.16-26.

Lee, H., and Liebenau, J. 2000. "Temporal Effects of Information Systems on Business Processes: Focusing on the

Dimensions of Temporality," Accounting, Management and Information Technologies (10:3), pp. 157-185.

Leidner, D.E. and Kayworth, T., 2006. A review of culture in information systems research: Toward a theory of

information technology culture conflict. MIS quarterly, 30(2), pp.357-399.

Levy, Y. and Ellis, T.J., 2006. A systems approach to conduct an effective literature review in support of information

systems research. Informing Science, 9.

Maglyas, A., Nikula, U. and Smolander, K., 2011, August. What do we know about software product management?-

a systematic mapping study. In Software Product Management (IWSPM), 2011 Fifth International Workshop

on (pp. 26-35). IEEE.

Maita, A.R.C., Martins, L.C., López Paz, C.R., Peres, S.M. and Fantinato, M., 2015. Process mining through artificial

neural networks and support vector machines: A systematic literature review. Business Process Management

Journal, 21(6), pp.1391-1415.

Mainela, T., Puhakka, V. and Servais, P., 2014. The concept of international opportunity in international

entrepreneurship: a review and a research agenda. International Journal of Management Reviews, 16(1),

pp.105-129.

McHugh, P. and Domegan, C., 2010. Systematic Reviews: Their Emerging Role in the Co-Creation of Social

Marketing Value. Regulation and Best Practices in Public and Nonprofit Marketing, 59.




66

Medlin, C. J., & Saren, M. 2012 “Interaction: Coherence to a Future”, in M. S. Glynn, A. G. Woodside (Eds.),

Business-to-Business Marketing Management, Strategies, Cases and Solutions, Vol. 18., Bingley UK:

Emerald, pp. 173–188.

Michon, J. A. and Jackson, J. L. 1985. Time, mind, and behavior. Berlin: Springer-Verlag.

Mitchell, T. R., and James, L. R. 2001. "Building Better Theory: Time and the Specification of When Things Happen,"

Academy of Management Review (26:4), pp. 530-547.

Mosakowski, E. and Earley, P.C. 2000. “A Selective Review of Time Assumptions in Strategy Research,” Academy

of Management Review, (25:4), pp.796-812.

Nandhakumar, J. 2002. "Managing Time in a Software Factory: Temporal and Spatial Organization of Is Development

Activities," The Information Society (18:4), pp. 251-262.

Newton, S.I. 1871. Philosophiae Naturalis Principia Mathematica: Principia. Maclehose.

Norton, J.D. 2005. “A Conjecture On Einstein, The Independent Reality of Spacetime Coordinate Systems and The

Disaster of 1913,” The Universe of General Relativity), pp. 67-102. Birkhäuser Boston.

O Riordan, N., Conboy, K. and Acton, T. 2013. How soon is now? Theorising temporality in Information Systems

research. In International Conference on Information Systems (ICIS) 2013: Reshaping Society Through

Information Systems Design, Milan, Italy, 15-18 December 2013.

Okoli, C. and Schabram, K., 2010. A guide to conducting a systematic literature review of information systems

research.

Orlikowski, W. J., and Yates, J. 2002. "It's About Time: Temporal Structuring in Organizations," Organization science

(13:6), pp. 684-700.

Patnayakuni, R. and Ruppel, C.P., 2006. Managing the complementarity of knowledge integration and process

formalization for systems development performance. Journal of the association for information systems, 7(8),

p.21.

Pervan, G. 1998. "How Chief Executive Officers in Large Organizations View the Management of Their Information

Systems," Journal of Information technology (13:2), pp. 95-109.

Petticrew, M. and Roberts, H., 2006. How to appraise the studies: an introduction to assessing study

quality. Systematic reviews in the social sciences: A practical guide, pp.125-163.

Polites, G.L., Roberts, N. and Thatcher, J., 2012. Conceptualizing models using multidimensional constructs: a review

and guidelines for their use. European Journal of Information Systems, 21(1), pp.22-48.

Power, K. and Conboy, K. 2015. A metric-based approach to managing architecture-related impediments in product

development flow: an industry case study from Cisco. In Proceedings of the Second International Workshop

on Software Architecture and Metrics (pp. 15-21). IEEE Press.

Ramesh, B., Cao, L. and Baskerville, R., 2010. Agile requirements engineering practices and challenges: an empirical

study. Information Systems Journal, 20(5), pp.449-480.

Roe, R. A. 2008. "16 Perspectives on Time and the Chronometric Study of What Happens in Organizations," Time in

organizational research (3), p. 291.

Sarker, S. and Sahay, S., 2004. Implications of space and time for distributed work: an interpretive study of US–

Norwegian systems development teams. European Journal of Information Systems, 13(1), pp.3-20.

Sarker, S., Munson, C.L., Sarker, S. and Chakraborty, S., 2009. Assessing the relative contribution of the facets of

agility to distributed systems development success: an Analytic Hierarchy Process approach. European

Journal of Information Systems, 18(4), pp.285-299.

Saunders, C., and Kim, J. 2007. "Perspectives on Time," Management Information Systems Quarterly (31:4), p. 1.

Saunders, C., Slyke, C.V., and Vogel, D.R. 2004. "My Time or Yours? Managing Time Visions in Global Virtual

Teams," The Academy of Management Executive (1993-2005) (18:1), pp. 19-31.

Shen, Z., Lyytinen, K., and Yoo, Y. 2014. "Time and Information Technology in Teams: A Review of Empirical

Research and Future Research Directions," European Journal of Information Systems (24:5), pp. 492-518.

Singh, R., Keil, M., and Kasi, V. 2009. "Identifying and Overcoming the Challenges of Implementing a Project

Management Office," European journal of information systems (18:5), pp. 409-427.

Sonnentag, S., 2012. “Time in Organizational Research: Catching Up On a Long Neglected Topic in Order to Improve

Theory,” Organizational Psychology Review, (2:4), pp.361-368.

Standifer, R. and Bluedorn, A., 2006. “Alliance Management Teams and Entrainment: Sharing Temporal Mental

Models,” Human Relations, (59:7), pp.903-927.

Stewart, K.J. and Gosain, S., 2006. The impact of ideology on effectiveness in open source software development

teams. Mis Quarterly, pp.291-314.

Taylor, F.W. 1911. The Principles of Scientific Management. New York and London: Harper & Brothers.




67

Vidgen, R. and Wang, X., 2009. Coevolving systems and the organization of agile software development. Information

Systems Research, 20(3), pp.355-376.

Waller, M. J., Conte, J. M., Gibson, C. B., and Carpenter, M. A. 2001. "The Effect of Individual Perceptions of

Deadlines on Team Performance," Academy of Management Review (26:4), pp. 586-600.

Wang, X., Conboy, K. and Cawley, O. 2012. ““Leagile” Software Development: An Experience Report Analysis of

the Application of Lean Approaches in Agile Software Development,” Journal of Systems and Software,

(85:6), pp.1287-1299.

Webster, J. and Watson, R.T., 2002. Analyzing the past to prepare for the future: Writing a literature review. MIS

quarterly, pp.xiii-xxiii.

Whittaker, B. 1999. "What Went Wrong? Unsuccessful Information Technology Projects," Information Management

& Computer Security (7:1), pp. 23-30.

Xia, W. and Lee, G., 2005. Complexity of information systems development projects: conceptualization and

measurement development. Journal of management information systems, 22(1), pp.45-83.

Yang, H.D., Kang, H.R. and Mason, R.M., 2008. An exploratory study on meta skills in software development teams:

Antecedent cooperation skills and personality for shared mental models. European Journal of Information

Systems, 17(1), pp.47-61.

Yetton, P., Martin, A., Sharma, R. and Johnston, K., 2000. A model of information systems development project

performance. Information Systems Journal, 10(4), pp.263-289.

Yin, R. K. 2009. "Case Study Research: Design and Methods. 4. Udgave." Sage Publications.

Zaheer, S., Albert, S., and Zaheer, A. 1999. "Time Scales and Organizational Theory," Academy of Management

Review (24:4), pp. 725-741.