Full citation: McLeod, L., MacDonell, S.G., & Doolin, B.

(2011) Qualitative research on software

development: a longitudinal case study methodology, Empirical Software Engineering 16(4),
pp.430-459. doi: 10.1007/s10664-010-9153-5

Qualitative Research on Software Development:

A Longitudinal Case Study Methodology

Laurie McLeod, Stephen G. MacDonell and Bill Doolin

Auckland University of Technology
Private Bag 92006, Auckland 1142, New Zealand
[email protected], [email protected], [email protected]

Abstract interrelated and together demand more flexible, ad hoc or

non-traditional development approaches. Combined with
This paper reports the use of a qualitative methodology the fact that at the same time software systems have
for conducting longitudinal case study research on become increasingly sophisticated and integrated, the
software development. We provide a detailed description potential for unpredictable or unintended consequences
and explanation of appropriate methods of qualitative has also increased.
data collection and analysis that can be utilized by other
A recent meta-review of prior empirical research on
researchers in the software engineering field. Our aim is
software systems development project outcomes reveals
to illustrate the utility of longitudinal case study research,
that quantitative factor-based studies form the basis of
as a complement to existing methodologies for studying
much of the current knowledge in this area (McLeod and
software development, so as to enable the community to
MacDonell in press). Such studies are cross-sectional and
develop a fuller and richer understanding of this complex,
attempt to measure the causal influence of a set of
multi-dimensional phenomenon. We discuss the insights
contingent conditions or variables on outcomes. However,
gained and lessons learned from applying a longitudinal
the continued problematic nature of many software
qualitative approach to an empirical case study of a
projects and the changing software development
software development project in a large multi-national
environment described above, suggest that there may be a
organization. We evaluate the methodology used to
role for alternative research approaches in enabling a
emphasize its strengths and to address the criticisms
deeper understanding of software development processes
traditionally made of qualitative research.
and practices. A range of research approaches can
generate different and richer information about a complex
Keywords: Qualitative methods, longitudinal case phenomenon such as software development (Harrison et
study, software development, empirical research al. 1999; Lethbridge et al. 2005; Mingers 2001). In
particular, qualitative research methods have been
advocated in this regard, although they still occupy a
1. INTRODUCTION relatively marginal position in software engineering
research compared to quantitative methods (Dittrich et al.
Software systems play an increasingly pervasive and
2008; Glass et al. 2002; Segal et al. 2005).
important role in contemporary organizations, as well as
supporting individuals, and established, temporary and The reason qualitative methods are used relatively
virtual groups. Despite decades of research and the infrequently in software engineering research lies in its
development of an extensive prescriptive literature, as foundations as a scientific and engineering discipline
well as some remarkable successes, software systems (Boehm 2006; Harrison et al. 1999). An inherited
development projects continue to be problematic, with a technical interest in improving practice is associated with
significant number failing or performing poorly (Charette a preference for quantitative research approaches that lend
2005; El Emam and Koru 2008; Royal Academy of themselves to measuring causal relationships for
Engineering 2004; Wallace and Keil 2004). The successful software process improvement (Dittrich et al.
environment in which software development occurs at 2008; Rönkkö et al. 2002). However, studying software
present is characterized by a rapid pace of technological engineering is a complex undertaking not just because of
change, increased devolution of responsibility and its technical aspects, but also “from the awkward
expenditure to user groups, high levels of packaged intersection of machine and human capabilities, and from
software acquisition and customization, greater the central role of human behavior in software
outsourcing of software development, and an increased development” (Seaman 1999, p. 557). Accordingly,
emphasis on enterprise-wide and inter-organizational within the growing trend for empirical studies of software
software intensive systems (Boehm 2006; McLeod and engineering (Perry et al. 2000; Sim et al. 2001; Sjøberg et
MacDonell in press). In many cases these changes are al. 2007), there are increasing calls for the use of
qualitative research methods to address the complex to say about software development. Section 6 evaluates
social and behavioral issues and human-technology the qualitative research presented in this paper to address
interactions involved in software development (Dittrich et the criticisms traditionally made of such approaches. In
al. 2007; Lethbridge et al. 2005; Robinson et al. 2007; Section 7, we outline some lessons learned from this
Runeson and Höst 2009a; Seaman 1999). As the call for research approach that we believe will be useful for other
papers for this special issue suggests, these issues are researchers interested in applying qualitative methods to
central to understanding and improving software research on software development. Section 8 concludes
development practice. the paper.
The main concern in this paper is methodological.
Following Robinson et al. (2007), we have two research 2. CASE STUDY RESEARCH
objectives: (1) to illustrate the utility of one specific
approach to qualitative research on software development, The aim in conducting the research on which this paper
longitudinal case study research; and (2) to guide and draws was to investigate the in situ process and practices
support other researchers wanting to conduct qualitative of software development as perceived and understood by
research on software development by providing an those involved in performing such work (Coleman and
exemplar of this form of research and a discussion of the O'Connor 2007; Dittrich et al. 2007). As Lethbridge et al.
lessons learned and issues that arise in conducting such (2005) argue, this means conducting empirical studies in
research. To meet these objectives, we describe the field settings. That is, the phenomenon under study is
qualitative methods used in a longitudinal case study of a investigated “within its real-life context” (Yin 2003, p.
recent software development project. The underlying aim 13), using a case study approach. Experiments and surveys
of the research was to develop an explanation of how and are unable to do this to the same extent, since an experiment
why the particular project outcomes in the case study divorces the phenomenon from its context and surveys are
emerged over time. A full description and analysis of the limited in their ability to investigate context (Yin 2003).
case study are beyond the scope of this paper. Full details
Case studies have been a commonly used and legitimate
can be found in McLeod (2008). Instead, aspects of the
method of research inquiry for studying related fields
case study will be drawn on in illustrating the qualitative
such as information systems (Benbasat et al. 1987;
research methodology followed.
Cavaye 1996; Doolin 1996; Markus and Lee 1999) and
By qualitative research, we mean research that computer supported cooperative work (Dittrich et al.
emphasizes words and images rather than numbers and 2007; Wainer and Barsottini 2007) for some time.
quantitative measurement in data collection and analysis. Equally, the case study method could be usefully
While many researchers equate qualitative research with deployed in investigations of software development
an interpretivist epistemology (Bryman and Bell 2007), processes and practices, a position that has received
we apply the term at the level of data or method (Guba recent support (Runeson and Höst 2009a; Segal et al.
1990). This allows for the possibility of qualitative 2005). After all, software development is generally an
research within a number of research traditions and with (organizational) activity that involves complex
various philosophical assumptions (Dittrich et al. 2007). interrelationships between people, structure, procedures,
The main difference in application lies in the research politics and culture – elements that require qualitative
questions asked and in the interpretation of the data. Our empirical case study research in real world settings
own research approach is ‘broadly interpretive’ (Walsham (Runeson and Höst 2009a, 2009b) if they are to be
1993, 2006), focusing on the content, context and process genuinely understood. Indeed, it has been noted that case
of software development as a complex and intersubjective study research has begun to be used in the field of
social reality that is interpreted rather than discovered. software engineering, although it often lacks sufficient
However, essentially the same methods of data collection research grounding or systematic analysis, or is not used
and analysis that we describe in this paper could be to its full potential (Höst and Runeson 2007; Perry et al.
utilized from a post-positivist perspective (Guba 1990). 2004; Runeson and Höst 2009a, 2009b; Sjøberg et al.
Both traditions seek to conduct research in natural 2007).
settings close to the phenomena of interest, use qualitative
The emphasis on studying a phenomenon in its context
methods to increase richness, and depend extensively on
(Yin 2003) means that case study research focuses on
inductive theory grounded in local contexts (Coleman and
actual organizational tasks, processes and activities, and
O'Connor 2007).
involves direct contact and close interaction between the
The remainder of the paper is structured as follows. In researcher and organizational participants (Doolin 1996).
Section 2, we locate the research approach discussed in Case studies also typically involve multiple data sources,
the paper in the wider context of qualitative case study including observation, interviews, documents and archival
research. Section 3 describes the selection of the case records, in order to develop a triangulated and in-depth
study used in the paper, a brief summary of the software analysis and a contextual understanding of the research
development project studied is provided, as well as a setting (Bratthall and Jørgensen 2002; Cavaye 1996;
short comment discussing research ethics, increasingly Darke et al. 1998; Easterbrook et al. 2008; Runeson and
recognized as an important consideration in software Höst 2009a; Yin 2003). Case study research offers a
engineering research. Section 4 discusses in detail the degree of flexibility in that key parameters of the research
methods used for qualitative data collection and design can be altered during the study in order to react or
qualitative data analysis. In Section 5, we discuss what adapt to “the complex and dynamic characteristics of real
the longitudinal qualitative research approach enabled us world phenomena” (Runeson and Höst 2009a, p. 137).
While case study research does not generate the In a longitudinal case study, data are collected over an
statistically significant conclusions of controlled extended period in order to investigate “how certain
empirical studies, it provides rich descriptions of social conditions change over time” (Yin 2003, p. 42). In-depth,
interactions and practices, reveals the knowledge and holistic case studies are often carried out longitudinally
perspectives of organizational participants, and yields a (Walsham 1993) to facilitate a “multifaceted treatment of
“deep understanding of a phenomenon in one context, change” (Pettigrew 1990, p. 270). A longitudinal case
which may bring insight into others” (Wynekoop & study enables software development to be observed as it
Russo, 1997, p. 51, Easterbrook et al. 2008; Robinson et unfolds, describing events as they occur and accessing
al. 2007; Runeson and Höst 2009a). participants’ actions and interpretations at the time. This
provides rich data that can be analyzed to trace the
Case studies typically describe a phenomenon, explore a
dynamics of change, which is important when trying to
phenomenon, or produce an explanation of a phenomenon
understand the complex interactions surrounding software
(Perry et al. 2005; Runeson and Höst 2009a). Descriptive
systems and their development. Software development
case studies may focus on an extreme or unique case,
unfolds within constantly changing contexts and
perhaps a previously inaccessible phenomenon, worth
conditions, which are difficult to capture using cross-
portraying and documenting (Yin 2003). Exploratory case
sectional methods. Longitudinal case studies can support
studies are used to investigate a little known phenomenon
the construction of holistic explanations of the outcomes
or one without an established theoretical basis. They are
of complex social processes (Leonard-Barton 1990;
often used as an initial exploration to generate new
Pettigrew 1997; Voss et al. 2002).
insights or propositions for further research (Easterbrook
et al. 2008; Runeson and Höst 2009a). Lethbridge et al. In terms of software engineering, longitudinal case
(2005, p. 314) suggest that many case studies in software studies such as that discussed in this paper address the
engineering research are exploratory “because we are still need for research that focuses on observation of the
gathering basic knowledge about the human factors practice of software developers in order to understand the
surrounding software development and maintenance.” complexity of software development (Westrup 1993). In
Explanatory case studies seek to provide a theoretical doing so, we emphasize the emergent nature of software
explanation for a phenomenon. These are most development rather than the deterministic view prevalent
appropriate for addressing “how” and “why” research in the software engineering literature, placing “the on-
questions (Yin 2003). Some researchers use explanatory going nature of the software processes … at the heart of
case studies to confirm or refute existing theories the analysis” (Allison and Merali 2007, p. 668).
(Easterbrook et al. 2008).
In addition, case study research designs can involve a 3. CASE SELECTION
single case or multiple cases. Single case studies may use
a critical case to test previously formulated theory or a In the longitudinal case study described here, the unit of
representative case to inform on typical experiences (Yin analysis was at the level of a single project. This
2003). Single case studies may also be used to provide a necessitated identifying and negotiating access to both a
holistic, in-depth analysis of one setting, characterized by host organization and a specific project within it. The
production of the rich descriptions favored by interpretive contracting between the researchers and a host case study
researchers. In contrast, in a multiple case study design, organization is particularly important in longitudinal case
detail and richness of description may potentially be study research as there is a need for close, trusted contact
sacrificed (to some extent) for the opportunity to make over an extended period of time (Pettigrew 1997).
comparisons across several settings (Doolin 1996). From A range of potential research sites was available, as a
a positivist perspective, multiple case studies may number of respondents to a survey we conducted into
represent literal replications (analogous to repeated software systems development practice had indicated
experiments) or theoretical replications used to generate their willingness to participate further in an in-depth case
contrasting results for predictable reasons (Easterbrook et study. Each of these organizations was examined to
al. 2008; Yin 2003). establish whether it was an appropriate case study site
based on its software systems development profile. This
resulted in a short-list of six potential organizations, who
2.1. Our Approach: Longitudinal Case Study were contacted in turn. The first two respondents
Research contacted declined to participate, one because of changed
circumstances and the other because of concern over the
In terms of locating the research approach described and
commercial sensitivity of some of their projects. The third
discussed in this paper, a single holistic explanatory case
respondent contacted, the CIO of AlphaCo, agreed to
study (Yin 2003) was conducted in order to examine the
meet to discuss the organization’s potential involvement
social and organizational dynamics of software
in more detail. AlphaCo, a large manufacturing company,
development in situ. The focus was on how software
operates in a competitive global manufacturing and
development is enacted as a process, and how and why
distribution environment. (AlphaCo is a pseudonym used
particular development outcomes emerge over time in
to refer to the case study organization in this study.
particular organizational settings. In order to achieve this
Similarly, pseudonyms are used for key individuals,
consideration of time and context, a longitudinal research
position titles, and organizational units or teams within
design was utilized.
AlphaCo and other organizations involved in the case
study, to preserve confidentiality.)
A series of meetings was conducted with various longitudinal research taken required a project that could
members of AlphaCo’s Information Systems (IS) be followed ‘in action’ (Latour 1987).
function, in order to negotiate access to the organization
The project owners were a small team of business
and to identify a suitable project that could be observed as
analysts, led by a manager and reporting to a senior
it unfolded. At the initial meeting in mid-December 2004,
commercial manager, who was the project sponsor.
the CIO was supportive of the proposed case study,
Consistent with organizational policy and practice in
suggesting that AlphaCo had a “role in society” to play in
outsourcing non-core competencies, an external project
supporting research. He agreed to raise the matter with
manager was hired to manage the project. Support for the
AlphaCo’s IS Project Office Manager, who would be able
project within AlphaCo was available from the IS Project
to identify a list of potential projects to observe. After a
Office and an IS Architect seconded to the project.
two month delay, a meeting was finally secured with the
AlphaCo company policy and practice advocated the
IS Project Office Manager, who gave an overview of how
acquisition of packaged software rather than internal
software systems projects are executed within AlphaCo
development of a solution. Accordingly, SoftCo, an
and outlined several projects that he thought might be
external development and implementation consultancy,
suitable. He agreed to approach the various business
were engaged to build a database solution using a
owners associated with these projects in order to see who
proprietary application development tool (a multi-
might be receptive to having an external observer on their
dimensional database and OLAP tool called MDS), for
project. An initial approach to one business unit was
which SoftCo were the licensed vendors.
declined on the grounds of commercial sensitivity.
The project was intended to be a straightforward
After a further month, the IS Project Office Manager
migration of existing spreadsheet models to a database
successfully identified a potential project and cooperative
solution. From the outset, it was perceived as relatively
business owner, and arranged a meeting with a business
small and well-defined, supported by senior management,
analyst from the team that manages AlphaCo’s
involving committed users and with no major threats to
information technology (IT) infrastructure outsourcing
project delivery within the planned six-month project
contract. This team was about to commence a project
timeframe. In practice, however, the project was subject
involving the development of a database solution to
to various delays and problems so that it stretched over an
replace existing financial spreadsheet models used for
eighteen month period.
managing the IT outsourcing contract. The team member
described the project, which seemed to meet the Initial delays were experienced in finding a suitable
requirements of the research. After some discussion, it external project manager, identifying and engaging an
was agreed that the first author could observe the project appropriate software package vendor, and in negotiating
on an ongoing basis as required. the nature of development. The SoftCo staff member who
negotiated the project bid, underestimated the project
A meeting was then set up with the IS Project Office to
complexity and solution requirements, committing the
negotiate a confidentiality agreement. Part of the
SoftCo development team to an extremely tight timeframe
difficulty in negotiating an acceptable agreement was that
and financial budget. The tight project schedule
AlphaCo’s standard confidentiality agreement was
necessitated a lower level of involvement in the solution
designed for sub-contracted project work and emphasized
development than was originally envisaged for the
the ownership of intellectual property arising from the
AlphaCo business analyst who would be the primary user
project. It took a series of meetings and emails to
of the database solution. Development proceeded in
negotiate a mutually acceptable understanding that, while
several overlapping and iterative stages, involving cycles
preventing the unintentional disclosure of commercially
of building by the SoftCo developers, testing by members
sensitive information was a priority (AlphaCo would be
of the AlphaCo project team, and subsequent amendment.
given the opportunity to review the findings of the
Development quickly fell behind schedule, and
research to ensure this had not occurred), from an
milestones had to be revised. Even when a largely
academic research perspective the researchers needed to
completed solution was eventually available, final testing
retain editorial control over the final publication
was delayed due to data corruption and problems within
(Pettigrew 1997).
the solution.
By this time, a major organizational restructuring had
3.1. The Project Studied taken place within AlphaCo. Not only did the new
database solution “fall off the radar”, but a change in
The project selected for study provided a useful management focus reduced the demand for reporting from
opportunity to investigate software development practices the new solution. Ultimately, the inability to complete the
and processes, from multiple stakeholder perspectives, in project and produce a usable software solution in a timely
the modern software systems environment described manner led to it losing its relevance in the organizational
earlier. It was a short to medium term project, involving context and its subsequent lack of use within the
commercial software package acquisition, the outsourced company.
development and configuration of that software
(including a degree of joint development), a range of
internal and external stakeholders and project participants, 3.2. Ethical Considerations
and devolution of project responsibility to the project
business owners. In addition, the project could be A number of authors emphasize the importance of ethical
observed from initiation to deployment. The approach to standards of conduct for maintaining trust and
cooperation in software engineering research (Runeson per week). However, during a 7-week period of intensive
and Höst 2009a; Sieber 2001; Singer and Vinson 2002). software development activity, she visited the site each
Ethical approval for this research was obtained from the working day (averaging about 7.5 hours per day).
researchers’ university ethics committee before fieldwork Subsequent to this initial period of the project, as work on
commenced. During the course of the fieldwork, as it became more sporadic, a number of follow-up visits to
people became involved in the project under study or the field site were undertaken until some form of closure
were interviewed, they were spoken to individually by the could be made in terms of actual use of the new solution.
first author about their potential involvement as research During this second, less intensive, period of the project,
participants. At this point, the person was told about the regular phone and email contact was maintained with the
purpose of the research, the nature of any involvement, main participants, in order to keep abreast with progress
what measures would be taken to protect their rights as on the project and to coordinate site visits. In total, 558
participants (including protection of their identity), and hours were spent on site within AlphaCo, observing
the right to not participate or to withdraw at any stage. project activities or interviewing staff.
Participants were given an information sheet detailing this
information, and were asked to sign a consent form, Fig 1. Time spent on site at AlphaCo over the course of
acknowledging that they understood what was entailed by the project
their participation and agreeing to have various activities
audio-taped and used for research purposes. A signed
copy of the consent form and information sheet was 10

9
retained by each participant and by the researchers. These

Time spent on site per day (hrs)

8
procedures (mandated by the researchers’ university) are 7

consistent with those recommended by Runeson & Höst 6

(2009a). 5

All of the individuals encountered during the case study 3

agreed to participate in the research. Participants engaged 2

with the researcher in a very open, genuine and 1

cooperative way. An overriding concern in conducting 0

1 Apr 05

1 Apr 06

1 Apr 07
1 Jun 05

1 Aug 05

1 Jun 06

1 Aug 06

1 Jun 07

1 Aug 07
1 Oct 05

1 Feb 06

1 Feb 07
1 Dec 05

1 Oct 06

1 Dec 06
fieldwork and subsequent data analysis was to treat their
contributions with respect and integrity at all times.

4. APPLYING QUALITATIVE METHODS 4.1.1. Observation

4.1. Data Collection Observation of project activities was a primary source of
data in this study. The field researcher (the first author)
As noted earlier, case study research involves close essentially undertook ‘participant observation’, in the
involvement with participants, including face-to-face sense that she participated in the research setting as much
contact, in the research setting. As Nandhakumar & Jones as possible over a prolonged period, interacting with the
(1997, p. 111) suggest, the best way to understand social project participants and collecting data with their
processes is “to get access to the actors themselves and to knowledge (Seaman 1999; Tolich and Davidson 1999).
elicit their interpretations directly.” In longitudinal case While this did not (usually) comprise direct participation
studies, this involves more intensive and extended in functional project activities, it did entail close
interaction with participants over a prolonged period of involvement and familiarity with the team at the centre of
time. This enables observation of social processes as they the study and their daily practices. By personally
unfold, provides insight into local knowledge and experiencing the research context under everyday
practices, and reveals alternative or shifting conditions, she was able to acquire sufficient contextual
interpretations (Lanzara 1999; Nandhakumar and Jones knowledge to be able to interpret what was being
1997). A range of data collection methods are available to observed , facilitating the development of an in-depth
achieve this familiarity with the organizational context ‘inside view’ on people, issues, events and activities
and participants, including observation of activities, (Bratthall and Jørgensen 2002; Nandhakumar and Jones
conversations and interviews with organizational 1997; Walsham 1995, 2006). From a longitudinal
participants, and review of organizational documentation perspective, participant observation over an extended
and project artifacts. period enabled the observation of software development
The case study was conducted between mid-2005 and processes more or less continuously over time.
mid-2007. The intention was to follow the project The field researcher had a desk co-located with the
inception, development of the solution, its deployment project team for the first eight months of the project, and
and initial use. Field work was conducted by the first access to an organizational workspace as required for the
author. It involved an initial 8-month period coinciding rest of the time. She was able to attend meetings, observe
with the main project activity (Figure 1). Work on the project activities, ask questions of and conduct informal
project by the various participants was not continuous, so conversations with project participants, and access a wide
a pragmatic decision was made to observe project work range of documents, including the company intranet and
when activities of interest were due to occur. This online document repository. The kinds of activities
typically involved the field researcher visiting the site for observed included various project management activities
two or three days each week (averaging about 12 hours
based around AlphaCo’s established processes, in-house A standard joke amongst the project team involved
preparation of a solution prototype for use by vendors and threatening to include her in some of the project work:
the eventual developers, preparation and distribution of a
Marie (SoftCo Project Manager): You’ll be able to
Request for Information (RFI) document, interaction with
get her [Laurie] to help do some testing. [To Laurie]
vendors, product demonstrations, formal selection of a
Frank’s got a greater plan for you.
vendor/product, informal and formal project meetings,
solution development, testing and training, and solution Laurie (Researcher): I don’t know the model well
delivery and transfer to the live environment. enough to do any testing.
Some 37 formal meetings were held over the course of Frank (AlphaCo Project Manager): Oh, it’s just data
the project. Observation of these meetings was considered validation.
important given their significance as sites of interaction
and negotiation between project participants. The field (Informal conversation, 24 November 2005)
researcher was kept informed of these formal sessions, From the outset, an open and unconstrained approach to
enabling her to attend all but one. The 36 meetings data collection was possible. The primary method of
observed spanned around 47 hours in total (Table 1). recording field observations was writing detailed notes of
Information about the missed meeting was obtained from what was going on or being discussed, wherever possible
discussions with participants and reviewing formal using the participants’ own words in order to preserve the
documentation. essence and integrity of what was being said. In total,
seven A5 notebooks (each with 200 leaves) were filled
Table 1. Summary of formal meetings observed with field notes. Field notes were openly written in these
notebooks during the observation period as events
Meeting type Number Total time
observed (minutes)
occurred. At no time was there any need to hide what was
being done or to seek “the privacy of the toilets” (Whittle
Interviews for an external project 2 90 2005, p. 1308)! In addition, formal meetings, project
manager activities and informal conversations were regularly
7 635
Vendor meetings and demonstrations
audio-taped (with permission), particularly where they
7 450 involved interactions between the AlphaCo project team
AlphaCo project team meetings and the developers from SoftCo. Some 42 hours of
9 290
Weekly project meetings with SoftCo recordings were made, providing a comprehensive record
5 175
Other project meetings with SoftCo of what was said, particularly when more than one
6 1175 participant was involved. Judgment needed to be
Training sessions in development
tool and solution
exercised in deciding which activities to record in order to
avoid being overloaded with data. Most audio recordings
Total 36 2815 (46.9 hrs) were transcribed in full; the remainder were listened to
and transcribed in part when considered relevant.
Participants did not appear to temper what they were
saying because the session was being recorded.
As a participant observer, the field researcher and what Comparison of the field notes with transcripts from
she was doing were readily accepted by staff at AlphaCo various audio-taped sessions showed good internal
and members of SoftCo. Participants were generally very consistency, both in terms of the quality and extent of
supportive, often enquiring about the progress of her content that was recorded (Zuboff 1988).
research or whether she had the support or access she
required. Indeed, she was included on the project email Nevertheless, participants remained aware of the field
list, so as to be kept aware of forthcoming activities or researcher’s observational role and that field notes or
emerging issues. This was particularly important given recordings were being made, sometimes explicitly
the discontinuous nature of the site-based field work. referring to them during project activities. For example,
Over time, the field researcher developed a close during some of the taped sessions, AlphaCo staff would
relationship with the project participants and was not remind the field researcher that certain commercially
excluded from project activities or confidential or sensitive material could not be revealed. In another
sensitive issues. Participant observation included example, in trying to work out how part of the eventual
interacting on a social level with members of the project database solution had been created, Claire, one of the
team and staff from SoftCo, such as taking coffee breaks AlphaCo Business Analysts, commented, “Your notes
or lunch with them, or being included in conversations will probably say it, somewhere, Laurie” (Informal
and jokes: conversation, 18 January, 2006). Again, in a conversation
between AlphaCo and SoftCo project staff about an error
Claire (AlphaCo Business Analyst): Man, this must in the emerging software solution, a joke was made about
be boring for you [observing]. It’s boring for me, the potential use of the researcher’s audio recordings:
and I’m doing it … Aren’t you glad you spent years
at university to do that? Claire (AlphaCo Business Analyst): You had to
change a couple of things.
Laurie (Researcher): [laughs] Yeah.
Gary (AlphaCo Business Analyst): The NPV
(Informal conversation, 14 December, 2005) calculation. I don't know what school you went to.
 Nancy (SoftCo Senior Developer): Do you know, I The longitudinal nature of the research enabled this repeat
wrote that with Frank? interview technique, with which participants’ changing
perspectives and interpretations could be tracked over
Gary: Did you?
time (Constantinides and Barrett 2006).
Nancy: Yeah … [To Laurie] You were there.
Interviews were typically audio-taped (with permission)
Laurie (Researcher): I know nothing about NPV. and transcribed in full. Where taping was not possible,
extensive field notes were made. A total of 33 interviews
Marie (SoftCo Project Manager): I can see your
were conducted, comprising almost 24 hours, for an
little recordings are going to become interesting. average interview time of around 45 minutes (Table 2).
Claire: Very sought after!
Table 2. Summary of interviews
(Project meeting, 27 January 2006)
Total
Number of Number of interview
Interviewees
interviewees interviews time
4.1.2. Interviews (minutes)

Another primary source of data was semi-structured AlphaCo project team

interviews, a common form of interviewing in case study IS Architect 1 1 105
research. These involve working from an interview guide External Project Manager 1 5 130
– a list of planned questions and interview topics aimed at Business Analysts 2 12 405
Business Managers 2 4 135
ensuring their systematic coverage across interviews.
However, the interview is flexibly conducted to allow for Other AlphaCo IS staff
improvisation and exploration of emerging issues (Allison IS Project Office 3 4 310
and Merali 2007; Myers and Newman 2007; Runeson and IS Managers 2 2 90
Höst 2009a). IS Analysts 2 2 135
SoftCo project team
Very early on, a senior manager said that AlphaCo staff
were generally open and that most of them would be Project Manager 1 1 30
prepared to be interviewed as long as the demands on Senior Developers 2 2 90
their time were not excessive. This was the field Total 16 33 1430 (23.8
researcher’s experience. In order to systematically obtain hrs)
information relevant to the project, all organizational
participants with a direct interest in the software system at
the centre of this study and/or those who participated in 4.1.3. Documentary Data Sources
the project itself were interviewed. Other members of
AlphaCo’s IS function, chosen because of their Other data sources were used to supplement the
knowledge and experience (Zuboff 1988), were also observation and interviewing described above. As noted
interviewed in order to understand the software systems earlier, full access to project-related emails was ensured
development environment within the organization. The by the field researcher’s inclusion in the project e-mailing
semi-structured interviews were another important and list. These emails were categorized and stored as an
rich source of data about the project itself, as well as additional source of documentary evidence. All project
development practice within both AlphaCo and SoftCo. documentation was made available to her through the co-
operation of project managers from both AlphaCo and
The interview guides used for the semi-structured SoftCo. AlphaCo’s IS policy, planning and process
interviews were customized to the role of the interviewee, documents were also reviewed so that the field researcher
the nature of the information they could provide and the could become familiar and fluent with IS processes,
stage the project was at. Interviewees were asked a set of practices and terminology. Much of this documentation
general questions about their organizational role, their was contained in a digital process document repository. A
involvement or interest in the project, their perspective on range of organizational documents and electronic sources
organizational events and activities, and their experiences provided a rich source of contextual information.
of development practice in their organization. In addition, Examples of the organizational and project
a list of specific questions was compiled for each documentation reviewed are shown in Table 3. In
participant about aspects of the project that they could addition, over 100 publicly available articles on AlphaCo
comment on, procedural matters, and issues arising during and its IS function were accessed and reviewed. The
the course of the project. Where relevant, organizational digital nature of almost all of the documentation reviewed
policy and procedure documents or artifacts were used as facilitated its management and manipulation in the
the focal point of discussion to both elicit information and subsequent qualitative data analysis.
minimize the potential for misunderstanding.
Some interviewees were interviewed multiple times over
4.2. Data Analysis
the course of the project as new developments or issues
emerged. Combining interviews with observation enabled Preliminary data analysis began early in the project and
questions to be tailored to the individual experiences of continued during the main period of intensive field work
these key informants (Whittle 2005), in an iterative and after as required. It entailed the field researcher
process of observation and verification (Pettigrew 1990). repeatedly reviewing the field notes and other
documentation available at the time in order to identify Themes may be generated inductively (from the data) or
relevant activities, events and issues related to the project. deductively (from a priori theory). In the study described
These were recorded in a spreadsheet together with the here, a combination of these approaches was used. The
sources of data that informed them, including which data from the various sources described above (i.e. field
participants’ views had been obtained or still needed to be notes, interview transcripts, emails, and various project
sought. The spreadsheet served as an important resource and organizational documents) were progressively
drawn upon by the field researcher to manage data collated into electronic form in documents. Initially, data
collection from project participants and other data were broadly categorized using eighteen factors
sources. influencing software systems development that had been
identified from prior literature (McLeod and MacDonell
Table 3. Organizational and project documentation in press). For ease of management, extracts from the data
reviewed relating to each initial category were contained in a
separate document. Data extracts were identified by
AlphaCo organizational documentation reference to their source (e.g. collection date and page
number in a field notebook, or the source electronic
Organizational project Staff intranet
management standards document). Where a data extract was considered to be
Internal company monthly relevant to more than one category, it was included in
Organizational restructuring magazine
documents and presentations
multiple locations (Whittle 2005). Cross-references were
Company annual reports made between different categories to reflect and reinforce
Organizational website their inter-relatedness and interaction.
AlphaCo IS process documentation Data within each initial category were read and re-read on
multiple occasions, often separated by significant periods
IS process document repository IS strategic and business plans of time. In this part of the analysis, the data were
(procedures, templates, checklists, categorized and re-categorized using a process of constant
guidelines, examples) IS quality standards and
governance documentation comparison (Glaser and Strauss 1967) to identify more
IS project life cycle refined themes based around specific aspects of how the
IS balanced scorecard reports and
Project tracking system and documentation project was enacted. These themes were predominantly
manual inductively derived from the data, although the analysis
IS policy framework and policies was informed by the researchers’ understanding of
software development and by reference to relevant social
IS induction manuals
theory and the findings of prior empirical studies. As a
more detailed understanding of and familiarity with the
AlphaCo project documentation
data was achieved, progressively more detailed themes
IT outsourcing contract Vendor reference checks (often based around the research participants’ own
management documentation vocabulary) were applied to the data and used to organize
Vendor evaluation reports
IT outsourcing contract
it. In this way, the data analysis was an emergent process
management financial models and Vendor service level agreement involving interplay between data interpretation and theory
documentation Project deliverables (concept (Walsham 1995, 2006). Table 4 illustrates the range and
External project manager Terms of document, project definition, depth of themes that could develop around a given initial
Reference feasibility reports, project plan, category, in this case project participants’ ‘understanding’
closure report)
Solution prototype, data and
in interaction around software development.
documentation Project monthly progress and
update reports Being able to manipulate data electronically was a
RFI document convenient way of handling, searching and comparing the
Project self-assessment report
Vendor RFI responses and product
large volumes of data involved. Co-locating extracts of
information data from various sources in their entirety (as opposed to
single codes) in the same document meant that the
SoftCo project documentation researcher revisited the textual context in which the data
was situated each time the data was read. The aim of this
Project costing and deliverables Training manuals was to minimize the possibility of making interpretations
documentation
Solution documentation based on the data removed from the context in which they
Project meeting agendas and occurred. Throughout the data analysis, explicit attempts
minutes Software license agreement
were made to retain chronological order and temporal
Task allocation plan relativity of the data, in order to facilitate the subsequent
Issues register
identification and description of episodes within the case
study. One technique used was to visually represent
across elapsed project time critical events and changes in
aspects of the project content, context, participants and
After the end of the main data collection period, a more their interactions, and software development processes.
comprehensive, thematic analysis was used to interpret These visual representations were an important resource
the data collected. Thematic analysis is a widely used in interpreting the case study data and structuring the
method for identifying, organizing and reporting patterns subsequent case description and narrative.
or themes that capture meaningful aspects of the data in
relation to a research question (Braun and Clarke 2006).
Data from the thematic analysis formed the basis of a narrative into eight episodes, each reflecting a degree of
detailed ‘chronological’ (Allison and Merali 2007; Yin continuity of activities in the software development
2003) case narrative of the project as it unfolded over process and distinguishable from other episodes for
time. Twenty-one key project activities were identified, analytical purposes. The use of episodes both structured
together with critical events and changes in aspects of the the narrative and allowed the researchers to consider
project content, context and process Pettigrew 1990; actions and interactions in one period in the context of the
Walsham 1993) over the course of the project. Temporal larger temporal whole or interconnectedness (Pettigrew,
bracketing (Langley 1999) was used to divide the case 1990).

Table 4. Themes developed in this project around the initial category ‘understanding’

– Conceptions of the project – Understanding the original spreadsheet models

– As a database solution + For all
+ Within AlphaCo + For Claire
+ Within SoftCo + For Frank
+ Within Vendor1 – For Gary
+ As a tool – His understanding of the models
+ Building/constructing a solution – Of the evaluation model
– Configuration – Of the scorecard model
– Source of that understanding
– Translation
– Through his involvement in the project
+ Migration of existing model
– Asking questions
+ Replication of existing model
– Using the model
– Understanding the process
– Consequences for the project
– Barriers to understanding – From his understanding of evaluation model
– Time/Tight deadline – Using the model in MDS
– The model itself – Contributing to others’ understanding
– Access to Claire’s original model – Role in testing
– Concerns over not accessing C’s model – Contributing to form of emerging model
– Were SoftCo’s concerns justified? – Caused things to drag at the end
– Not having all the information at the outset – From his understanding of scorecard model
– Things not 100% defined – Consequences for ongoing use of MDS model
– Coming in late and under-prepared – From his understanding of evaluation model
+ Aspects of the model causing difficulty – From his understanding of scorecard model
+ Understanding scenario copying – For SoftCo
– Resource calculations – Understanding of the models
+ These are complex – Consequences of late/partial understanding
+ Getting it right – Inefficiencies
– But model largely the same
+ Getting it right for Year 2 onwards
– Source of that understanding
+ Understanding the MDS technology
– What they did not do
– Understanding the emerging model
– Project definition
– The overall model
– Missing the scoping meeting
– Developing the emerging model – What they did do instead
+ Aspects of the model itself & how it is built – Using the solution prototype
+ Misunderstanding – Diagrams from Claire
– Interactions
+ The process of creating understanding

+ Indicates further detail or sub-themes

– Indicates no further detail under the theme or sub-theme than that shown

Rather than simply a case history or description, the case (Allison and Merali 2007; Constantinides and Barrett
narrative attempted to provide a meaningful explanation 2006; Gasson 1999). Participant quotations were used in
of how and why the sequence of events in this particular the case narrative to illustrate important points in the
software development project, situated in a specific analysis. Typically, these were selected as representative
organizational setting and involving multiple groups of of the views of the participants involved. Where
internal and external actors, produced the observed appropriate, unique or contrasting views were also
outcome (Pentland 1999; Pettigrew 1997). The intention presented (Zuboff 1988).
was “to derive theoretical interpretation from data … To support and summarize the case narrative, ‘visual
rather than to test theory against data” (Nandhakumar and mapping’ (Langley 1999) was used to produce a
Avison 1999, p. 180). Central to this theoretical diagrammatic representation of the sequential relationship
interpretation was a conceptualization of software between episodes over the course of the software
development as a complex and emergent process, often development project. This ‘process chart’ (Langley and
with unintended effects, involving a dynamic relationship Truax 1994) depicted at a high level the emergence of the
between people, software technology, and the social and project outcome over time from a trajectory of key (often
organizational context in which development occurs
overlapping and iterative) project activities, influenced by used, see McLeod (2008)). It includes three of the
significant contextual events, project participants’ analytically identified episodes, which relate to the
perceptions and actions, and material or technological identification of SoftCo as a potential vendor, negotiation
artifacts. As such, the process chart provided a useful of how development would proceed, and the initial
abstraction and temporal representation of the case study development of a solution. The six key project activities
data that could be used to support the more detailed case included in these episodes are briefly summarized in
narrative. Figure 2 shows one section of the process chart Table 5. The graphical notation used in the process chart
from the study to illustrate the technique (for the complete is adapted from Langley and Truax (1994) and Madsen et
process chart and a fuller description of the approach al. (2006).

Fig 2. Partial process chart for the AlphaCo software development project
Oct Oct Nov Dec
2005 2005 2005 2005
E4: Emergence of a new vendor E6: Building the solution
E5: Negotiating development

Preferred supplier policy Differing

Tight interpretation
Conception of of original
SoftCo identified as timeframe
super-user specs
potential vendor (SoftCo)

Limitations of
prototype models

11. Vendor evaluation 14. Negotiation of the Limited joint

A revisited
SoftCo selected
nature of development development

16. Negotiation of Out-of-scope

12. 2nd Feasibility
Gate 2 approval 13. Project planning Gate 3 approval out-of-scope project work
Report preparation
issues agreed

Incomplete
15. Solution development
solution delivered
B

Prototype Approach to
MDS
models development
development tool
(SoftCo)

KEY
Square-edged boxes represent activities Ovals represent contextual properties or events that influence activities

Rounded boxes represent outcomes Pages represent aspects of material or technological artifacts that influence activities

Solid arrows represent precedence in the sequence of activities Hexagons represent assumptions or beliefs held by project participants that influence activities

Zig-zag lines represent activities that have been terminated Dotted arrows link influences (ovals, pages or hexagons) to relevant activities

Table 5. Key project activities in Episodes 4-6

Episode 4 Emergence of a new vendor
Activity 11 Vendor evaluation revisited: The inadvertent discovery of SoftCo, with a product (MDS) already used by an
AlphaCo subsidiary, led to a re-evaluation of the available solution options. MDS was constructed as the
preferred solution on cost since software licenses and a hardware server could be shared with the subsidiary.
2nd Feasibility Report preparation: This project deliverable was rewritten and approval to proceed was
Activity 12 granted.
Episode 5 Negotiating development
Activity 13 Project planning: Initial planning with SoftCo established that development was to be done onsite at AlphaCo
on a standalone server with considerable input from members of the AlphaCo project team to transfer
knowledge of the MDS tool. A development timeframe was agreed. To save time, agreement was obtained
from the IS Project Office to start development without waiting for formal approval of a detailed project plan.
Negotiation of the nature of development: The extent of the AlphaCo project team members’ participation in
Activity 14 the solution build was renegotiated and reduced due to SoftCo concerns about tight project costs and
timeframe.
Episode 6 Building the solution
Activity 15 Solution development: Development proceeded in overlapping and iterative cycles of building, testing and
amendment. Development quickly fell behind schedule, and milestones were revised.
Negotiation of out-of-scope issues: A SoftCo perception of escalating project scope and costs led to the
Activity 16 negotiation of whether remaining project tasks were part of the original project specifications or ‘out of scope’.
5. WHAT DID THE LONGITUDINAL 5.2. Insights into Software Development Practice
QUALITATIVE APPROACH YIELD? The qualitative case study analysis provided a number of
We believe that using a longitudinal qualitative case study insights into the nature of software development that we
methodology in software development research opens up believe are of potential interest to software development
possibilities that have not received extensive attention to in other locales. These insights arise from the richness of
date in the software engineering field. In this section, we the data obtained, the detailed and in-depth analysis this
outline some of these possibilities in terms of what this enabled, the longitudinal dimension incorporated into the
research approach yielded in the case study on which the study, and the consideration of the content, context and
paper is based. We identify three main contributions: the process of software development. While the insights
production of holistic explanations of software generated in the case study analysis are not necessarily
development as an emergent process, the derivation of novel, they contribute towards building a body of
specific insights about software development practice, cumulative research that addresses the complex and
and the generation of theoretical models of software dynamic nature of software development, which can
development. better inform software development practice and lead to
more beneficial outcomes for all stakeholders involved.

5.1. Software Development as a Complex and

Emergent Process 5.2.1. The Influence of Initial Characterizations of
a Project
The invariant relationships between variables and
outcomes assumed by traditional factor studies rarely Initial characterizations of a software development project
exist in complex, ‘real world’, social phenomena. can play an important role in shaping participants’
Reductionist approaches to dealing with software attitudes and actions in the development process. The
development fail to adequately deal with the dynamic and early characterization of the project in this case study as
interactive processes involved in such a complex small, well-defined and uncomplicated meant that
organizational practice. In contrast, a longitudinal decisions and choices were made that affected the project
qualitative approach such as that presented here opens up trajectory. On AlphaCo’s part, no baseline review of the
the ‘black box’ (Latour 1987) of software development, adequacy of the original financial models was undertaken,
by focusing attention on the sequence of events and the decision was made to forego a formal problem
situated actions that comprise the software development definition process, and the employment of an
process and that connect antecedents with outcomes inexperienced external project manager was considered
(Pentland 1999), “enabling one to track cause and effect” acceptable. A similar underestimation of the complexity
(Leonard-Barton 1990, p. 250). Software development of the project by SoftCo committed them to an overly
trajectories are rarely linear, continuous and predictable. tight timeframe and project budget, with consequences for
Instead of singular explanations of software development, how the nature of development was negotiated and indeed
longitudinal case study research facilitates the production how the solution development proceeded.
of holistic and analytically complex explanations that take
into account the discontinuous, multi-directional and
open-ended nature of the development process as it
5.2.2. The Role of Participants’ Sense-Making in
emerges over time (Langley 1999; Pettigrew 1997). Shaping Actions and Decisions
In the case study described here, the software Consideration of how individual project participants’
development project did not take the smooth and knowledge, expectations, perceptions and interests shape
straightforward path anticipated by its originators. Rather their sense-making, decisions and actions helps to explain
than following the intended linear project lifecycle, the how software development proceeds through the
project trajectory was characterized by overlapping and negotiation and communication of a shared understanding
parallel tracks of events and activities, reverses or of the development problem and solution. In the case
iterations in specific aspects of development, and was study, this often involved a particular interpretation of the
subject to unintended consequences or unanticipated problem at hand that stabilized its meaning and aligned
events. Instead of a predictable project path and outcome, the understanding and interests of different participants
the software development that occurred in the case study around it (Gasson 1999). Ambiguous or problematic
was actually anything but that, experiencing delays and aspects of the software development process were often
difficulties more typical of larger projects. The project’s conceptualized and made sense of by the use of various
trajectory and outcome could not be adequately explained symbolic artifacts such as metaphors or ‘transient
in terms of simple prescriptions for successful constructs’ (Lanzara 1999), enabling a way forward to be
development or the presence or absence of particular identified and negotiated by the participants. For example,
factors. The protracted and problematic nature of the construction of the notion of ‘out-of-scope’ project
development that led to a software solution that had lost work by the SoftCo project manager provided a way of
its organizational relevance was an emergent outcome or understanding and making sense of contested elements of
effect of complicated, multi-dimensional the project. It enabled the negotiation of what tasks were
interrelationships and interactions between social, legitimate demands on the developers’ time, how project
material and contextual influences on software costs would be allocated, and what was an acceptable
development. solution delivery timeframe. The case study analysis also
highlighted how the contribution or lack of contribution 5.2.5. The Role of Unanticipated Events and
of key individuals can facilitate or constrain the Unintended Consequences
development of a shared understanding in software
development. Finally, the case study analysis reveals the extent to
which the software development trajectory and emergent
solution may be shaped and influenced by unanticipated
5.2.3. The Material Content of a Project events or unintended consequences of decisions and
actions (Markus and Robey 1988). For example, the
The case study analysis highlighted the importance of not inadvertent discovery of SoftCo, late into the vendor
neglecting the technological dimension in analyses of engagement process, delayed the project and introduced a
software development. Material resources and new set of actors with various associated consequences.
technological artifacts mediate the work practices and In another example, a decision to share software and
interactions of the various participants involved in the hardware with an AlphaCo subsidiary in order to reduce
software development process (Schultze and Orlikowski costs led to extensive time delays and problems in
2004). At a general level, the material and technological transferring the eventual software solution from the
content of the project studied, such as the chosen development environment to AlphaCo’s networked
development technology and existing IT infrastructure, environment. Multiple or ongoing unintended effects,
functioned as constraints and capabilities within which often of varying nature, can arise from a single decision
the emerging software solution was developed. In or action. One example from the case study was the
addition, particular project-related artifacts and underestimation of the project complexity by SoftCo
representations (e.g. the solution prototype, RFI mentioned above. This committed SoftCo to unrealistic
document, task allocation plan, issues register) functioned project milestones and costs, with consequential
as ‘boundary objects’ (Star 1989; Subrahmanian et al. downstream effects in the form of project slippage,
2003) in facilitating communication and collaboration version control problems, solution errors, inadequate
between the AlphaCo project team and the SoftCo testing and repeated amendments. It also meant
developers. Boundary objects span different communities development was renegotiated to reduce AlphaCo team
or groups, providing sufficient flexibility in interpretation members’ participation in development work, which
to accommodate individual meanings and interests while compounded the delays experienced and reduced the
serving as a common basis for knowledge-sharing and potential for transfer of knowledge of the MDS
negotiation. In the case study, particular boundary objects development tool.
stood in for or delegated for individual participants and
their knowledge. Other boundary objects were used as the Software development tends to be portrayed as a
basis for contract negotiation or conflict resolution. From predictable and controllable intervention in the software
a practice perspective, software engineers need to engineering literature (Allison and Merali 2007). In
understand the potential for such objects to influence contrast, the case study analysis supports the contention
interaction and negotiation between participants in a that control or management of a software development
software development project. project is an emergent property of situated software
development practice, rather than a determining factor
(Madsen et al. 2006), as participants recognize and
5.2.4. The Importance of Context respond to unanticipated events or the unintended
consequences of decisions taken (Galliers and Swan
Consideration of the context in which a software 2000).
development project is situated helps to demonstrate how
various contextual elements influence and structure
project-related activities by providing rules and resources 5.3. Towards a Theoretical Model
that participants draw on in making choices and decisions,
thus shaping the field of possible actions (Giddens 1984). In analyzing the case study, it became apparent to the
The case study analysis highlighted how, for example, researchers that the project trajectory and outcome could
AlphaCo’s guiding principles for software systems not readily be reduced to a single set of contributory
acquisition and development, standard procedures for factors. Rather, a more detailed consideration and
project management, and historical organizational conceptualization of the complex practices and processes
practices were implicated in shaping the software involved in software development was required. Overall,
development process and trajectory in particular ways. the analysis enabled the development of an understanding
Further, software development occurred in an of software development as a process in which a software
organizational context of rapid and continuous change. system emerges from a dynamic and interactive
The longitudinal analysis revealed how the ‘formative relationship between the technological and material
context’ (Ciborra and Lanzara 1994) within which the components of the software system and artifacts used in
proposed software solution was situated shifted over time, development, the social and organizational context in
thus undermining the relevance of the developed solution which the software system is designed, developed and
within a changed organizational context. used, and the negotiated actions of various individuals
and groups with an interest in the software system or its
development.
Based on this understanding, a theoretical model of
software development as situated practice was developed
(see McLeod 2008). This was a major outcome of the were sought. Validity was also improved by spending
research, and was used to analyze, interpret and present sufficient time with the case, and analyzing negative or
key events and activities in the case study analysis. It contradictory evidence (Easterbrook et al. 2008; Runeson
provided the theoretical basis for the explanation of the and Höst 2009a).
software development process outcomes generated in the
The second way that the traditional critique of qualitative
study. It is also of potential value outside the study, as an
research and case studies can be addressed is by
analytical tool for other software engineering researchers,
understanding that statistical significance is not the only
as a guide for project managers in planning and executing
form of valid knowledge (Runeson and Höst 2009a). For
software development projects, as a basis for software
example, Yin (2003) argues that analytic, not statistical,
project evaluation, or in educating future software
generalization is the goal of case study research; case
engineers about the situated and emergent nature of the
studies “are generalizable to theoretical propositions and
software development process in practice.
not to populations or universes” (p. 10). Walsham (1995)
extends this in arguing that such research can be used to
develop theoretical concepts that inform further
6. EVALUATING THE RESEARCH
theoretical development, to generate or refine theoretical
Qualitative research and case studies are often criticized frameworks, to draw specific implications from one
as being of limited value (e.g. useful only for exploratory particular domain that can be useful in understanding
research), subject to bias, and inadequate as a basis for similar phenomena in other contexts, and to contribute
generalization (Flyvbjerg 2006). Runeson and Höst rich insights or implications on a wide range of issues.
(2009a) suggest that this critique can be addressed in two The longitudinal case study of software development
ways. The first is to ensure that appropriate research described here developed a number of theoretical insights
methods and practices are systematically and consistently and an in-depth understanding of software development
applied. Runeson and Höst emphasize the importance of as an emergent process that, although grounded in the
adequately defining and describing the data collection and particularity of the case study, are nevertheless relevant
analysis methods used, providing a chain of evidence with and meaningful beyond the research site.
traceable inferences, and the consideration of alternative Research should be judged according to criteria
perspectives and explanations. They note that this appropriate for the underlying assumptions of the research
involves more than simply listing methods; rather a tradition within which it is conducted, and there is
detailed ‘history of the inquiry’ is called for. The growing recognition that interpretive case studies, such as
description of the application of qualitative data collection the research described in this paper, should be evaluated
and analysis methods in the study provided earlier in the against criteria appropriate to their nature (Klein and
paper is such an account. Myers 1999; Markus and Lee 1999; Walsham 2006). The
In addition, the validity of qualitative research can be validity of the understanding or interpretation derived
improved by using triangulation, as multiple sources of from such research relies on its ability to provide a
data are likely to result in better justified findings (as well convincing explanation of the phenomena studied and on
as more findings) (Bratthall and Jørgensen 2002; Dittrich the clarity of the logical reasoning underpinning its
et al. 2007; Easterbrook et al. 2008; Runeson and Höst argument (Walsham 1993). Following Golden-Biddle &
2009a). As Miller (2008, p. 226) observes, “Triangulation Locke (1993), Walsham & Sahay (1999) suggest that to
provides an explicit vehicle for tackling the principle produce convincing explanations, interpretive case study
issues or limitations presented by a single empirical accounts need to demonstrate authenticity, plausibility,
study.” In the study described here, multiple and and criticality. The way in which these three criteria were
complementary sources of data were used and multiple addressed in analyzing and presenting the longitudinal
perspectives across different levels in the organization case study is summarized in Table 6.

Table 6. Criteria for evaluating the longitudinal case study (after Walsham and Sahay 1999)
Criterion Explanation Application in the study (McLeod 2008)
Authenticity Shows that the authors • Describes the extent and nature of fieldwork, the role of the researcher and interaction with
have ‘been there’, by participants
conveying the vitality of • Rich descriptions that display familiarity with participants’ everyday actions and use quotes from
life in the field participants
• Seeks multiple participant perspectives and is sensitive to different participant interpretations
• Demonstrates systematic, disciplined and iterative approach to data collection and analysis
Plausibility Connects to the personal • Uses schematics such as tables, figures, models and visual mapping to make sense of the data for the
and professional experience reader
of the reader • Develops a comprehensive explanation of the phenomenon studied that is supported by relevant
theory
• Explicitly considers the social and historical context of the phenomenon investigated
• Demonstrates the relevance of the analysis to contemporary software development practice in
organizations
• Makes a distinctive contribution through the development of an analytical model of software
development
Criticality Encourages readers to • Offers a novel model for understanding software development as situated practice
consider their taken-for- • Applies non-mainstream ways of thinking about social interaction and the role of technology in
granted ideas and beliefs software development.
7. LESSONS LEARNED projects or parts of an organization. Further, conduct of
the research can be adversely affected by events within
Dittrich et al. (2007, p. 536) suggest that an important the organization. In the case study described here, time
step in qualitative research involves “reflection on the and organizational restructuring meant that many of the
lessons learned and the applicability and usefulness of the key participants left the project (or indeed the
chosen research design”. In this section, we reflect on the organization) before fieldwork was eventually completed.
longitudinal qualitative approach used in the case study
and presented in the paper to derive a number of lessons
learned that we hope will be helpful to other software 7.2. Rich Data
engineering researchers and in improving the relevance of
qualitative research on software development (Allison Close engagement in a particular research context yields
and Merali 2007). the rich data needed for an in-depth and holistic analysis
based upon the ‘thick description’ (Geertz 1973) of
software development processes (Allison and Merali
7.1. Researching in Action 2007; Nandhakumar and Jones 1997). As noted earlier,
prolonged and close proximity to the phenomenon being
The key benefit of the longitudinal qualitative approach researched and the use of multiple methods, including
taken in the study was the ability to follow software participant observation, semi-structured interviews and
development in action, before the software system is document review, produced a familiarity with and
completed and “blackboxed” (Latour 1987, p. 258). understanding of the content, context and process of
Observing software development processes continuously software development in the case study. Participant
over time is essential to producing a temporal observation meant that useful data was obtained from
understanding and explanation of how processes are informal conversations and observation during software
connected to outcomes in an emergent and often development activity as well as from the semi-structured
unpredictable way. While a longitudinal dimension can be interviews. The former were particularly important for
added retrospectively, such studies rely on the recall of deriving a context-sensitive understanding of the project
participants, which may be faulty or susceptible to studied and also for discerning the sometimes subtle
influence from subsequent events or post-rationalization differences between individuals’ perspectives and
(Leonard-Barton 1990). Further, researching in action interests within the respective project teams.
reveals the way that participants’ perspectives,
interpretations or positions may change over time. However, as various authors have noted, the collection of
large amounts of rich data in longitudinal qualitative
Despite the benefits, there are practical considerations research can be as challenging as it is potentially
associated with this type of research. Observing processes rewarding. Such large volumes of complex data require
continuously over time requires considerable access to time and effort to analyze. It is easy to be overwhelmed
and time spent at a research site (Nandhakumar and Jones by the amount and richness of the data, or so focused on
1997; Westrup 1993). For various reasons, it may be detail that higher-level interpretations or patterns do not
impractical for a researcher to be in the field for the entire emerge (Leonard-Barton 1990; Nandhakumar and Jones
period of software development activity. Choosing when 1997; Robinson et al. 2007). Still, as Seaman (1999, p.
and what to observe may be somewhat arbitrary, unless 558) points out, if qualitative data are “more difficult to
the research participants can assist in keeping the summarize or simplify … then, so are the problems we
researcher informed – more likely if a close and study in software engineering.” In the case study
cooperative relationship with participants is established. described in this paper, a number of mechanisms were
Even then, there is the possibility of unanticipated events used to deal with the volume and complexity of data
occurring when the researcher is not present, necessitating generated from the fieldwork. These included the use of a
reliance on retrospective participant accounts. However, spreadsheet by the field researcher to manage data
as experienced in this case study, the intensity of activity collection around specific project activities, events and
in software development projects can vary over time, emerging issues across the various data sources available.
which may mean that fieldwork can also be conducted in Temporal bracketing was used to divide the project
stages of varying intensity to match development project trajectory into analytically meaningful episodes of related
activity. software development activities, and key elements of the
The access involved in a longitudinal qualitative study process data were abstracted out and graphically
requires a considerable commitment from the represented using visual mapping techniques.
participating organization to cooperation over an
extended period of time. To the host organization, the
7.3. Multiple Perspectives
costs of the research in terms of time, disruption and
commercial confidentiality may seem to outweigh the Actively accessing multiple participant perspectives is
perceived benefits, necessitating much work by the important in developing a holistic understanding of an
researcher in managing organizational expectations and organizational phenomenon like software development,
relationships (Leonard-Barton 1990; Nandhakumar and particularly as it often involves a wide range of internal
Jones 1997). Even if access to a suitable organization is and external participants and stakeholders. Multiple
secured, access to potential projects may not be under the perspectives across different organizational levels are
control of your organizational sponsor, or commercial important in obtaining data relevant to multiple levels of
sensitivity may preclude outsiders accessing particular context, and in avoiding reliance on or bias from a single
perspective. In the case study described in this paper, the 7.4. Relationship between the Researcher and the
AlphaCo managers were able to provide information Researched
about, for example, organization-wide policies and issues
to do with IT strategy or software acquisition and A number of authors have highlighted the significance of
development. This ‘big picture’ perspective (Coleman and the relationship between the researcher and the researched
O'Connor 2007), although useful, was removed from in qualitative research involving close engagement with
actual software development work. To understand the the research context (Nandhakumar and Jones 1997;
organizational history of software development and how Robinson et al. 2007). These authors suggest that there is
it occurred in practice within AlphaCo (as opposed to a “tension involved in moving between two worlds”
policy), it was necessary to talk with those participants for (Robinson et al. 2007, p. 545), arising from the dual role
whom software development was part of their everyday of the field researcher as both a participant experiencing
experience and work. Similarly, conversations with the the research context and a researcher analyzing and
SoftCo developers revealed a much more informal interpreting it. This had several consequences in this
knowledge of and adherence to the software development study, including negotiating and maintaining an
methodology espoused by the organization and the appropriate distance (or closeness) to the research context
SoftCo project manager. Again, discussing the software and participants. For example, the field researcher was
development project with the externally-appointed comfortable socializing with participants at the workplace
AlphaCo project manager provided a refreshing and often or during work hours, but turned down an invitation to an
counter view of organizational and software development after-hours Christmas party organized by SoftCo for their
practice in AlphaCo. clients. Similarly, she was careful to maintain an
association with all participants, to avoid being perceived
Sensitivity to multiple participant perspectives applies not
as favoring specific individuals. Care was also taken not
just across different hierarchic levels in an organization or
to disclose to others personal information or views
different groups associated with software development,
expressed to the researcher by any one participant.
but also within groups. Commonly used categories such
as ‘users’, ‘developers’ or ‘managers’ are not In many ways, being known to be a doctoral researcher
homogeneous groups, but comprise individuals with was advantageous to conducting field work in the
potentially different characteristics, interests and software development project. It was a role the
capabilities. Further, individuals can have multiple or participants recognized and seemed to respect, and helped
changing roles in a software development project and the researcher to engage the participants’ interest and
their actions may be influenced by a range of personal, cooperation while maintaining a certain degree of
organizational or professional commitments and distance or difference. That AlphaCo staff were used to
affiliations (McLeod and MacDonell in press). For having external parties involved in software development
example, the field researcher observed how, during the projects may also have facilitated acceptance of the field
project in this case study, a relatively junior AlphaCo researcher and her participation in the organizational
business analyst, who had been given an official status as context.
a ‘super-user’ of the MDS development tool being
acquired from SoftCo, successfully resisted this technical
definition of his role in favour of a continuation of his 8. CONCLUSION
current business role.
In this paper, we outline the longitudinal qualitative
Multiple participant perspectives may also imply research approach used to investigate a case study of a
differences, or even conflicts, in participants’ software development project in a large manufacturing
interpretations of events and activities. Rather than organization. We discuss the utility of this approach and
attempting to resolve such differences, perhaps based on show how it enabled the derivation of an in-depth
the perceived reliability of various participants, in order to understanding of software development as a complex and
arrive at a singular explanation, the approach taken in this emergent process, the generation of a range of insights
study was to exploit and tease out differences and their into software development practice, and the development
reasons to reveal differing aspects and a more holistic of a theoretical model of software development as
explanation of the software development process studied. situated practice that was used to explain the outcome of
For example, in this case study, tension arose between the software development in the case study but is also of
AlphaCo and SoftCo project teams around whether potential value in other contexts. We also abstract out
particular development tasks were in or out of scope. some lessons learned in conducting the research that may
Observation of this tension and subsequent conversations benefit other qualitative researchers in software
with the participants revealed different interpretations of engineering.
not only the project specifications but also the basis for
how development should have proceeded. This difference In presenting in some detail the qualitative research
in understanding was crucial in explaining why the methods that were followed in the study, we provide
software development trajectory proceeded as it did in the practical guidance on one way to undertake qualitative
case study. research on software development practice. Researchers
can use the approach developed here to conduct, analyze
and illustrate the processes occurring in the longitudinal
case studies of software development. Comparison of
how software project outcomes emerge and unfold over
time in multiple case studies will help “build up a
repertoire of knowledge about what can be expected in Darke P, Shanks G, Broadbent M (1998) Successfully
practice and what can be done to cope with the situation” completing case study research: Combining rigour,
(Madsen et al., 2006, p. 236). relevance and pragmatism. Inf Syst J 8(4):273-289
The analysis summarized in the paper confirms the utility Dittrich Y, John M, Singer J, Tessem B (2007) Editorial
of qualitative approaches for addressing the complexity of for the special issue on qualitative software engineering
software development processes as enacted in local research. Inf Softw Technol 49(6):531-539
settings. A major implication of this study is that a multi-
Dittrich Y, Rönkkö K, Eriksson J, Hansson C, Lindeberg
dimensional consideration of software development is
O (2008) Cooperative method development: Combining
needed to understand this complex organizational
qualitative empirical research with method, technique and
phenomenon. Adopting such a research approach
process improvement. Empir Softw Eng 13(3):231-260
facilitates a holistic analysis rather than a narrow focus on
individual dimensions and aspects of the phenomenon. Doolin B (1996) Alternative views of case research in
information systems. Aust J Inf Syst 3(2):21-29

ACKNOWLEDGMENTS Easterbrook SM, Singer J, Storey M-A, Damian D (2008)

Selecting empirical methods for software engineering
This research was funded through a Top Achiever research. In Shull F, Singer J, Sjøberg DIK (eds) Guide to
Doctoral Scholarship by the Tertiary Education advanced empirical software engineering. Springer,
Commission of New Zealand. We would like to London, pp. 285-311
acknowledge the support of AlphaCo and SoftCo. El Emam K, Koru AG (2008) A replicated survey of IT
software project failures. IEEE Softw 25(5):84-90

REFERENCES Flyvbjerg B (2006) Five misunderstandings about case-

study research. Qual Inquiry 12(2):219-245
Allison I, Merali Y (2007) Software process improvement Galliers RD, Swan JA (2000) There's more to information
as emergent change: A structurational analysis. Inf Softw systems development than structured approaches:
Technol 49(6):668-681 Information requirements analysis as a socially mediated
Benbasat I, Goldstein DK, Mead M (1987) The case process. Requir Eng 5(2):74-82
research strategy in studies of information systems. Gasson S (1999) A social action model of situated
Manag Inf Syst Q 11(3):369-386 information systems design. Database Adv Inf Syst
Boehm B (2006) A view of 20th and 21st century 30(2):82-97
software engineering. In Rombach D, Soffa ML (eds) Geertz C (1973) Thick description: Toward an
Proceedings of the 28th International Conference on interpretative theory of culture. In The interpretation of
Software Engineering. ACM, New York, pp. 12-29 cultures: Selected essays. Basic Books, New York
Bratthall L, Jørgensen M (2002) Can you trust a single Giddens A (1984) The constitution of society: Outline of
data source exploratory software engineering case study? the theory of structuration. University of California Press,
Empir Softw Eng 7(1):9-26 Berkeley and Los Angeles
Braun V, Clarke V (2006) Using thematic analysis in Glaser BG, Strauss A (1967) The discovery of grounded
psychology. Qual Res Psychol 3(2):77-101 theory: Strategies for qualitative research. Aldine,
Bryman A, Bell E (2007) Business research methods, 2nd Chicago
edn. Oxford University Press, Oxford Glass RL, Vessey I, Ramesh V (2002) Research in
Cavaye ALM (1996) Case study research: A multi- software engineering: An analysis of the literature. Inf
faceted research approach for IS. Inf Syst J 6(3):227-242 Softw Technol 44(8):491-506
Charette RN (2005) Why software fails. IEEE Spectr Golden-Biddle K, Locke K (1993) Appealing work: An
42(9):42-49 investigation of how ethnographic texts convince. Organ
Sci 4(4):595-616
Ciborra CU, Lanzara GF (1994) Formative contexts and
information technology: Understanding the dynamics of Guba EG (1990) The alternative paradigm dialog. In
innovation in organizations. Account Manag Inf Technol Guba EG (ed), The paradigm dialog. Sage, London, pp.
4(2):61-86 17-27
Coleman G, O'Connor R (2007) Using grounded theory to Harrison R, Badoo N, Barry E, Biffl S, Parra A, Winter B,
understand software process improvement: A study of Wuest J (1999) Directions and methodologies for
Irish software product companies. Inf Softw Technol empirical software engineering research. Empir Softw
49(6):654-667 Eng 4(4):405-410
Constantinides P, Barrett M (2006) Negotiating ICT Höst M, Runeson P (2007) Checklists for software
development and use: The case of a telemedicine system engineering case study research. In Proceedings of the
in the healthcare region of Crete. Inf Organ 16(1):27-55 First International Symposium on Empirical Software
Engineering and Measurement (ESEM’07). IEEE
Computer Society, Washington DC, pp. 479-481
Klein HK, Myers MD (1999) A set of principles for Perry DE, Porter AA, Votta LG (2000) Empirical studies
conducting and evaluating interpretive field studies in of software engineering: A roadmap. In Proceedings of
information systems. Manag Inf Syst Q 23(1):67-94 the Conference on the Future of Software Engineering.
ACM, New York, NY, pp. 345-355
Langley A (1999) Strategies for theorizing from process
data. Acad Manag Rev 24(4):691-710 Perry DE, Sim SE, Easterbrook SM (2004) Case studies
for software engineers. In Proceedings of the 26th
Langley A, Truax J (1994) A process study of new
International Conference on Software Engineering
technology adoption in smaller manufacturing firms. J
(ICSE’04). IEEE Computer Society, Washington DC, pp.
Manag Stud 31(5):619-652
736-738
Lanzara GF (1999) Between transient constructs and
Perry DE, Sim SE, Easterbrook SM (2005) Case studies
persistent structures: Designing systems in action. J
for software engineers. In Proceedings of the 29th Annual
Strateg Inf Syst 8(4):331-349
IEEE/NASA Software Engineering Workshop - Tutorial
Latour B (1987) Science in action: How to follow Notes. IEEE Computer Society, Los Alamitos CA, pp.
scientists and engineers through society. Harvard 96-159
University Press, Cambridge, MA
Pettigrew AM (1990) Longitudinal field research on
Leonard-Barton D (1990) A dual methodology for case change: Theory and practice. Organ Sci 1(3):267-292
studies: Synergistic use of a longitudinal single site with
Pettigrew AM (1997) What is processual analysis?
replicated multiple sites. Organ Sci 1(3):248-266
Scandinavian Journal of Management 13(4):337-348
Lethbridge TC, Singer J, Sim SE (2005) Studying
Robinson H, Segal J, Sharp H (2007) Ethnographically-
software engineers: Data collection techniques for
informed empirical studies of software practice. Inf Softw
software field studies. Empir Softw Eng 10(3):311-341
Technol 49(6):540-551
Madsen S, Kautz K, Vidgen R (2006) A framework for
Rönkkö K, Lindeberg O, Dittrich Y (2002) 'Bad practice'
understanding how a unique and local IS development
or 'bad methods': Are software engineering and
method emerges in practice. Eur J Inf Syst 15(2):225-238
ethnographic discourses incompatible? In Proceedings of
Markus ML, Lee AS (1999) Special issue on intensive the 2002 International Symposium on Empirical Software
research in information systems: Using qualitative, Engineering (ISESE’02). IEEE Computer Society,
interpretive, and case methods to study information Washington DC, pp. 204-210
technology. Manag Inf Syst Q 23(1):35-38
Royal Academy of Engineering (2004) The challenges of
Markus ML, Robey D (1988) Information technology and complex IT projects. Royal Academy of Engineering,
organizational change: Causal structure in theory and London
research. Manag Sci 34(5):583-598
Runeson P, Höst M (2009a) Guidelines for conducting
McLeod L (2008) Understanding IS development and and reporting case study research in software engineering.
acquisition: A process approach. PhD thesis Empir Softw Eng 14(2):131-164
(http://hdl.handle.net/10292/644), Auckland University of
Runeson P, Höst M (2009b) Tutorial: Case studies in
Technology
software engineering. In Bomarius F, Oivo M, Jaring P,
McLeod L, MacDonell SG (in press) Factors that affect Abrahamsson P (eds) Product-focused software process
software systems development project outcomes: A improvement (Proceedings of the 10th International
survey of research. ACM Comput Surv Conference, PROFES 2009, Oulu, Finland, June 15-17).
Springer, Berlin, pp. 441-442
Miller J (2008) Triangulation as a basis for knowledge
discovery in software engineering. Empir Softw Eng Schultze U, Orlikowski WJ (2004) A practice perspective
13(2):223-228 on technology-mediated network relations: The use of
Internet-based self-serve technologies. Inf Syst Res
Mingers J (2001) Combining IS research methods:
15(1):87-106
Towards a pluralist methodology. Inf Syst Res 12(3):240-
259 Seaman C (1999) Qualitative methods in empirical
studies of software engineering. IEEE Trans Softw Eng
Myers MD, Newman M (2007) The qualitative interview 25(4):557-572
in IS research: Examining the craft. Inf Organ 17(1):2-26
Segal J, Grinyer A, Sharp H (2005) The type of evidence
Nandhakumar J, Avison DE (1999) The fiction of produced by empirical software engineers. In Proceedings
methodical development: A field study of information of the Workshop on Realising Evidence-Based Software
systems development. Inf Technol People 12(2):176-191 Engineering (REBSE'05). ACM, New York, NY
Nandhakumar J, Jones M (1997) Too close for comfort? Sieber JE (2001) Protecting research subjects, employees
Distance and engagement in interpretive information
and researchers: Implications for software engineering.
systems research. Inf Syst J 7(2):109-131 Empir Softw Eng 6(4):329-341
Pentland BT (1999) Building process theory with Sim SE, Singer J, Storey M-A (2001) Beg, borrow, or
narrative: From description to explanation. Acad Manag steal: Using multidisciplinary approaches in empirical
Rev 24(4):711-724
software engineering research. Empir Softw Eng 6(1):85- Laurie McLeod recently
93 completed her PhD at Auckland
University of Technology
Singer J, Vinson NG (2002) Ethical issues in empirical
(AUT), New Zealand. Her
studies of software engineering. IEEE Trans Softw Eng
doctoral research focused on a
28(12):1171-1180
process approach for
Sjøberg DIK, Dybå T, Jørgensen M (2007) The future of understanding software systems
empirical methods in software engineering research. In development and acquisition.
Briand LC, Wolf AL (eds) Future of software engineering Her research has been published in various journals,
(FOSE'07). IEEE Computer Society, Los Alamitos, CA, including ACM Computing Surveys, Australasian Journal
pp. 358-378 of Information Systems, Journal of Research and Practice
in Information Technology and Journal of Systems and
Star SL (1989) The structure of ill-structured solutions:
Information Technology.
Boundary objects and heterogeneous distributed problem
solving. In Gasser L, Huhns MN (eds) Distributed
artificial intelligence (Vol. 2). Pitman Publishing,
Stephen G. MacDonell is
London, pp. 37-54
Professor of Software
Subrahmanian E, Monarch I, Konda S, Granger H, Engineering and Director of the
Milliken R, Westerberg A, The N-Dim Group (2003) Software Engineering Research
Boundary objects and prototypes at the interfaces of Laboratory (SERL) at the
engineering design. Comput Support Co-op Work Auckland University of
12(2):185-203 Technology (AUT) in New
Zealand. During his time at AUT
Tolich M, Davidson C (1999) Starting fieldwork: An Stephen has also held the roles of Head of the School of
introduction to qualitative research in New Zealand.
Information Technology and Associate Dean
Oxford University Press, Auckland (Development). Stephen was awarded BCom(Hons) and
Voss C, Tsikriktsis N, Frohlich M (2002) Case research in MCom degrees from the University of Otago and a PhD
operations management. Int J Oper Prod Manag from the University of Cambridge. He undertakes
22(2):195-219 research in software metrics and measurement, project
planning, estimation and management, software forensics,
Wainer J, Barsottini C (2007) Empirical research in and the application of empirical analysis methods to
CSCW - a review of the ACM/CSCW conferences from software engineering data sets. He is a Member of the
1998 to 2004. J Braz Comput Soc 13(3):27-36 IEEE Computer Society and the ACM, and serves on the
Wallace L, Keil M (2004) Software project risks and their Editorial Board of Information and Software Technology.
effect on outcomes. Commun ACM 47(4):68-73
Walsham G (1993) Interpreting information systems in Bill Doolin is Professor of
organizations. John Wiley and Sons, Chichester Technology and Organisation in
Walsham G (1995) Interpretive case studies in IS the Business School at Auckland
research: Nature and method. Eur J Inf Syst 4(2):74-81 University of Technology (AUT),
New Zealand. His research
Walsham G (2006) Doing interpretive research. Eur J Inf focuses on the processes that
Syst 15:320-330 shape the adoption and use of
Walsham G, Sahay S (1999) GIS for district-level information technologies in organizations. This has
administration in India: Problems and opportunities. involved work on information systems in the public
Manag Inf Syst Q 23(1):39-66 health sector and electronic business applications and
strategies. His work has been published in international
Westrup C (1993) Information systems methodologies in journals such as Electronic Markets, Information Systems
use. J Inf Technol 8(4):267-275 Journal, Journal of Global Information Management and
Whittle A (2005) Preaching and practising 'flexibility': Journal of Information Technology.
Implications for theories of subjectivity at work. Hum
Relat 58(10):1301-1322
Wynekoop JL, Russo NL (1997) Studying system
development methodologies: An examination of research
methods. Inf Syst J 7(1):47-65
Yin RK (2003) Case study research: Design and methods,
3rd edn. Sage, Thousand Oaks, CA
Zuboff S (1988) In the age of the smart machine. Basic
Books, New York