See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/249747644

Involving Salient StakeholdersBeyond the Technocratic View on Change

Article in Action Research · September 2004

DOI: 10.1177/1476750304045940

CITATIONS READS

74 514

1 author:

Hans Jochen Scholl

University of Washington Seattle
191 PUBLICATIONS 6,565 CITATIONS

SEE PROFILE

All content following this page was uploaded by Hans Jochen Scholl on 27 May 2016.

The user has requested enhancement of the downloaded file.

 Action Research
Volume 2(3): 277–304
Copyright© 2004 SAGE Publications
London, Thousand Oaks CA, New Delhi
www.sagepublications.com
DOI: 10.1177/1476750304045940

ARTICLE Involving salient stakeholders

Beyond the technocratic view on change

Hans J. Scholl
University of Washington

ABSTRACT

Business process change involving information technology has

become notorious for high failure rates. Apparently, the larger
the project scope and size, the higher the failure rate. Also, as a
major factor among others associated with failure, past research
has identified an overemphasis on technical validity and func-
tionality at the expense of the social and institutional process side
in change projects. Yet, even if important factors had been
correctly and completely identified, the social process, within
which they interact, might have remained obscured. Further-
more, long-term, large-scale change projects, particularly when
they encompass IT components as major building blocks, defy
the conventional start-to-closeout, detailed project planning.
KEY WORDS Rather, they unfold in a stepwise fashion with alternative paths
towards a coarse goal, particularly in environments with distrib-
• inclusive process uted powers, as in the public sector. For this process and this
• IT success/failure environment, the author proposes that participatory action
• large-scale business research (PAR) has the capacity to provide a holistic method-
ological and social-process frame and a mode of joint inquiry.
process change
This article gives an account of the approach based on a large
• organizational government change project in its early stages. In this project,
change practitioners and researchers formed a joint team, which strove
• participatory AR to lay foundations to a multi-year, IT-enabled change initiative
• public-sector meant to become a state-wide exemplar for similar projects.
During this early project stage, salient stakeholders and their
change projects
needs were identified, which helped launch a highly inclusive
• social process process. However, as found in this project, external influences
dimension impacted this public-sector project in a way that the build-up of
• technical/ consensus remained incomplete, underscoring the need for
functional paradigm ongoing stakeholder involvement within the project.

277
278 • Action Research 2(3)

Introduction
After decades of research and practice, organizational change projects involving
information technology as a major component are still notorious for high costs
and high risk of failure (Hirschheim, 1985). A core problem in such IT-related
change projects may stem from an overemphasis on both the technical and eco-
nomic aspects at the expense of other aspects such as the organizational and
social impacts (McDonagh & Coghlan, 2001), or, put another way, the technical
validity of the IT component supersedes the context-specific social and organiza-
tional validity (Newman & Robey, 1992). Knowing the success (and failure)
factors, however, provides little guidance in theory and practice as long as their
interaction and interdependence within a social process are unknown (Newman
& Robey, 1992). Nevertheless, social process models of IT-induced change have
remained rare in the literature. In the public sector, it seems such models are in
particular demand due to the sector-specific distribution of powers and the
complexity of interaction through checks and balances, which impact almost any
project of size (Rainey, Backoff & Levine, 1976).
In this article, I present and discuss the case of a large-scale change initia-
tive with a major IT component in its early stages. Well aware of the risky and
messy nature of the undertaking, my researcher colleagues and I carried out this
research in a joint team of practitioners and academics over a period of almost
two years. The article lays out the team’s original concepts, the actions planned
and taken, the outcomes encountered, and the resulting contextualization, the
latter of which might be of great interest to other projects of this nature. The con-
tribution of this article is twofold:

1 It illustrates how participatory action research helps stimulate an inclusive

process, which has the capacity of creating outcomes with social, organiza-
tional as well as technical validity, even if the process has to span across
organizational borders, extend over long periods of time, and cope with
politics and diverging interests; and
2 while it adds to related methods of identifying and involving organizational
participants used in soft systems methodology (SSM) (Checkland, 1981;
Checkland & Scholes, 1990), it also accommodates the PAR approach to the
idiosyncrasies of the public sector, in which ‘satisficing’ (March & Simon,
1958, p. 141) rather than full consensus regarding process and outcomes
appears as a best goal.

The Office of the State Comptroller (OSC) of BIG State initiated this study
and involved in the project the Center (fictitious names), a research institution with
a focus on IT uses in the public sector. The problem facing BIG State was that its
central accounting system, the administrative backbone of the State, was aging.
A number of influential constituents perceived it as being no longer capable of
satisfactorily coping with the State’s rapidly expanding needs for sophisticated
 Scholl Involving salient stakeholders • 279

financial management. Since BIG State officials had painfully learned about the
risks when replacing major administrative information systems, OSC leadership
looked for guidance in this project and chose the Center for assistance.
I have organized the article as follows: First, I briefly discuss why an action
research approach was used. Then, I describe the composition and forming of the
joint team of practitioners and academics, its charter, and its initial problem and
goal definition. Further, I lay out the theoretical foundations the team identified
as relevant for better understanding the problem and defining a path of action
towards solving the problem. Subsequently, two cycles of action: planning,
taking, and evaluating, which the team engaged in, are described. Finally, I con-
textualize my learning outcomes of the project.

Methodology: why action research was used

As Stringer suggests, action research studies should be explicit about why the par-
ticular research design was used (Stringer, 1999). According to Denzin and
Lincoln, action research (AR) is used when practical problems are to be solved in
a context of organizational change (Denzin & Lincoln, 2000). Organizational
and social contexts defy the simplification and identification of clear-cut cause-
and-effect relationships, which made traditional natural science research success-
ful; however, when applying that same pattern to social science research many
results have been found irrelevant (Stringer, 1999). Since research in IT-enabled
organizational change suffers from that exact same fate, a participatory action
research approach was seen as most appropriate. Also, we as the Center
researchers realized that knowing more facts (Torbert, 2001, p. 312) and factors
(Newman & Robey, 1992) about the frequent failure of IT-related change
projects would not help to understand the nature of the problem better nor help
arrive at a desired and widely accepted outcome. We hoped our jointly planned
action and inquiry for the early stage would help stimulate a process conducive to
meeting the constituents’ needs in terms of modern accounting and financial
management. We believed learning would occur at individual and group level
throughout this process, finally leading to a widely accepted outcome demon-
strating the transformational efficacy (Torbert, 1999) of the approach at least for
the initial project stage.

The composition and forming of the joint practitioner/

researcher team and the initial problem definition

The practitioner team initially consisted of 13 individuals from various depart-

ments inside OSC, ranking in the office’s hierarchy from project assistant to
280 • Action Research 2(3)

Assistant Deputy Comptroller; the Director of State Accounting Systems, the

Deputy Director Fiscal Research and Policy Analysis, and the Assistant Director
of State Payroll Systems were also part of this team. Seven researchers were
dedicated to the project including the Center’s Director and Project Director. It is
noteworthy that the hierarchical distance inside the OSC team expanded across
at least seven levels. I will discuss the effect on the project further below.

Problem definition
In an inaugural meeting of all joint team members, two OSC members presented
to the joint team the problem at hand as OSC’s management perceived it:
Launched in the early 1980s, BIG State’s central accounting system (CAS) pro-
vided financial service to all BIG State agencies in budgetary controls, accounting,
and reporting. The CAS was a mission-critical, state-wide system issuing 15,000
payments daily, tracking 80,000 BIG State contracts, and processing 17.5 million
transactions per annum. In other words, CAS was the backbone of BIG State’s
financial structure. However, OSC management recognized that the 20-year-old
mainframe-based CAS was insufficient to support agency accounting and finan-
cial management needs such as:

1 easy access to information to support agency-specific financial management;

2 modifications in the processes by which agencies share information with the
CAS; and
3 influence over the functionality of the CAS.

Also, within OSC itself, concerns had grown about mounting investments made
in agency-based systems designed to address the gap between individual agency
needs and CAS functionality.
The Assistant Deputy Comptroller charted out the general direction of the
problem-solving activity of, first, analysing the problem at hand in more detail,
next, developing a set of recommendations for further action, and, then, depend-
ing on approval by senior management and house committees, implementing
the first stages of those recommended actions, still with help from the Center
researchers. OSC expected the team to complete this first phase within a period
of seven months. OSC management requested a written report authored by the
Center researchers, which was to outline the jointly developed recommendations.

Setting the stage for an inclusive process

In the same meeting, one researcher facilitated a so-called ‘hopes-and-fears’ exer-
cise (Andersen & Richardson, 1997) for the team. On color-coded sheets, the
facilitator asked every team member to write down her hopes (green sheet) or
fears (red sheet), one item per sheet. In a round-robin fashion, each member pre-
 Scholl Involving salient stakeholders • 281

Partnerships and relationships H-2 No change F-1

Hopes Fears
Helps foster vision of OSC as collaborator with OSC or stakeholder inability to have open minds
others to new concepts and begin with ‘clean slate’
Results in credible data – from objective analysis Too much attention on existing system (no new
We end up with a clear statement of ideas)
stakeholders needs Focus on CAS deficiencies, ‘not see big picture’
Helps reach statewide consensus on needs Institutional reluctance to change
Core stakeholder group to work with going Politics will prevent open exchange of ideas
forward
Ways to overcome
That our stakeholders will openly discuss
their needs 1 Sell the project, involve stakeholders
2 Go around them (nay-sayers)
Actions in Support
3 Sell value of change
1 Develop cohesive team (champions) 4 Build trust
2 Honest feedback – communication 5 Look for key person
3 Partnership must first pervade OSC
4 Start 1-3 from beginning
5 Leadership in OSC – awareness and buy-in
6 Resource commitment – OSC

Buy-in H-3 Expectation Management F-3

Hopes Fears
Generates buy-in from key stakeholders Stakeholders will expect more than we can
Get buy-in from those affected by CAS deliver
Help recruit support for eventual CAS redesign Difficulties in defining limitations for project –
Begin a strong foundation (relationship) what processes?
with users Runaway expectations
We get or begin to get ‘buy-in’ and support Unrealistic and unaffordable ‘needs’ identified
for this project statewide Unsatisfied stakeholders when project
Develop broad support for the CAS redesign completed
Not being able to meet expectations
Actions in support
Too much diverse information
1 Get right people involved
Ways to overcome
2 Demonstrate sincerity
3 Learn from XSR (other projects) Constant communication (feedback)
4 Demonstrate project is in interest of Hold structured sessions
stakeholders Communicate ‘can’t have everything you ask for’
5 Enhance relationships (throughout agency) Communicate boundaries
6 Efficiency potential End product is a statement of needs, not a new
7 Explore benefits – BIG State system
8 Convince right people

Methodology H-6 Getting the right people involved F-4

Actions in Support Fears
Helps us choose methodology for Stakeholders will not send the right people
requirements phase Identifying stakeholder spokespersons
Provide a methodology and framework Not getting the ‘right’ stakeholders involved
Add academic rigor and a neutrality to project
Ways to overcome
Characteristics ‘Making the case’ for the project
Enlisting key leadership commitment (benefits/impact)
Identify additional resources Identifying skill sets and time commitments
Research best practices Personal contacts
Pick CENTER and experts’ brains
Continually organize our effort

Figure 1 Selected hopes and fears

282 • Action Research 2(3)

sented one individual hope or fear at a time and handed the respective sheet to the
facilitator who in turn affixed the sheet to the wall and with the guidance from
the submitting participant tentatively grouped them together with other related
items. This exercise lasted almost two hours until every participant had exhausted
her stack of sheets. Then, the facilitator helped the team members cluster the
items on the walls into coherent themes (eight themes for the hopes, seven for the
fears). For those themes, the team then defined measures, which it believed would
foster the hope or mitigate the fear (for selected examples, see Figure 1). One
theme, in particular, was present in many comments: Given the many divergent
interests and politics in the project’s environment, accomplishing the broadest
(rather than complete) stakeholder consensus possible regarding a) the process
itself, b) the course of action, and c) the nature of stakeholder participation would
be the ultimate goal. The hopes-and-fears exercise tremendously helped surface
and align expectations of project-related processes and outcomes among team
members. It also fortified the foundation for mutual trust and respect within the
joint team. During this exercise, we researchers deliberately took a backseat for
the fear the practitioners might not speak as freely as we thought was necessary.
However, from my hindsight perspective I feel it was an unnecessary, if not
counterproductive, precaution. The practitioners proved unafraid of us as
‘academic experts’ throughout the course of the project. On that occasion, for
example, I might have already brought into the open my specific concerns regard-
ing expected internal pressures and dynamics to curtail the unfolding of a truly
inclusive process at some point in favor of an imposed ‘technical’ solution (see
Appendix 1), which actually became an issue during the project, but I decided to
postpone it until we had presented what we knew from the literature and our own
practice about large-project successes and failures.
The joint team also agreed on a project calendar with regularly scheduled
weekly half day meetings with every team member obliged to attend. The joint
team decided to keep detailed minutes of all meetings and to join them in project
journals. We used standard project management tools (overall plan, baseline,
detailed schedules, work breakdown, etc.) to organize the project. As a first step,
the team decided to acquaint itself with related bodies of academic knowledge
before engaging into a detailed stakeholder analysis. OSC management requested
the researchers to take the lead in organizing this first phase of the joint project.

Deconstruction – theoretical foundations of the research

project identified at the outset

What we knew from the literature we grouped into two major bodies of academic
knowledge: 1) the literature on business process (BPC) change in conjunction
with information systems (IS) and their success and 2) stakeholder theory.
 Scholl Involving salient stakeholders • 283

The BPC/IS success literature

For business process change, information technology has been identified as key,
if not the enabler (Champy, 1995; Hammer, 1996; Hammer & Champy, 1993).
Hence, information system development and deployment go hand-in-hand with
process change. Kettinger, Teng and Guha, for example, embed any IS project
into a superseding project of business process change (Kettinger, Teng & Guha,
1997). The authors identify six sequential stages of business process change
(envision, initiate, diagnose, redesign, reconstruct, and evaluate) consisting of
various activities for which they enumerate tools and methodologies. The IS por-
tion of a process change project is not reduced to its technical aspects, rather it is
intertwined with the organizational and social change process, while classical IS
projects typically lack the social design and process transformation perspectives
(Teng, Jeong & Grover, 1998). The so-called system development life cycle
(SDLC) models such as the waterfall model (B. W. Boehm, 1981), which defines
a straight sequence from problem definition to system implementation, most
prominently exemplify the traditional technical paradigm. While the waterfall
model is still widely used for producing commercial off-the-shelf systems (COTS),
iterative elements and even certain environmental factors have been included in
later versions such as in the spiral model (B. Boehm, 1988), when used in indi-
vidual, non-commercial projects. However, the overall success of IS projects
governed by the technical paradigm has remained low. According to the func-
tionalist IS literature, IS project success depends on six main factors:

1 system quality;
2 information quality;
3 use;
4 user satisfaction;
5 individual impact; and
6 organizational impact (DeLone & McLean, 1992)

Also, the lack of understanding regarding the organizational context and the
iterative nature of such projects appear as major failure factors in IS projects,
which developers can overcome via prototyping, group experimentation, and
iterative development (Lyytinen, 1987; see also, Mathiassen & Stage, 1992).
Unlike the predominant technical/functionalist paradigm, evolutionary and
organizational change models emphasize ‘social learning’ and orchestrated orga-
nizational change (Hirschheim & Klein, 1989; Lyytinen & Hirschheim, 1987).
However, as pointed out before, knowing the success and failure factors while
disregarding their interaction within the social process renders that knowledge
meaningless (Newman & Robey, 1992; Robey & Newman, 1996). Influenced by
SSM, such socio-technical approaches pay attention to the social implications of
IS projects to some extent. They attempt to align the internal players on a con-
284 • Action Research 2(3)

sensual basis throughout the process, however, most adaptations of SSM in the IS
literature seem inadequate from a SSM perspective (Holwell, 2000).
With its roots in the British and Scandinavian union movements, Mumford
and also Ehn have developed a socio-technical approach with the democratic par-
ticipation and co-determination of workers (Ehn, 1989; Mumford, 1983, 1987,
1993). Since information systems have the capacity to radically change the organ-
ization and organizational relationships, the socio-technical view focuses on the
role the users play with respect to information technology. As Mumford points
out, in socio-technical system designs, social objectives such as job satisfaction
or quality of work life are seen as equally important as efficiency objectives
(Mumford, 1983, p. 58). This approach holds that the (inner-organizational) user
involvement in the process is critical: Users need to participate in every aspect of
the selection, development, deployment, and use of an IS, and need to co-
determine the whole process, since otherwise they would reject and fail the
deployed systems (Bravo, 1993; Ehn, 1993). However, user participation varies
widely regarding type (everybody versus representatives), degree, content, extent,
formality, and influence (Cavaye, 1995), and the extent of self-regulation of such
user/developer groups depends on the organizational context (Cummings & Doh,
2000).

Stakeholder theory
While both the socio-technical strand and the business process change literatures
are cognizant of important organizational implications and dependencies, when
it comes to information technology enabled change and IS deployment, those
bodies of knowledge fall short capturing the wider picture of potentially diver-
gent interests and constituents’ concerns, particularly in inter-organizational
settings, which is where stakeholder theory bridges the gap of understanding. It is
noteworthy that in Freeman’s classical definition of stakeholder, the influence
between an organization (or project) and the stakeholder can be unidirectional
(‘affect’, or ‘be affected’) in either direction, or bi-directional (Freeman, 1984).
Clarkson incorporates risk as a defining element of a stake into the stakeholder
definition (Clarkson, 1994). Early stakeholder theory described the organization
as the hub at the center of many spokes representing various equidistant stake-
holders (cf. Freeman, 1983; Mitroff, 1983). Mitchell, Agle and Wood develop a
more dynamic perspective on stakeholders. In their view, stakeholders are not
equal due to their different salience. The authors’ approach distinguishes stake-
holders along the attributes of power, legitimacy, and urgency. With the help of
these attributes, seven classes of stakeholders are identified who need different
managerial attention at different times (Mitchell, Agle & Wood, 1997). In
the group of primary or definitive stakeholders, salience in terms of all three
attributes is high. Secondary or expectant stakeholders are those with high
 Scholl Involving salient stakeholders • 285

salience along at least two attributes, while tertiary stakeholders are salient with
regard to only one attribute. Most important for an organization (or project) are
primary and secondary stakeholders who are salient along at least two of those
attributes. Blair and Whitehead (1988) point out that stakeholders also differ
with respect to their potential for collaboration versus their potential for
threatening the organization. Also, stakeholder stances, particularly in the public
sector, may change over time (Scholl, 2001).
The stakeholder perspective presented here resembles certain elements of
SSM, for example, the CATWOE model (in terms of customers, actors, and
owners as well as ‘weltanschauung’ and environmental constraints) used in ‘rich
picture building’ (Checkland & Scholes, 1990). However, the notion of stake-
holder salience and its potential change over time along with changing stake-
holder stances opens for analysis the possibility that stakeholders work towards
ultimately different ends, while they may incidentally align and collaborate for a
limited time or scope, as is the regular case in a system with distributed powers
such as the public sector. Stakeholder theory helps cope with shifts in problem
context and power, which poses a problem in SSM interventions (Mingers &
Taylor, 1992). Stakeholder theory as presented here, hence, enables project teams
to work on the bases of relative consensus and sufficient rather than compre-
hensive participation among salient stakeholders (see Spear, 2001).

Deconstruction – summary
Organizational change projects follow a certain pattern, in which a problem/need
is stated and analysed, a potential solution envisioned and researched, then
planned, developed, tested, modified, tested again, implemented, and finally
evaluated (see Kettinger et al., 1997). When looking at the two bodies of litera-
ture, the joint project team decided to use the cycle as a framework for identify-
ing subsequent steps. The group found that stakeholder salience, and the
influence salient stakeholders can exert on the project, had to be well understood
before engaging in business process change with an embedded IS project effort. It
was concluded that the identification of salient stakeholders leads to the identifi-
cation of salient stakeholder needs, where the latter can differ within homo-
geneous salient stakeholder groups (Wolfe & Putler, 2002). The team conceptu-
alized its theoretical foundation by means of what it called the ‘IT-enabled busi-
ness process change cycle’ (see Figure 2), and decided to follow through along
the lines of this specification. The cycle represents a fusion of the presented
literatures. It follows the Kettinger et al. (1997) cycle of business process change,
however, it also introduces elements of Boehm’s spiral model (B. Boehm, 1988;
Kettinger et al., 1997). Most importantly, from stakeholder theory it adds two
stages for identifying both salient stakeholders and their specific needs (Blair &
Whitehead, 1988; Mitchell et al., 1997; Tennert & Schroeder, 1999) and helps
286 • Action Research 2(3)

Analyze Research focus

problem or Perform
Evaluate task stakeholder
analysis

Perform
Develop, stakeholder
implement needs analysis
13-stage
and test IS

Framework of Conduct BPR

and BP/CP
IT-enabled business
pre-study
Execute build process change
or buy
Primary and secondary Identify and
stakeholder involvement choose analysis
and design tools
in each stage
Redesign
business
processes Analyze business
processes in detail

Redesign
organization Analyze data
Analyze and organization
of data make build-or- in detail
buy decision

Figure 2 The joint team’s theoretical framework

incorporate the social-process dimensions of alliance, community formation, and

cooperation (Fallding, 1990).

Two cycles of action research

Equipped with this ‘theory of practice’ (Friedman, 2001, p. 160), the team iden-
tified the particular problems to be solved in the project, first, the identification,
involvement, and management of salient stakeholders, and second, the identifica-
tion and management of those salient stakeholders’ needs. The reasoning was
that when engaging in an IT-enabled change project of that magnitude, perform-
ing a salient stakeholder and a salient stakeholder needs analysis would lead to a
deeper understanding of the problem and a necessary and sufficient involvement
of those who count, thus, making failure less likely (see Friedman, 2001).
We used Sussman’s classical model of action research cycles, which com-
prise: the diagnosis; the action planning; the action taking; the evaluation; and the
learning specification stages (Baskerville & Wood-Harper, 1996; Heron &
 Scholl Involving salient stakeholders • 287

Reason, 2001; Sussman, 1983). Each diagnosis phase, in which we analysed

cycle-specific problems, was followed by a detailed action-planning phase, in
which we translated the results from the diagnosis phase into action steps. We
described these steps of the action-taking phase in advance in great detail and
then scheduled them. As mentioned above, we used a project journal and uni-
formly organized notes, in which we documented the project steps and recorded
the collected data. In the evaluation phase, we used the journal and the data for
comparing the action plan to the action taken. We also utilized them for reflect-
ing on the effectiveness of the action and the detailed results of the action. In the
concluding phase of a cycle, we took the insights recorded in the journal and the
results derived from the data for specifying our learning and for attaching mean-
ing to our findings. These findings we subsequently fed into the diagnosis phase
of the first cycle iteration, and so forth (Baskerville & Pries-Heje, 1999; Kemmis
& McTaggart, 1988). Beyond helping solve the practical problem of salient
stakeholder identification and subsequently identifying the specific needs of those
salient stakeholders in the joint endeavor, we were also interested in observing
how the fused framework would compare to traditional approaches.

Identifying salient stakeholders

This first cycle comprised a total of three sub-cycles or iterations, which for space
and readability reasons I do not lay out in detail here. During the first sub-cycle,
the joint project team completed the full cycle utilizing the stakeholder analysis
toolkit for diagnosing and testing the approach. This led the team into the second
sub-cycle during which we consulted and actively involved the identified primary
stakeholders. In the third sub-cycle, the project team and the steering committee
of primary stakeholders revisited the results of the previous two sub-cycles. Since
in the third sub-cycle the disconfirmation of findings occurred only in the context
of minor details, the project team and the steering committee concluded that the
chosen framework and its proposed direction were robust and promising enough
to be followed.

First cycle: diagnosis

We decided to use an analysis tool (Tennert & Schroeder, 1999) to chart the
project-related stakeholder landscape. The tool helped diagnose stakeholders’:

1 power to influence the project;

2 sense of urgency with respect to the project;
3 legitimacy to influence the project;
4 expected degree of collaboration during the course of the project; and
5 potential for threatening the project.
288 • Action Research 2(3)

Table 1 Primary stakeholders’ expected stances over the first three project phases

Primary stakeholders Phase 1 Phase 2 Phase 3

(‘Can affect …’ (Until completion (Until completion (Until completion
– Go/No Go) of report) of RFI) of selection)

Technology Mixed blessing ? ?

department (New director Govenor’s office Govenor’s office can
incoming) can influence influence process/
process/issue issue of FMS
of FMS recommendation.
recommendation.
Whom to select?
Technically reporting
to?
Budget Mixed blessing Mixed blessing Mixed blessing
department (Specific ideas, (Specific ideas, (Specific ideas,
experience with experience with experience with
payroll system payroll system payroll system
cost overrun) cost overrun) cost overrun)
Legislature Mixed blessing Mixed blessing Mixed blessing
(More open/listening, (More open/listening, (More open/listening,
also experience with also experience with also experience with
payroll system cost payroll system cost payroll system cost
overrun) overrun) overrun)
OSC Supportive ? ?

Key: ? = Likely stance unclear

We regarded organizational entities as well as individuals as potential stake-

holders. The thorough stakeholder analysis helped us distinguish those who
‘really count’ (Mitchell et al., 1997) such that a stakeholder needs analysis was
the next logical step.
Using the analysis tool and a scoring model for evaluation, we as a joint
team were capable of identifying over 400 organizational and individual stake-
holders. Five BIG State agencies and governmental entities emerged as primary,
definitive, and strategic stakeholders by scoring high on each of the power,
urgency, and legitimacy scales. We also identified 52 secondary stakeholders
(41 BIG State agencies and 11 non-governmental entities) as well as another 68
tertiary stakeholders. This analysis particularly helped us distinguish those stake-
holders with ‘go/no go’ powers over the project from secondary and tertiary
stakeholders who scored high on one or two of the scales but were not expected
to exert ‘go/no go’ powers.
It is worthwhile mentioning that after the stakeholder analysis a significant
number of stakeholder candidates from the original list of over 400 were no
 Scholl Involving salient stakeholders • 289

longer considered for inclusion. This underscores the critical point that not all
stakeholders are equal and that effective stakeholder involvement should start
with this distinction.
The diagnosis of interest landscapes of the primary stakeholders also made
it possible to assess the two other scales of potential for collaboration or threat.
We found that all five primary stakeholders had at least a medium to high
potential for collaboration. Two of the primary stakeholders had a potential for
threatening the project if it was not carried out in a certain way (see Table 1).
This group of primary stakeholders comprised OSC’s internal leadership,
the Budget Department, the Technology Department (names changed), and both
houses of the State Legislature.

First cycle: action planning

On the basis of the diagnosis, we assumed that the earliest possible involvement
of senior managers of the primary stakeholder organizations would be of utmost
importance to the viability of the whole project. Consequently we planned to
contact these individuals to inform them one by one about the project, its design,
and its goals. We would gather preliminary feedback from them, and we would
invite them to become part of a steering committee. As desired by the project
team, the senior level executives personally took on the charge of serving on the
steering committee and maintained their involvement throughout the first and
second cycles. During the meetings held throughout the first and second cycles,
we jointly discussed each significant aspect of the project with those primary
stakeholders before we carried them out.

First cycle: action taking

The first and second meeting with the primary stakeholders was conducted with-
in a four-week timeframe. During these two meetings we provided the primary
stakeholders with in-depth information about the current state of the Central
Accounting System, its limitations, and its decreasing ability to keep pace with
current and future financial management needs of BIG State. We also presented
its theoretical framework including the specifics of the stakeholder and stake-
holder needs analyses. The primary stakeholders endorsed the approach in its
entirety. They also linked the project to a completed state project that had
studied the growing and increasingly expensive proliferation across BIG State
agencies of financial management systems using multiple architectures and plat-
forms. The primary stakeholders saw a direct correlation between the deficiencies
of the current Central Accounting System and the undesired and costly sprawl of
multiple FMS. They urged us to verify this relationship during the subsequent
cycles of the project.
290 • Action Research 2(3)

First cycle: evaluation

When analysing the journals and notes of the previous cycle stages, the joint
project team found the stakeholder analysis tool functional and practical for
systematically and comprehensively identifying potential stakeholders and assess-
ing their initial and future stances towards the project and its possible outcomes.
Had they not conducted this diagnosis, the OSC practitioners in the joint team
acknowledged that several primary and secondary stakeholders would have
escaped their attention.
OSC practitioners agreed that the full engagement of primary stakeholders,
while representing additional work in the short run, represented potential oppor-
tunity for long-run payoffs in terms of buy-in and support for the effort. Each
meeting required a presentation of current thinking on the project for review by
the primary stakeholders. These meetings established transparency and opportu-
nity to influence the process as it was being devised. They kept key decision
makers well informed of the project’s goals and progress and invited them to pro-
vide input into project goals and strategies so that eventual recommendations
would be viewed in the context of this ongoing participation and discussion.

First cycle: specifying learning

Both practitioners and researcher in the joint team found the results promising:
We had obtained detailed, quantified, and qualified stakeholder information. We
used this information directly for conducting three sub-cycle iterations involving
the primary stakeholders identified, during which we sought and found the pri-
mary stakeholders’ full support. So, from that perspective we jointly concluded
that the tool was practical. The theoretical framework was influential in focusing
the efforts of the OSC practitioners. In addition, two other large-scale IT failures,
which had failed to identify stakeholder needs, weighed heavy on the minds of the
OSC team members. However, as early as it was at this stage and despite the
demonstrated usefulness of the tool, a couple of influential practitioners in the
team raised their concerns about the approach, which they regarded as possibly
too academic and too sumptuous for ‘getting the job done’. Unfortunately, with-
out spending more time on addressing and potentially resolving those concerns,
the team majority decided to stay the course and invest in a full analysis of stake-
holders. Ironically, as advocates of the inclusive approach, we were not fully
attentive to those concerns and cut the consensus-building process short at this
juncture, which would negatively pay off in later stages.
 Scholl Involving salient stakeholders • 291

Identifying stakeholder needs

Second cycle: diagnosis

While the first cycle (also referred to as stage 1 of the theoretical framework)
involved the joint project team and the steering committee of primary stake-
holders, the next project phase (here equivalent to the second framework stage)
required eliciting and recording specific wants and needs of a greater number of
important CAS stakeholders. When the joint project team analysed the list of pri-
mary, secondary, and tertiary stakeholders, it became obvious that stakeholders
(even in the same category) were not uniform in their interests and needs and that
dealing directly with well over 100 organizations and thousands of individuals
would not be practicable. Furthermore, the users of CAS, BIG State agencies
varied in terms of:

1 accounting transaction volume;

2 accounting transaction types;
3 integration of CAS functionality into agency-specific applications;
4 data analysis and manipulation needs;
5 reporting needs;
6 financial planning needs; and
7 dependency on timely and accurate information garnered from CAS.

Therefore, the team decided to involve all secondary stakeholders.

Second cycle: action planning

Through the diagnosis the joint project team understood it had to be creative in
its response to this diagnosis. The team considered alternative strategies for hear-
ing from the broadest yet most manageable range of stakeholders. Since range
and nature of stakeholder needs were not exactly predictable ex ante, a data
collection method allowing for interactive inquiry and verification was chosen.
Individual and unstructured interviews, though promising rich, detailed data,
were not feasible for this treatment given the sheer number of individuals
involved. Furthermore, OSC practitioners, with a clear sense for the social
process side, urged that the needs identified and the recommendations derived
from them should visibly and solely have originated from stakeholders’ input and
not from OSC – in other words, not from OSC ‘cooking the soup’. With 41 BIG
State agencies and 11 non-governmental entities qualifying as secondary stake-
holders leading to the involvement of a couple of hundred individuals, the
approach of uniformly structured and facilitated workshops was chosen. Two
individuals were to conduct these workshops, a lead and a co-facilitator. In each
workshop several non-participant observers attended to capture verbal and non-
verbal contributions of participants. We invested significant effort into identify-
292 • Action Research 2(3)

ing logical ways to divide up the BIG State agencies and non-governmental
entities representing the secondary stakeholders. We focused each workshop on
stakeholders that had some common characteristics. For example, those agencies
that used an in-house financial management system formed one group and those
that relied entirely on CAS for financial information formed another. In this
way agencies could hear from agencies with comparable environments, and the
project team could compare needs across environment to determine any similari-
ties and differences. We planned a total of 13 workshops. The first workshop we
saw as a pilot for testing the whole approach (defining the first sub-cycle). We
assumed that the evaluation and learning of the first sub-cycle would lead us to
certain modifications of the design of the other 12 workshops to be held in the
second sub-cycle.
As researchers we knew that deciding what to ask of stakeholders is often
and surprisingly one of the most quickly taken shortcuts to misrepresentation.
Some practitioner members of the team made statements such as ‘we aren’t going
to let them say whatever they want, are we?’ and, ‘we can’t just leave it up to
them to decide what to talk about!’ It was in the area of elicitation question
development that the team encountered its first situation of distress. However, it
was also during this phase of the effort that the team, including the skeptics, illus-
trated their commitment to a full and comprehensive stakeholder analysis. The
early discussions around the elicitation questions were a volley between the
broader, complete-the-sentence-type questions and very specific questions about
problems with the current system or specific function-related questions. These
narrower and more directed questions reflected the comfort zone of most OSC
practitioners. They were experts in the CAS, and they wanted questions to be
framed in the context of CAS. Further, inside OSC, there was a lengthy discussion
about whether the effort should talk specifically about an ‘accounting system’ or
more generally about accounting procedures and the management of financial
information. The OSC practitioners had a high comfort level with their view of
the CAS as a bulk accounts processing machine and not as a financial manage-
ment tool and information resource. They tended to favor more focused features-
and-functionality discussions with stakeholders, while we researchers favored a
more open-ended approach. The primary stakeholders finally influenced and
informed the elicitation questions, which reflected a compromise of approach.
The question asked participants to think in terms of an overall ideal design, but
focused specifically on an ideal design for an ‘accounting system’. As a result,
each of the over 200 participants in the 13 workshops conducted was asked to
answer two broad ‘complete-the-sentence’ questions:
An accounting system designed to meet the informational and information access
needs for my agency would ideally . . .
An accounting system designed to meet the transactional needs for my agency would
ideally . . .
 Scholl Involving salient stakeholders • 293

Second cycle: action taking

We sent invitations to the senior management level of 41 BIG agencies and 10

non-governmental entities. The organizational turnout was 98.1 percent, indi-
cating a very strong interest in the subject matter. Of the 202 participants who
attended the 13 workshops, 191 were from 41 BIG agencies and 11 were from 10
non-governmental organizations.
We conducted the 13 workshops within a three month period generating
more than 1100 individual proposals of varying specificity for enhancement and
extension of the Central Accounting System. With only facilitative guidance the
workshop participants themselves grouped their proposals into clusters of similar
ideas. They also gave the clusters descriptive names. Finally, the workshop par-
ticipants ranked the clusters in order of importance.

Second cycle: evaluation

The data analysis focused on the clusters and the participant-defined rankings
rather than the frequencies of similar individual proposals. In the analysis, we
finally consolidated the top five clusters for both transactional and informational
needs generated in each workshop into six ‘dominant themes’.
Data access and manipulation capabilities emerged as a high priority item
in every workshop; real time workflow support, improvement in basic financial
processes, support for e-business, and better usability were high priority themes
in half to two thirds of the workshops. Consistency across related systems was a
top theme in about one quarter to one third. These very strong findings laid the
groundwork for recommended action steps.
Inasmuch as these findings highlighted the main functional requirements
and characteristics of a next generation accounting system, they also confirmed
the deficiencies of the existing CAS, particularly, in the areas of ease of use, user
interface, data and application integration, and ad hoc query functionality.

Second cycle: specifying learning

Between the first and second sub-cycle, that is, between the pilot workshop and
the 12 subsequent workshops, the wording of the sentence to be completed in the
facilitated workshops was slightly changed, sharpening the distinction between
‘transactional’ and ‘informational/analytical’ needs. The secondary stakeholders
clearly articulated their need for data access and manipulation for both informa-
tional and transactional uses. Automated workflow support, improvement in
basic financial processes, support for electronic business, improved usability, and
consistency within and across related systems were next ranking priority needs in
secondary stakeholder views (see Table 2).
294 • Action Research 2(3)

Table 2 Dominant themes from CAS stakeholder needs workshops

Informational use Transactional use

Number of Number of
workshops in workshops in
which this which this
theme was theme was
represented represented
in the top in the top
Theme five clusters Percent five clusters Percent

1 Data access and

manipulation capability 13 100% 13 100%
2 Automated workflow support 8 62% 9 69%
3 Improvement in basic
financial processes 8 62% 7 54%
4 Support for electronic
business 6 46% 8 62%
5 Usability 7 54% 6 46%
6 Consistency within and
across related systems 3 23% 4 31%

The overall findings of the stakeholder needs analysis came as no surprise

to the majority of the OSC practitioners even though a number of details were
seen as new, unique, and original. Not surprisingly, some OSC practitioners
found the role and importance of the social process dimension of the massive
stakeholder involvement hard to understand in light of an estimated 80 percent
confirmation level of the assumed needs that these very same OSC experts had
identified up front. This suggested an implicit questioning of the usefulness of the
sumptuous needs analysis approach. In our internal discussion with the OSC
practitioners, we contrasted the functional/technical aspects of the overhaul and
redesign project with the social process elements. Stakeholder inclusion, we
argued, had not only the merits of more fully eliciting the functional requirements
of the changed business processes and their supporting IS but also of fostering a
smoother process of change that provides the non-technical underpinnings of the
overall change effort. For an illustrative account for how well the inclusive social
process unfolded please see Appendix 2 (we used at least one non-participant
observer per workshop to capture dialogues and discussions as well as non-verbal
communication during the workshops).
While a majority of OSC practitioners acknowledged their growing under-
standing and appreciation of the indivisibility of functional/technical-to-social-
process relationship, a minority of team members from OSC still remained
unimpressed, if not unconvinced. These members also based their argument on
the notion that OSC commanded the statutory powers to impose any technical
 Scholl Involving salient stakeholders • 295

changes to CAS as necessary and desired. These members hence indicated con-
cerns that inclusive social processes ‘could take too long without ever delivering
an acceptable and implementable system’. Even accounts of reported covert user
recalcitrance when systems were imposed (Howcroft & Wilson, 1999) would not
change these practitioners’ perspective. We observed a clear tension between
these practitioners’ desire to advance in functional/technical terms and to honor
the requirements of an agreeable sociopolitical process.
OSC leadership was very cognizant of the new role of primary stakeholders
and of the criticality of their comfort that the conclusions from this analysis
would truly reflect the needs as identified by stakeholders. The workshop par-
ticipants asked both the OSC practitioners and us as researchers a number of
times throughout the workshops whether the ‘RFP wasn’t really already written
for the new CAS’. Participants were skeptical that in fact OSC was actually col-
lecting information from stakeholders that would then be used in formulating a
plan for the replacement CAS without further stakeholder involvement.
The effect of this regularly voiced concern was notable. The OSC staff
developed an early and strong commitment to the development of a plan that was
fully and soundly based on stakeholder feedback. OSC invested heavily in a series
of presentations on the findings and the resulting plan. These presentations
shared data summaries and the plan and provided both OSC colleagues, as well
as strategic partners, the opportunity to question and comment on the process
and the outcome.
At the end of the workshop series, the team revisited its initial hopes and
fears, one by one. Overall, the practitioners said that they were happy with the
process and its outcomes. In particular, they were relieved that the workshops
showed no stakeholder skepticism, but rather a willingness to progress and
change the CAS. However, some OSC members were worried that participants
may have left the workshops with the impression that a ‘new CAS’ was coming,
while OSC wanted to keep open the option of maintaining the old CAS. The
practitioners were particularly happy with the high turnout at the workshops.
However, they said they would have liked to contact the participants individually
in advance explaining the workshop process, in order to elicit even more infor-
mation. Most workshop participants had indicated their willingness to further
contribute to the process. Except for one important stakeholder (the senate
majority) the team felt that all primary and secondary stakeholders had been
correctly identified. The team members also found that participants had got value
from the process by first, meeting peers from other agencies, second, understand-
ing the idea behind the change process, and third, being able to influence the out-
comes. The OSC practitioners, although 80 percent of the stakeholder needs
may have been known without asking, maintained that OSC had learned much
more in terms of stakeholder needs and expectation than anticipated and were
happy with the process and its results. The practitioners also pointed out that
296 • Action Research 2(3)

understanding the inclusive action/inquiry process and its techniques was an

invaluable expansion of knowledge and skills for the remainder of the project.
From my hindsight perspective, I feel the process we had proposed and
implemented with the OSC practitioners had worked better than expected:

1 it developed and strengthened relationships within the team;

2 it established trust and paved the path for participation and collaboration
with primary and secondary stakeholders for the future stages of the project;
3 it produced a plethora of stakeholder-validated information;
4 it demonstrated that certain degrees of consensus regarding process and
expected outcomes are sufficient to find overall stakeholder acceptance in an
environment of distributed powers; and
5 it showed that stakeholder accepted and expected OSC to take and maintain
the lead in the project.

In other words, stakeholders seemed comfortable with an alignment and conver-

gence towards a common goal at the expense of certain individual expectations
and needs. For the internal processes of the joint team, I would prefer a more
open and less chary exchange on issues with a high potential for conflict. For
example, some practitioners yearned to short cut the social process for fear of
losing control or not being able to complete the functional CAS overhaul in due
time and within the budgetary cycles. By suppressing the conflict, the practi-
tioners unfortunately remained unconvinced of the value of such a ‘lengthy’ and
‘costly’ process. It may have been worth the effort of exploring (via interviewing
and written accounts) the lessons learned from the earlier payroll system disaster.
OSC leadership asked the Center researchers to prepare a report on the
findings of the first two cycles and present those back to the primary stakeholders
and other BIG State officials. Prior to moving forward with the implementation
of any next generation accounting system for the state, the report concluded that
OSC should follow the next stage in the theoretical framework and learn more
about the fragmentation in existing business processes and standards. As the
report states, this fragmentation has ‘resulted in the unnecessary complexity that
prohibits the kind of querying and use that agencies need to make of their data’.
The recommendation called for a comprehensive effort that would begin with a
pre-study of the eleven financial management processes and of current and best
practice in other states. Senior management levels at OSC and the primary stake-
holders stated their support for the systematic approach as outlined in the BPC
framework and as recommended by the Center researchers. Consequently, the
funding necessary to begin the next phase became available almost immediately
and in the full amount requested.
 Scholl Involving salient stakeholders • 297

Contextualization

OSC’s CAS-related BPC strategy initially sought to address the social and behav-
ioral as well as the technical elements of BPC. Continuing to fully involve stake-
holders, keeping strategic partners informed, exploring and documenting work
processes and organizational conditions that influence work and continually
adapting to new information is a challenge in any effort, but was particularly so
here. The organization was used to brief analysis and quick moves to conclusions
and build-or-buy decisions. Sticking to any prescriptive framework in the first
two stages, therefore, despite strong pressures to skip at least portions of those
elaborate exercises, was a notable new behavior. Agency management and staff
spoke directly to the benefit of the approach in terms of building their under-
standing of the involved players, their roles, their likely behaviors and stance, and
their expectations regarding the CAS-related BPC project. They recognized that
this critical depth of understanding and appreciation for stakeholders and their
needs did not exist in other efforts. They directly related the failure of other
projects, some of which were quarter billion dollar disasters, to not understand-
ing salient stakeholder roles and needs.
Beyond the reach of a traditional socio-technical analysis, the analysis of
both internal and external stakeholders allowed for the identification, involve-
ment, and management of salient, project related constituents who would
otherwise have been missed and who might have impeded, if not stopped, the
whole BPC project. Otherwise, the salience of such needs might have passed
unattended. Hence, the first two BPC framework stages contributed significantly
to the project managers’ focus on those who ‘really count’ as well as the needs,
which ‘really count’ (Mitchell et al., 1997).
The early strategy based on the framework called for a three year timeline
prior to a build-or-buy decision. The agency supported this strategy, presented it
as its own, and invested in it. However, the pressures to move to conclusions, the
discomfort with lengthy analysis, with the burden of external participation and
with the attraction of being committed to an approach may have been greater
than the team could bear. Whether the agency is able to avoid skipping this stage
will become evident over the next stages of the project.
For this part, though, the framework provided a roadmap for:

1 identifying stakeholders (grouped into classes of salience);

2 understanding their likely stance towards the project (present and over time);
3 comprehensively eliciting their needs and wants in a ranked fashion;
4 paving the path for stakeholders’ buy-in to the project by means of an inclu-
sive institutional and social process; the framework then also supported the
identification and detailed description of business processes and the discovery
of their homogeneity (which was unanticipated).
298 • Action Research 2(3)

On this basis, the framework provided a clear and logical guide for systematically
involving constituents and addressing their needs in an ongoing fashion rather
than eliciting requirements once, then focusing on technical issues alone. It served
to link technical issues to organizational and social implementation issues.
The researchers anticipated pressures for leaving the prescriptive frame-
work and observed repeatedly that the practitioners had a tendency ‘to get the
job done’ sooner rather than later, even if the decision relevant information was
dangerously incomplete or massively contradictory, or even more importantly,
stakeholder involvement had not been secured for establishing an inclusive
process. Even past experience to the contrary did little to sway them. As early as
the first cycle, some practitioners questioned the usefulness of an elaborate stake-
holder analysis. In particular, the ‘CAS pundits’ did not believe in the benefit of
this exercise. They were also sure that they had already captured and had been
aware of the real needs of CAS users. When both the stakeholder and the stake-
holder needs analysis proved differently, the willingness to follow through with
the framework increased for a while. In the project debriefing session, all practi-
tioners acknowledged that they had never had such a clear picture of CAS-
related stakeholders and their detailed wants and needs before the completion of
the first two cycles. They clearly valued this broader base of information about
processes; however, they had greater difficulty seeing the value of stakeholder
involvement from a social process standpoint. It may be precisely in this area
where the framework (and the BPC literature in general) must still seek deeper
understanding.
Throughout the meetings and workshops, primary and secondary stake-
holders continued to express their delight at being involved and asked for their
needs and their inputs. Some (though not all) of the OSC practitioners clearly
noticed the positive change in stakeholder reactions. In Bradbury and Reason’s
words, there were clear signs that both OSC practitioners and CAS stakeholders
‘were energized and empowered by being involved’ (Bradbury & Reason, 2001,
p. 448).
The identification of not just (equidistant) stakeholders but salient stake-
holders and their specific needs may be informative to other projects of this kind
and scope. Also, external pressures on joint project teams as well as hierarchical
relationships of team members outside the project can exert a major influence on
long-term action research projects. Finally, as Orlikowski outlines on the basis of
Giddens’s structuration theory, institutional and social conditions are not only
facilitated and constrained by technology, but technology use is shaped by those
conditions (Giddens, 1984; Orlikowski, 1992). DeSanctis and Poole even speak
of a ‘recursive relationship between technology and action, each iteratively
shaping each other’ (deSanctis & Poole, 1994, p. 125). In this regard Orlikowski
argues in favor of involving users in designing and testing technology for the
benefit of its higher acceptance and flexibility of use. Since technology use
 Scholl Involving salient stakeholders • 299

changes through human action, it both indicates and induces institutional change.
With Tsoukas and Chia one can argue that technology related changes represent
a special form of organizing human action, a ‘patterned unfolding of human
action’ (Tsoukas & Chia, 2002, p. 577) moderated by a social process.
This article contributes to the action research methodology in that it finds a
participatory approach is applicable even in inter-organizational contexts over
longer periods of time. Further, it illustrates the use of the concept of salience,
which helps facilitate the involvement and inclusion of large numbers of stake-
holders in participatory approaches. Finally, it gives an account for the willing-
ness of salient stakeholders in environments of distributed powers to accept
‘satisficing’ processes and outcomes, as long as stakeholders feel meaningfully
involved in generating those processes and outcomes.
Critically reflecting on my own learning, in future projects I will pay more
attention once team members raise important concerns even if those concerns
are driven from a narrow technical perspective. Such concerns cannot remain
unaddressed. Glossing over them, in essence, is little different from the myopic
stricture on technical validity in IS projects so much criticized in this article, since
it stresses team members’ relationship and capacity to collaborate.

Appendix 1 Author notes from an early project stage

August 16
I have never worked in a large project involving such a large and diverse constituency.
Bill (name changed – director of State Accounting Systems) mentioned that the
statewide accounting system was currently used by over 90 agencies and the number
of private sector vendors may be in the lower hundreds. So, we are talking about some
2000 daily users and some 20 million transactions annually!
The transaction aspect, however, is only one area of interest to those con-
stituents. The various users have very different analysis- and information-related
needs, both of which are largely based on the transactional data.
From what the OSC people tell us it seems that the current mainframe-based
system will not be appropriate for serving the State’s growing needs for another 20
years. The Y2K-related overhaul has already shown major gaps and inconsistencies in
functionality. The user interface is just horrible under today’s standards. So, that
means a new system of gigantic proportions!
I wonder whether we can envision and launch a process which involves all those
people who need to have a say in this. This is going to be a multi-year undertaking.
First, we need to establish a level playing field for both the OSC people and us (the
CENTER researchers in the joint project team). We all need to share what we know.
Then we need to see how we involve and engage those diverse groups. Plus, there is
this political, budget-related dimension, which I have no clue about how that is going
to interfere.
I am nervous that we might lose track or commitment to the inclusive approach
300 • Action Research 2(3)

over time, which I believe is critically important for arriving at a new organizational
quality in accounting and financial management. In my career I have seen so many
organization change projects, system introductions, and overhauls fail. All focused on
the technology and the functionality in a technical sense, not on the overall process,
mostly neglecting the different stakes people have. I am expecting pressures from
various sides including from OSC itself (‘let’s get the job done, for God’s sake’).
The good thing is that they burnt their fingers big time with a coercive, technical
approach a few years ago with the payroll system. So, they know the pitfalls and are
sensitized.

Appendix 2 Sample workshop recorder notes

Recorder notes for stakeholders needs analysis workshop

Date: February 11
Location: Meeting Room 2
Group: Statewide Analytical
Facilitator: DC
Co-Facilitator: DF
Recorder: DH

Question #1 – Informational

Group was anxious to get ideas on the wall. Willing to cluster. Group continued to
add ideas during clustering.
A discussion occurred on the differences between ‘user friendly’, ‘flexibility’, and ‘ease
of use’.
There was a relatively long discussion on ‘data capture’ issues in the reporting
category. The joint team needs to understand that some ideas are meant to tell us to
begin capturing information that we currently don’t, that is, bargaining unit, final
recipient of payments made through AMEX.
All participants were very involved. Key theme is: They want to use the data them-
selves. At several points, multiple conversations were occurring. Consistency across
agencies was important they said.

1. CLUSTERS
Ease of use 1
Flexible access to data (download) 1
Access 4
Flexible reporting 13
Training (overall system capability) 2
Flexibility 5
Interface – user friendly 6
Corporate tax refund system 1

Question #2 – Transactional

Slightly less involvement from fewer participants. Most of the group is not involved
in day-to-day transactions.
 Scholl Involving salient stakeholders • 301

More interest in what is in the system. Participant from OGS was reviewing what
appeared to be a credit card statement. One participant wanted to know if we were
surprised by the results from today and all workshops.

2. CLUSTERS
Electronic relationships 3
Flexibility 3
Consistency 5
Seamless process (reduce paper/work) 10
New stuff (more detail/new data elements) 7
User friendly 4
Training 1

References

Andersen, D. F., & Richardson, G. P. (1997). Scripts for group model building.
System Dynamics Review, 13(2), 107–129.
Baskerville, R. L., & Pries-Heje, J. (1999). Grounded action research: a method for
understanding IT in practice. Accounting, Management, and Information
Technologies, 9(19), 1–23.
Baskerville, R. L., & Wood-Harper, T. (1996). A critical perspective on action
research as a method for information systems research. Journal of Information
Technology, 11(4), 235–246.
Blair, D. L., & Whitehead, C. J. (1988). Too many on the seesaw. Stakeholder diag-
nosis and management for hospitals. Hospital and Health Administration,
33(2), 153–166.
Boehm, B. (1988). A spiral model of software development and enhancement. IEEE
Computer, 21(5), 61–72.
Boehm, B. W. (1981). Software engineering economics. Englewood Cliffs, NJ:
Prentice-Hall.
Bradbury, H., & Reason, P. (2001). Conclusion: Broadening the bandwidth of valid-
ity: Issues and choice-point for improving the quality of action research. In P.
Reason & H. Bradbury (Eds.), Handbook of action research: participative
inquiry and practice (pp. 447–455). London/Thousand Oaks, CA: Sage.
Bravo, E. (1993). The hazards of leaving out the users. In D. Schuler & A. Namioka
(Eds.), Participatory design: principles and practices (pp. 3–11). Hillsdale, NJ:
Lawrence Erlbaum Associates.
Cavaye, A. L. M. (1995). User participation in system development revisited.
Information & Management, 28(5), 311–323.
Champy, J. (1995). Reengineering management: the mandate for new leadership (1st
ed.). New York: HarperBusiness.
Checkland, P. (1981). Systems thinking, systems practice. Chichester/New York: J.
Wiley.
Checkland, P., & Scholes, J. (1990). Soft systems methodology in action.
Chichester/New York: Wiley.
Clarkson, M. (1994, May). A risk based model of stakeholder theory. Paper present-
ed at the Proceedings of the second Toronto conference on stakeholder theory,
Toronto.
302 • Action Research 2(3)

Cummings, J. L., & Doh, J. P. (2000). Identifying who matters: Mapping key players
in multiple environments. California Management Review, 42(2), 83–104.
DeLone, W. H., & McLean, E. R. (1992). Information systems success: The quest for
the dependent variable. Information Systems Research, 3(1), 60–95.
Denzin, N. K., & Lincoln, Y. S. (2000). Handbook of qualitative research (2nd ed.).
Thousand Oaks, CA: Sage.
deSanctis, G., & Poole, M. S. (1994). Capturing the complexity in advance tech-
nology use: Adaptive structuration theory. Organization Science, 5(2), 121–
147.
Ehn, P. (1989). Work-oriented design of computer artifacts. Hillsdale, NJ: Lawrence
Erlbaum Associates.
Ehn, P. (1993). Scandinavian design: On participation and skill. In D. Schuler & A.
Namioka (Eds.), Participatory design: principles and practices (pp. 41–77).
Hillsdale, NJ: Lawrence Erlbaum Associates.
Fallding, H. (1990). The social process revisited: achieving human interests through
alliance and opposition. New York: P. Lang.
Freeman, R. E. (1983). Strategic management: a stakeholder approach. In R. Lamb
(Ed.), Advances in strategic management (pp. 31–60). Greenwich, CT: JAI.
Freeman, R. E. (1984). Strategic management: A stakeholder approach. Boston, MA:
Pitman.
Friedman, V. J. (2001). Action science: Creating communities of inquiry in communi-
ties of practice. In P. Reason & H. Bradbury (Eds.), Handbook of action
research: Participative inquiry and practice (pp. 159–170). London/Thousand
Oaks, CA: Sage.
Giddens, A. (1984). The constitution of society: Outline of the theory of structura-
tion. Berkeley: University of California Press.
Hammer, M. (1996). Beyond reengineering: How the process-centered organization is
changing our work and our lives. New York: HarperBusiness.
Hammer, M., & Champy, J. (1993). Reengineering the corporation: A manifesto for
business revolution. New York: HarperBusiness.
Heron, J., & Reason, P. (2001). The practice of co-operative inquiry: Research ‘with’
rather than ‘on’ people. In P. Reason & H. Bradbury (Eds.), Handbook of
action research: Participative inquiry and practice (pp. 179–188). London/
Thousand Oaks, CA: Sage.
Hirschheim, R. A. (1985). Office automation: A social and organizational perspec-
tive. Chichester/New York: Wiley.
Hirschheim, R. A., & Klein, H. K. (1989). Four paradigms of information systems
development. Communications of the ACM, 32(10), 1199–1216.
Holwell, S. (2000). Soft systems methodology: Other voices. Systemic Practice and
Action Research, 13(6), 773–797.
Howcroft, D., & Wilson, M. (1999, July). Paradoxes of participatory design: The
end-user perspective. Paper presented at the Critical Management Studies
Conference, Manchester, UK.
Kemmis, S., & McTaggart, R. (1988). Action research planner (3rd ed.). Geelong,
Victoria, Australia: Deakin University.
Kettinger, W. J., Teng, J. T. C., & Guha, S. (1997). Business process change: A study
of methodologies, techniques, and tools. MIS Quarterly, 21(1), 55–80.
Lyytinen, K. (1987). Different perspectives on information systems: Problems and
solutions. ACM Computing Surveys, 19(1), 5–46.
 Scholl Involving salient stakeholders • 303

Lyytinen, K., & Hirschheim, R. A. (1987). Information systems failures – A survey

and classification of the empirical literature. Oxford Surveys in Information
Technology, 4, 257–309.
March, J. G., & Simon, H. A. (1958). Organizations. New York: Wiley.
Mathiassen, L., & Stage, J. (1992). The principle of limited reduction in software
design. Information, Technology, & People, 6(2/3), 171–185.
McDonagh, J., & Coghlan, D. (2001). The art of clinical inquiry in information-relat-
ed change. In P. Reason & H. Bradbury (Eds.), Handbook of action research:
Participative inquiry and practice (pp. 372–378). London/ Thousand Oaks,
CA: Sage.
Mingers, J., & Taylor, S. (1992). The use of soft systems methodology in practice. The
Journal of Operational Research Society, 43(4), 321–332.
Mitchell, R. K., Agle, B. R., & Wood, D. J. (1997). Toward a theory of stakeholder
identification and salience. Defining the principle of who and what really
counts. Academy of Management Review, 22(4), 853–866.
Mitroff, I. I. (1983). Stakeholders of the organizational mind (1st ed.). San Francisco,
CA: Jossey-Bass.
Mumford, E. (1983). Designing human systems for new technology: The ETHICS
method. Manchester: Manchester Business School.
Mumford, E. (1987). Sociotechnical system design – Evolving theory and practice. In
G. Bjerknes, P. Ehn & M. Kyng (Eds.), Computers and democracy – A
Scandinavian challenge (pp. 59–76). Aldershot: Avebury.
Mumford, E. (1993). The participation of users in systems design: An account of the
origin, evolution, and use of the ETHICS method. In D. Schuler & A. Namioka
(Eds.), Participatory design: Principles and practices (pp. 257–270). Hillsdale,
NJ: Lawrence Erlbaum Associates.
Newman, M., & Robey, D. (1992). A social process model of user–analyst relation-
ships. MIS Quarterly, 16(2), 249–266.
Orlikowski, W. J. (1992). The duality of technology: Rethinking the concept of tech-
nology in organizations. Organization Science, 3(3), 398–427.
Rainey, H., Backoff, R., & Levine, C. (1976). Comparing public and private organi-
zations. Public Administration Review, 36(2), 233–244.
Robey, D., & Newman, M. (1996). Sequential patterns in information systems devel-
opment: An application of a social process model. ACM Transactions on
Information Systems, 14(1), 30–63.
Scholl, H. J. J. (2001, October). Applying stakeholder theory to e-government: bene-
fits and limits. Paper presented at the 1st IFIP Conference on E-Commerce, E-
Business, and E-Government (I3E 2001), Zurich, Switzerland.
Spear, R. (2001). The dark side of the moon: Unilluminated dimensions of systems
practice. Systemic Practice and Action Research, 14(6), 779–790.
Stringer, E. T. (1999). Action research (2nd ed.). Thousand Oaks, CA: Sage.
Sussman, G. (1983). Action research: A sociotechnical systems perspective. In G.
Morgan (Ed.), Beyond method: Strategies for social research (pp. 95–113).
Beverly Hills, CA: Sage.
Teng, J. T. C., Jeong, S. R., & Grover, V. (1998). Profiling successful reengineering
projects. Communications of the ACM, 41(6), 96–102.
Tennert, J. R., & Schroeder, A. D. (1999, April). Stakeholder analysis. Paper present-
ed at the 60th Annual Meeting of the American Society for Public Adminis-
tration, Orlando, Florida.
304 • Action Research 2(3)

Torbert, W. R. (1999). The distinctive questions developmental action inquiry asks.

Management Learning, 30(2), 189–206.
Torbert, W. R. (2001). The practice of action Inquiry. In P. Reason & H. Bradbury
(Eds.), Handbook of action research: Participative inquiry and practice (pp.
250–260). London/Thousand Oaks, CA: Sage.
Tsoukas, H., & Chia, R. (2002). On organizational becoming: Rethinking organiza-
tional change. Organization Science, 13(5), 567–582.
Wolfe, R. A., & Putler, D. S. (2002). How tight are the ties that bind stakeholder
groups? Organization Science, 13(1), 64–80.

Hans Jochen Scholl is Assistant Professor at the University of Washington. He

earned a PhD in Information Science from the University at Albany and a MBA from
the GSBA Zurich, Switzerland. Previously, Jochen was a researcher at the Center for
Technology in Government at Albany, NY. Address: University of Washington, The
Information School, Box 352840, Seattle, WA, 98195-2840, USA.
[Email: [email protected]]

View publication stats