Content uploaded by Richard T. Watson
Author content
All content in this area was uploaded by Richard T. Watson on Jul 21, 2015
Content may be subject to copyright.
63
INFORMATION SYSTEMS MANAGEMENT
SUMMER 1999
MANAGING THE
THREE LEVELS OF
CHANGE
Margaret T. O’Hara, Richard T. Watson, and C. Bruce Kavan
Change may be introduced into an organization a variety of ways — implement-
ing new technology, employing new people, or in establishing new organiza-
tional structures, new policies, or new procedures. Just as change is made up
of different components, it comes in varying degrees. A three-level classifica-
tion of change can help IS managers gain control over the variable components
and nature of change.
RGANIZATIONAL CHANGE AS IT
relates to information technology (IT)
has been the subject of several studies
since 1958, when Leavitt and Whisler,
who first used the label information technology,
predicted dramatic organizational changes as a
result of IT. Forty years later, the exact nature of
the relationship between IT and organizational
change is still neither well-understood nor well-
managed. Poorly managed technology imple-
mentation may result in only minimal benefits
being realized.14
Although some studies have examined the
impact of technology on organizations, few
have explored the relationship between tech-
nology and the magnitude of change. All new
information technologies cause change within
organizations; the magnitude of change varies
depending upon the technology introduced and
the goals for the technology. Some technolo-
gies, because of their complexity, are more
likely to cause higher levels of change. Cli-
ent/server technology implementations, for
example, can vary from very simple to
extremely complex. Consequently, client/server
technology makes an excellent focal point of
analysis to examine organizational change.
Client/server technology divides comput-
ing resources between a central processor (the
server) and desktop PCs (the clients). An oft-
cited reason for employing this technology is
its flexibility. Applications developed using
client/server may be configured in a variety of
ways, each one providing the users with a dif-
ferent access to information. Some cli-
ent/server configurations closely resemble
their mainframe predecessors; others are a
radical departure from menu-driven systems.
For many organizations, the move from the
mainframe legacy system to client/server tech-
nology represents a major change. For some
firms, it is the greatest change in computing
since they adopted mainframes more than 30
years ago.
Any new technology will be accompanied by
some change. Thus, the conclusions drawn con-
cerning client/server technology may be applied
to the implementation of any new technology.
In ever-increasing numbers, businesses are
turning to IT to provide either the means or
the support for achieving and maintaining sus-
tainable competitive advantage.4,8,11 Often, to
obtain competitive advantage and respond to
their rapidly changing environments, busi-
nesses embrace new technologies without a
complete analysis of their organizational
impact, and they unleash unknown and possi-
bly unanticipated problems.
O
MARGARET
O’HARA is an assis-
tant professor of CIS at
Columbus State Uni-
versity in Columbus,
GA.
RICHARD WATSON
is a professor in the
Department of Man-
agement at the Univer-
sity of Georgia in
Athens.
C. BRUCE KAVAN is
the NationsBank Pro-
fessor of Information
Technology at the Uni-
versity of North Florida
in Jacksonville.
Downloaded by [University of Georgia] at 05:33 21 February 2013
64 INFORMATION SYSTEMS MANAGEMENT
SUMMER 1999
MANAGING THE THREE LEVELS OF CHANGE
THE SOCIO-TECHNICAL SYSTEM
PERSPECTIVE
One way to understand the complex interaction
between technology and people within an orga-
nization is to consider the organization as a
socio-technical system (STS) in which organiza-
tions are viewed as the interaction of four highly
interrelated variables: task, people, structure (or
roles), and technology. The STS model is based
on the fundamental concepts of general systems
theory.15 Every organization may be thought of
as a collection of interrelated parts working
together toward a common goal. There are two
primary systems in the organization: the social
system and the technical system. These systems
are interdependent; what affects one affects the
other.
People perform tasks; these tasks produce the
organization’s goods and services. Structure
results from the communications, authority, and
workflow systems that operate within the orga-
nization. Technology refers to any direct prob-
lem-solving intervention, such as a computer.
The technical system includes the technology
and the tasks performed to achieve organiza-
tional goals. Although the same type of technol-
ogy may be present in many organizations, the
technical system will be different within each
organization. This is because the technical sys-
tem is the result of implementing the technology,
and the implementation choices are manifold.
People and the roles they assume comprise
the social system. Thus, the attributes of people
(attitudes, skills, and values), and the commu-
nications, authority and workflow systems
within the organization are among the concerns
of the social system.1 Multiple subsystems com-
prise the main social system; each department
may form a unique social subsystem, or sub-
systems may form based on more temporary
divisions. Exhibit 1 offers a graphical represen-
tation of the STS model.
CASE STUDIES
Extending the STS model to include a focus on
organizational change, we now introduce three
orders of change observed in our case studies.
Each order of change is specifically linked to a
component of the STS model. First-order
change involves only task accomplishment. It
occurs, for example, when a task is automated
in some fashion. Second-order change occurs
when the tasks and the people who perform
them are affected. An example would be the
introduction of word processing, which
changed the nature of many jobs. Third-order
change affects task, people, and organizational
structure. Reengineering both management
structures and workflow is a good example of
third-order change. Each order of change is
examined in detail in the cases reported within
this article.
Interviews were conducted with multiple cli-
ent/server implementation teams over a 12-
month period. An iterative process of within-
and cross-case analysis was employed to analyze
the data.2,7,9,16 This process consists of data
reduction, analysis of data displays, and conclu-
sion drawing and verifying. Although conclusion
drawing and verifying took place throughout the
analysis process, the activity reached a final stage
only after all data was collected, reduced, and
analyzed.
Although many client/server implementa-
tions were evaluated as part of a broader study,
only three cases are discussed, one to exemplify
each specific order of change. The broader
study findings, however, were very consistent
with the cases chosen to illustrate each particu-
lar concept.
First-Order Change
In the first case, an international cable manu-
facturer developed a client/server application to
replace a label printing process in which each
plant used a single non-networked PC to print
customer labels for product shipment. These
labels often contained outdated information,
since updates were infrequent and inconsistent.
The client/server implementation provided
plants with multiple PCs linked to one another
and to a central repository of data. Customer
data on the local servers was updated nightly
from the repository at the corporate office,
resulting in a more reliable label for this mission-
EXHIBIT 1 The STS Model
Downloaded by [University of Georgia] at 05:33 21 February 2013
65
INFORMATION SYSTEMS MANAGEMENT
SUMMER 1999
MANAGING THE THREE LEVELS OF CHANGE
critical process. Accurate address labels were crit-
ical to timely delivery of product to customers.
The new label printing system did not
change the manner in which work was accom-
plished from a people perspective; it simply
enhanced the label-printing task. Jobs were not
affected. Consequently, this project illustrates a
first-order change. This level of change is easy
to understand and plan. The consequences are
rarely unanticipated or disruptive.
The development team for this project was
small yet fluid — it consisted of three perma-
nent members and many temporary members.
The project was the development team’s first
venture into client/server technology. At various
times during the project, users from different
functional areas and representatives from the
plants were brought onboard to assess progress,
provide guidance, and specify requirements.
Although this project was limited in scope, the
project manager nonetheless felt it was very dif-
ficult to manage because of the changing nature
of the project team and the learning process
necessary to exploit the new technology.
First-order change is highlighted in the STS
model by an interaction arrow between tech-
nology and task. This represents alpha change
(α), the lowest order of organizational change
that may result from technology implementa-
tions (see Exhibit 2).
Second-Order Change
The second case concerns the standardization
of an application across various subsidiaries of a
major utility. Each of the organization’s 17 sub-
sidiaries used a different system to capture pay-
roll information. The systems ranged from
manual to fully automated. The client/server
replacement application represented the first
common system to be developed for use by all
subsidiaries. It altered both the method of task
accomplishment as well as people’s roles (jobs).
Thus, a second-order change took place. Sec-
ond-order change “replaces the status quo with
a new way of doing things”.3
The two interaction arrows: (1) tasks and
people and (2) people and technology in
Exhibit 3 represent second-order or beta change
(β) resulting from the technology implementa-
tion. Moving clockwise through the model from
technology to task, the technology altered the
method of task accomplishment (time account-
ing). However, not only was the method of task
accomplishment altered (a), but so were the
procedures. It was not a simple technology sub-
stitution such as in the first case study. The
dynamic represented by the arrow between task
and people is the changing roles or procedures
that affected the method of task accomplish-
ment. Not only are the procedures changed, but
the manner in which people interact with the
technology is also altered. This dynamic is
reflected in the arrow between people and tech-
nology. When both roles (people and task
accomplishment) and the method of task
accomplishment (people and technology) are
altered, this is second-order or beta (β) change.
Third-Order Change
The final case is represented by a major finan-
cial institution with 12 regional offices, each
using different information systems. Regional
offices operated autonomously with informa-
tion systems developed by one region that were
sometimes available for internal sale to the
other regions. The regional office examined in
EXHIBIT 2 First-Order Change
EXHIBIT 3 Second-Order Change
Downloaded by [University of Georgia] at 05:33 21 February 2013
66 INFORMATION SYSTEMS MANAGEMENT
SUMMER 1999
MANAGING THE THREE LEVELS OF CHANGE
this study had developed two previous cli-
ent/server applications — one of which was
later marketed to other regions. The purchasing
and payables system in this case was also sched-
uled to be marketed to the other offices.
The client/server application system affected
more than 1200 people, and it was used by every
department within a single region. Although cli-
ent/server technology was not new to the devel-
opment team, the project experienced many
difficulties. It involved many different func-
tional areas with an IS staff that was not pre-
pared for such extensive business involvement.
Many of the development team members lacked
understanding of the functional user areas (i.e.,
business knowledge) and were not completely
comfortable with client/server technology, nor
were they rigorous in their approach to develop-
ment and project management.
Both the original IS project manager and
business project manager left the regional office
before the project was completed, and the new
project managers held very different beliefs
about the IS staff and users. All four managers
were interviewed as part of this research.
The original IS manager believed that the
traditional mainframe development staff could
not make the transition to client/server devel-
opment. Still, he placed them on the project
team with little or no client/server training.
These team members subsequently resigned,
and an entirely new team assumed develop-
ment responsibilities. The new project manager
made certain that the new employees received
adequate training in client/server technology to
ensure a smoother development process.
Changes resulting from this system were
also felt in the user area. The new system
allowed for purchase requisitions to be entered
and approved online at a lower managerial
level. Thus, not only were the purchasing tasks
automated, but the entire management struc-
ture of the firm also changed. As decision-mak-
ing moved farther down the hierarchy, the
structure flattened and the culture of the orga-
nization was adjusted accordingly. Thus, peo-
ple, the tasks they perform, and the
communications, authority, and workflow
structures were all altered.
Finally, because of implementation problems
experienced with this project, changes were
made to the project management structure for
all technology initiatives. The makeup of the
steering committee was changed to include
more users. Accounting areas and IS areas were
placed under the control of a single vice presi-
dent, and new lines of accountability for tech-
nology acquisition were established.
This change is highlighted in Exhibit 4 by
three interaction arrows: (1) people and struc-
ture, (2) structure and task, and (3) structure
and technology. In addition to the beta-level
changes discussed previously, changes afforded
by this implementation
1. flattened the organization decision processes
(people and structure arrow dynamic)
2. changed the manner in which new technol-
ogy was selected and implemented (struc-
ture and technology arrow dynamic)
3. altered the method by which the organiza-
tion would accomplish tasks (structure and
task arrow dynamic).
These changes represents gamma-order
change (γ), the highest order of organizational
change that may result from technology imple-
mentations. The STS model, extended to
include the impact of technologically induced
change, is now renamed the socio-technical
change impact model (SCI).
Change is often unanticipated; however, not
all unanticipated change causes problems.
When task automation is not expected, it is
often still welcomed because tasks are done
faster and presumably more efficiently. Even
beta-level change, which affects task and peo-
ple, may be easily handled, since peoples’ skill
sets may just need updating. It is gamma
change, with its far-reaching effects, that causes
the most trouble when it is not anticipated.
This begs the question: How does a manager
anticipate the level of change that a new tech-
nology will produce?
EXHIBIT 4 Third-Order Change
Downloaded by [University of Georgia] at 05:33 21 February 2013
67
INFORMATION SYSTEMS MANAGEMENT
SUMMER 1999
MANAGING THE THREE LEVELS OF CHANGE
IMPLICATIONS FOR MANAGING
CHANGE
Managers, acting as change agents, can use the
SCI model first to assess the magnitude of
change and then orchestrate an appropriate
response. In this manner, many undesirable
consequences of inadequately planned change
implementations may be eliminated.
Managing Toward the Magnitude
of Change
A close examination of the case data revealed
several references to the complexities associ-
ated with higher-order (beta and gamma)
change. As a result, a set of guidelines related
to change management is presented to assist
managers to achieve the desired results.
Technology implementation projects may
be divided into three categories, as exempli-
fied by the SCI model: those that affect the
tasks that people perform (alpha), those that
affect the tasks and people (beta), and those
that affect the tasks, people, and structure
(gamma) of the organization. For each level of
change, certain factors are critical to a
project’s success. These factors can be consid-
ered dimensions that may be measured along
an alpha to beta to gamma change continuum
as reflected in Exhibit 5.
Project Management Success Factors
Alpha-level change is related to task — it may
simply be replacing one type of technology with
another type and thereby automating the task
without altering employee’s roles or organiza-
tional structure. This is the simplest level of
change and requires a participatory manage-
ment style for the project manager — users par-
ticipate on the team in the selection and
implementation process. When individual roles
are altered, such as in beta change, a facilitating
management style is required. Such a style
encourages the people affected by the change
to identify role changes, redesign their job
descriptions, and bring definition to the new
roles. When the change is gamma-level, the
pertinent management style is empowerment,
which enables people and teams to redesign
both their work roles and the organizational
structure, recognizing that no single person or
group can accomplish this task individually.
As the complexity of the change increases,
both the business acumen and the ratio of
EXHIBIT 5 Dimensions of Successful Change Management
Dimension Alpha Beta Gamma
Project manager:
Management style Participatory Facilitating Empowerment
Business acumen General understanding Recognized specialized
functional
understanding
Recognized superior general
and functional understanding
Technical ability Specialist Generalist Futurist
Project team:
Orientation Technical specialist Training specialist Organizational design specialist
Level of communications •Project status
•Implementation
planning guide
•Project status
•Implementation
planning guide
•Workflow walk-through
•Job behavior changes
defined and reward
structtures altered
•Project status
•Implementation planning
guide
•Workflow walk-through
•Job behavior changes defined
and reward structures altered
•Organizational preparedness
processes
•Early successes publicized
Organization:
Attitude toward change Understanding Enthusiastic Mobilizing
Implementation training •Task Oriented •Task Oriented
•Role Oriented •Task Oriented
•Role Oriented
•Oganizationally oriented
Problem handling Supervisory Middle management Executive
Problem response Immediate Methodical Introspective
Downloaded by [University of Georgia] at 05:33 21 February 2013
68 INFORMATION SYSTEMS MANAGEMENT
SUMMER 1999
MANAGING THE THREE LEVELS OF CHANGE
business understanding to technical under-
standing increases. Only a general business
understanding with a significant technical
specialty is required to manage alpha-level
change, while beta-level change requires
greater business functional area knowledge.
At the gamma level, the manager must not
only have true insight into how the business
works and where it is positioned in the mar-
ketplace, but that manager must also be
clearly recognized within the organization as
having such insight. Only then can the man-
ager truly empower the project team members
and the users.
Project Team Success Factors
Just as the project manager’s management
style must alter within the alpha to gamma
change continuum, so must the nature of the
project team. With lower-order alpha change,
the team members function in the mode of
technical specialists, with an emphasis on the
technology. As there is little impact on the
roles or structure of the organization, there is
little need for the team members to be more
than this. As the complexity increases and
individuals’ roles are altered based on the
planned change, the team needs to incorpo-
rate a significant training component concern-
ing the new method of work accomplishment.
To do this, the team members must have
some experience with training. As change
reaches the highest level of structural change,
the team requires not only technical and train-
ing components but also an organizational
design component. An organizational design
specialist would review and develop the struc-
tures, reporting relationships and reward sys-
tems that affect the people who perform the
work and the roles they assume.
Good communication is critical to the suc-
cess of any project. As the complexity of a
project increases, so does the need for varying
types of communications. At the lower alpha-
level change, simple project status reports
accompanied by the current implementation
planning guides are a minimum. As the change
expands to include role changes (beta change),
workflow walk-throughs and redesigned job
descriptions need to be prepared. The walk-
throughs assist individuals in moving toward
new ways of doing work (i.e., altered roles);
however, new behaviors are not refrozen until
the job descriptions are redesigned, optimally
with the affected people as active participants
in the activity.
Gamma-level change requires that the orga-
nization prepare for change in a more formal
manner. Change orientation seminars empha-
sizing the problems associated with maintain-
ing the status quo and the opportunities
afforded by responding to these problems
should be emphasized in such a manner as to
solicit input as to how the organization might
or should respond. This allows participants to
buy in to the change process. Early successes
resulting from the change should be highly
publicized and rewarded to reinforce the new
appropriate behaviors.
Organizational Success Factors
As indicated, organizations must prepare for
high-order change. These high-order changes
often require the entire organization to be mobi-
lized in the process. In addition to the change
preparedness processes described above, organi-
zations can rally around threats such as a major
competitor or new regulatory requirements.
Such rallies lend themselves to contests, testi-
monials, or success stories, all of which provide
to focal points for strategic planning purposes.
Lesser-order change may require only moti-
vating people through improved understanding
of the rationale for change (alpha) or to gener-
ating enthusiasm for the new method of
accomplishing work (beta). Training sessions,
newsletters, kickoffs, and victory celebrations
may all be useful in generating a positive atti-
tude towards change.
Unanticipated problems typically come with
every change. The handling of these problems
is often as critical to the project success as the
handling of the intended change. The higher
the order of change, the more deliberate the
resolution of problems must be. Alpha-change
problems should be handled swiftly by the
immediate supervisor. Beta-order changes that
affect the roles of individuals should be han-
dled by a higher-level manager after a method-
ical understanding of the conflicts or problem.
Problems associated with gamma-level change
are best handled at the executive level, since
they may involve organizational competitive-
ness or other market or competitive position-
ing. These problems may not be resolved in as
expedient manner as the lower-order changes
because they involve significant organizational
and market introspection.
Appropriate training can often minimize
problems associated with the change. Alpha-
level change requires task-level training (i.e., how
the new technology is used). Since people’s roles
Downloaded by [University of Georgia] at 05:33 21 February 2013
69
INFORMATION SYSTEMS MANAGEMENT
SUMMER 1999
MANAGING THE THREE LEVELS OF CHANGE
are changed by beta-level change, training
should be extended beyond task-level training to
workflow training to understand how roles are
changed. It is often useful to simulate these
changes for individuals to internalize and accept
that the change will indeed accomplish the
required task. At the gamma level, the mobiliza-
tion of the organization around the change
needs considerable care and deliberate planning.
When possible, the change should occur in
phases to allow the organization to deal with it
in smaller, incremental chunks rather than all at
once. However, in such instances, it is very useful
to understand not only the current phase and
the end goal but also how each phase helps
achieve the longer-term outcome.
DISCUSSION
Projects associated with gamma-level change
are difficult to manage: the tasks are changed,
the people are affected, and the management
structure is transformed. To be successful, a
project manager must consider all the factors
mentioned previously; concentrating on only
one or two factors may not be enough to pro-
duce a success. With such projects, the man-
ager must perform a true juggling act, insuring
that all the factors are well-managed.
The cases examined reinforce the notion
that a clearly articulated vision for new technol-
ogy is important if the change is to be success-
ful. This is not a new concept, yet for new
technologies it seems as if managers often lose
sight of its importance.5,6,12,13 Perhaps it is the
seductive nature of any new technology that
the technical person becomes so preoccupied
with the technology and that the users’ needs
are overlooked.10 Perhaps it is simply the nature
of the technical person to focus on what the
technology can do rather than what it must do.
Those projects, where a clear business need for
new technology existed, progressed more
smoothly than projects in which a need was not
clearly articulated. Consequently, managers
must recognize that the existence of a technol-
ogy does not necessarily justify its use within
the organization.
Ideally, organizations should match avail-
able skills to projects at the outset. Manage-
ment, users, and developers each anticipate
certain organizational impacts resulting from
every new project implementation. For exam-
ple, a project designed to automate a simple
process may be thought to initially bring
about an alpha or first-order change. The
actual change that results, however, may be
greater than anticipated. When actual
changes are greater than expected, resources
may be under-committed for the project. A
resulting change that is less than expected
may indicate an over utilization of resources.
Exhibit 6 illustrates these possibilities. Over-
commitment often results in waste, since
projects can expand to reflect the availability
of resources. Conversely, under-committed
projects will likely fail because of inadequate
resources.
In many change models, the first stage con-
cerns preparing the organization to change.
Yet many organizations do not plan imple-
mentations appropriate to the level of change
anticipated. Exhibit 6 will help mangers
match resource allocation and the level of
planned change.
CONCLUSION
The SCI model extends the traditional STS
model by focusing on the varying magnitudes
of organizational change. In an era when
restructuring, downsizing, and reengineering
have become commonplace, managers must
pay closer attention to the human aspects of
the change rather than continue to emphasize
the technical system if organizational perfor-
mance is to be maximized. ▲
EXHIBIT 6 Anticipated vs. Actual Level of Change
Anticipated level of change
Alpha Beta Gamma
Actual Level
of change Alpha Match Over committed Over committed
Beta Under comitted Match Over committed
Gamma Under committed Under committed Match
Downloaded by [University of Georgia] at 05:33 21 February 2013
70 INFORMATION SYSTEMS MANAGEMENT
SUMMER 1999
MANAGING THE THREE LEVELS OF CHANGE
References
1. Bostrom, R. P. (1980), “A socio-technical
perspective on MIS implementation,” Paper
presented at the national conference of
ORSA/TIMS, Colorado Springs.
2. Eisenhardt, K. M. (1989), “Building Theories
from Case Study Research,” The Academy of
Management Review, Vol. 14 No. 4, pp. 532–550.
3. Gash, D. and Orlikowski, W. J. (1991), “Changing
Frames: Understanding Technological Change in
Organizations,” Academy of Management Best
Paper Proceedings, 51st Annual Meeting, Miami
Beach, FL. pp. 189–193.
4. Haapaniemi, P. (1996), “Cyber-strategy,” Journal
of Business Strategy, Vol. 17 No. 1, pp. 22–24.
5. Hoffman, D. E. (1995), “A new game requires new
technology team,” Best’s Review (Life/Health),
Vol. 96 No. 4, p. 78.
6. Levine, K. S. (1995), “Changing the mindset for
client/server,” Wall Street & Technology, Vol. 13
No. 9, p. 98.
7. Marshall, C. and Rossman, G. (1989), Designing
Qualitative Research, Sage Publications, Newbury
Park, CA.
8. Mata, F., Fuerst, W. L., and Barney, J. B. (1995),
“Information technology and sustained
competitive advantage: A resource-based
analysis,” Management Information Systems
Quarterly, Vol. 19 No. 4, pp. 487–505.
9. Miles, M. and Huberman, M. (1994), Qualitative
Data Analysis, A Sourcebook of New Methods,
(2nd Ed.) Sage Publications, Newbury Park, CA.
10. Misic, M. (1996), “The skills needed by today’s
systems analysts,” Journal of Systems
Management, Vol. 47 No. 3, pp. 34–40.
11. Nelson, F. (1996), “New client/server systems
create competitive edge,” Best’s Review
(Prop/Casualty), Vol. 96 No. 12, pp. 92–99.
12. Radding, A. (1995), “Infoworld 100: Client/Server
challenges — Familiar stumbling blocks in the
road,” Infoworld, Vol. 17 No. 38, pp. 100.
13. Rifkin, G. (1991), “IS Executives Must Put Their
Vision to Work, Speakers Urge,” Computerworld,
Vol. 25, p. 64.
14. Scott Morton, M. (1991), The Corporation of the
1990s, Oxford University Press, New York.
15. Schoderbek, P. P., Schoderbek, C. G., and Kefalas,
A. G. (1990), Management Systems: Conceptual
Considerations, (4th Ed.), Irwin Publications,
Boston.
16. Yin, R. K. (1994), Case Study Research: Design
and Methods, (2nd Ed.), Sage Publications,
Beverly Hills, CA.
Downloaded by [University of Georgia] at 05:33 21 February 2013
