When new technology
enters the workplace, managers must address their workers’ concerns
and make sure the lines of communication run both ways.
Change in the workplace has a significant impact on the individual
worker. Managers are especially interested in how change affects
a worker’s morale and performance. Some people react
to change by seeing it as an opportunity for improved conditions,
while others fear losing a workplace with which they are comfortable.
To alleviate fear of change, managers must acknowledge that
the fear is real and then address each person’s specific
It is important to study the dynamics of overcoming the fear
that causes resistance to change. This article examines the
impact of the introduction of a major change—computer
technology—into a workforce. It focuses on three actual
cases, describing how the change was introduced, how the individuals
in the workforce reacted, and how any subsequent adverse reaction
could have been reduced.
The Coming of Organizational Change
The specific workforce studied was a multidisciplinary directorate
of 140 civilian engineers, technical specialists, and clerical
and managerial personnel employed by the Army. From 1981 to
1986, an all-encompassing management information system designed
to automate all major functions was implemented in the directorate.
The directorate’s managers established a small computer
systems office with 10 to 12 engineers and specialists to design,
develop, and manage the introduction of computer-based tools.
The directorate was responsible for emergency production planning
and for the planning, budgeting, and execution of capital investment
projects, both in Government-owned facilities and in key privately-owned
facilities. The directorate was organized into several divisions,
with a specific function, manager, and staff ranging from 10
to 30 employees. In the style of a traditional hierarchal organization,
several of these divisions were divided further into branches.
With one exception, the directorate’s functions were
performed manually (that is, without computer support) and
were very paper intensive.
To improve productivity, the director created a special team
(which eventually became a permanent systems office) to look
at automating many organizational operations. The directorate
was experiencing a 20-percent annual turnover
rate in personnel at that time. The director and deputy director
thought that automating organizational processes would reduce
the impact of that turnover.
The special systems team researched and analyzed the directorate’s
business processes and designed the concept for an integrated
management information system (IMIS) of 10 interrelated subsystems
that would be phased in over a 3-year period. These subsystems
were intended to automate and integrate the major “manual” functions
of the directorate. The task of implementing the IMIS was inherited
by the permanent systems office. However, none of the people
who were on the special team that conceived the IMIS transitioned
into the systems office. The systems office was a branch within
a division and thus was two organizational levels below the
The special systems team made several presentations on the
IMIS to the directorate’s managers while it was being
designed. The director expressed his full support for its implementation.
Automating key processes was thought by most managers to be
useful in executing the directorate’s mission. The system
design was well thought out and incorporated design tools for
automated systems that were in use at that time. The special
team developed a set of system specifications for each of the
10 planned subsystems.
The first subsystem tackled was actually a reprogramming of
the directorate’s only existing automated system, which
was a partially automated process that had been in use for
several years by one specific branch. The employees of this
branch had been clamoring for an upgrade in the programs they
used. Other than normal programming problems, the transition
to the new subsystem went well. The branch’s employees
were involved from design to test to production (that is, actually
put into use).
When the permanent systems office moved to implement a new
subsystem that automated part of the budget process, resistance
started. The resistance was caused not so much by the technology
itself but by the process of its introduction. This situation
reflected the insight of Barbara M. Bouldin in Agents of
Change: Managing the Introduction of Automated Tools: “The difficulties
of implementing a new technology have very little to do with
the product itself, rather they are related to the intangible
but real obstacles associated with overcoming resistance.”
Case 1: Failure
Although implementation of the budget subsystem supposedly
had management support, the systems office immediately ran
into a wall of resistance from the budget division itself.
The resistance took the form of continual objections to the
original specifications and to numerous revisions that attempted
to incorporate budget division comments, the failure of budget
division personnel to participate in meetings scheduled to
resolve problems, and the refusal of the budget division chief
to even consider automation of “his” processes.
The systems office chief (who, remember, was one level lower
in the directorate’s hierarchy than the budget division
chief) attempted to persuade the recalcitrant budget chief
by pointing out the benefits of automating the processes. He
also made the resistance known to his chief (who was at the
same level as the budget division chief). Nothing changed.
The systems office found that the special team that prepared
the system specifications had not obtained or even sought input
from the budget division. As a result, the budget chief was
offended from the beginning and was not willing to listen to “outsiders” describe
how he should conduct and improve his business. As Bouldin
notes, experience has shown that “resentment . . . usually
accompanies recommendations issued by centralized groups.” That
had certainly occurred in this instance. Another dynamic at
play was that the budget chief did not want to change the way
he ran the budget process; he may have feared that he would
lose control over the process.
The introduction of new technology results in change. People
are required to stop using an old, comfortable method and start
using a new tool that may be totally foreign to them. It was
evident that automating the budget process with the use of
computers would result in different ways of doing business,
which the budget division’s personnel (or at least the
chief) did not want to learn. The budget chief also was not
convinced of any reason to give up the old method. Neither
the division chief who supervised the systems office nor the
director were willing to confront the budget chief to gain
some level of cooperation. The systems office chief did not
possess the skills to persuade the budget chief in order to
gain voluntary cooperation. This was a problem since, as Bouldin
observed, “one prerequisite for successful implementation
is [the involvement of] a zealot.” The budget chief did
not see a need to change his process, and he saw no advantage
to automation. It was his view that there was no need to make
a change for the sake of change.
Both sides dug in. The rather desultory discussions that did
take place between the two groups centered on what the new
subsystem, as it was designed by the special team, would do.
The discussions rarely, if ever, addressed how this would help
the budget division do its job or what the budget division’s
needs really were. Consequently, even after a 2-year “battle,” the
IMIS budget subsystem was never implemented.
This failure severely handicapped the implementation of other
subsystems because it sent the message to the rest of the directorate
that, if they resisted, they would not have to change. The
workforce was quick to pick up on the fact that senior managers
were not going to insist on the implementation of the IMIS
subsystems. This confirmed the observation of William Umiker
in a 1997 article in Health Care Supervisor, “Employees
are particularly prone to resistance when . . . they have supervisors
who fail to mean what they say, or fail to say what they mean.”
Case 2: Success
The greatest success in the initial IMIS introduction was the
implementation of a subsystem related to the planning-with-industry
function. This initiative differed from the experience of the
budget subsystem in that the special systems team had fully
involved the users in the preparation of specifications. The
branch getting the subsystem therefore received a subsystem
that represented what they wanted. This user involvement was
in keeping with the principle presented by Bouldin, that “not
only is listening a key to success . . . but it will also lay
the foundation for creating the proper environment in which
change can take place.”
Because of this earlier communication and coordination, the
systems office found no resistance in the branch. Instead,
they found impatient users anxious to get the new subsystem
as soon as possible. The users had accepted the proposed change,
had already projected themselves into their new roles, and
were anxious to get there. This subsystem was developed and,
after the normal debugging process, was used until replaced
by newer technology about 10 years later.
Case 3: The Budget Division Revisited
About 2 years after giving up on the budget subsystem, the
chief of the systems office approached the chief of the budget
division with a concept for a subsystem that would involve
most of the directorate. This subsystem would categorize and
track deficiencies in production capabilities and feed information
on those deficiencies into the budget process. (In the intervening
years, the importance of the systems function was recognized
and the systems chief was now at the same level as the division
chiefs, making communication possible at the same level.)
The two chiefs discussed the concept in general terms. The
budget chief agreed that he needed a better process for tracking
industrial base needs so that he could develop a budget that
eventually would be supported by Congress. He felt that input
to the budget process as it existed was too fragmented and
inconsistent to support a budget.
The budget division and systems office chiefs agreed to form
and co-lead a team to develop specifications for the new system.
Other divisions were responsible for identifying the industrial
base deficiencies, and they were asked to participate in the
process. This method took longer to develop a product than
just having one office do the work, but it resulted in a specification
for a new system that everyone agreed with, primarily because
everyone had input. Ultimately, the system was developed and
put into successful operation within the directorate.
Analysis of the Cases
The implementation of the IMIS ran into several problems from
the beginning. The first problem was that, for most of the
10 subsystems, the special systems team did not coordinate
properly during the design process with the organizations responsible
for the functions being automated. Experience has shown that
the people who are doing the job and who will use the new system
are the best judges of the system’s merits. But the people
who were doing the job were omitted from the design process!
In the case of the budget chief, this omission created resistance.
It is not unusual for people to “dig in” when faced
with unwanted change. As Mary Frances observed in her 1995
article in Personnel Review, “Organizational Change and
Personal Mythology,” “When we are hostile, we seek
to keep things as they are even when we are aware that this
is not working for us . . . It is a psychological fact of considerable
significance that people who go around aggressively dilating
other people’s fields are likely to find themselves the
targets of hostility.” In the case of the budget subsystem,
the chief’s ideas and expertise had been snubbed by people
who purported to know his business better than he did. So he
refused to change until much later, when he was ready to change.
The next problem was the fact that the people who designed
the system (as part of the special systems team) were not allowed
to follow through on its development and implementation in
the systems office. Consequently, the rationale behind the
IMIS design was essentially lost. The original designer of
the budget subsystem, for example, most likely would have been
able to articulate the benefits of change and might have been
able to persuade the budget division chief to support the automation
The chief of the systems office did not have the skills needed
to convince the budget division chief or upper management of
the need for the budget subsystem. The new subsystem represented
significant change in the way business is conducted, and implementing
change requires a considerable sales job. Unfortunately, the
systems chief was not a salesman, and the systems staff was
too inexperienced to persuade their peers in the budget division
who might have provided support for change.
Because of the original lack of coordination and the inability
to communicate the need for change to a resistant and hostile
manager, the budget subsystem was not implemented. Unfortunately,
this had an adverse affect on the entire IMIS initiative. By
allowing the budget chief to stop the implementation of the
new process, upper managers sent a message that they were not
really behind the IMIS. The directorate’s workforce could
see that management commitment was absent.
Management approval of a new technology without a strong commitment
to that technology is not unusual. This is especially true
if the new technology is being proposed primarily as a productivity
enhancer. Increasing productivity usually is not a priority
for most organizations. The primary reason for this is the
press of day-to-day business, which often causes workers at
all levels to feel that they do not have the time to develop
new ways of doing business or—even if an acceptable new
process is available—the time to learn the new way.
The success in the second case was due to the existence of
conditions that were almost the opposite of those that caused
the budget subsystem failure. First, the workers recognized
that they needed improvements to their existing process (which
was partially automated). Second, and perhaps most important,
the systems team designer responsible for designing the new
subsystem worked with the ultimate users to develop the specifications.
Third, the function being automated was performed almost wholly
within one branch, so any lack of support by the top directorate
managers had minimal impact on the change. The branch chief
was fully behind the effort and participated personally in
many of the design meetings and in all of the status reviews.
In this case, the managers involved were fully committed to
The third case was successful for almost the same reasons as
the second. However two additional factors were at work. First,
the systems office and the budget division had gradually developed
a level of trust since the earlier budget subsystem “battles.” The
systems office had supported the budget division in obtaining
and learning to use new personal computer technology, the systems
office chief and staff had learned how to work with and involve
the user in solving problems and making improvements, and the
budget division chief had decided that maybe the systems office
really was trying to help.
Second, the budget chief and his workforce wanted to improve
the function (the base capacity-budget interface). This time,
rather than the systems office staff designing a system without
outside input, a team drawn from both organizations was established
to develop the specifications. The two managers found that
the team could accomplish a considerable amount of coordination
in a short time. This was much quicker than the old method
of repeatedly preparing, staffing, commenting, and revising
formal correspondence until consensus was reached. As most
organizations have discovered, the use of teams speeds action
and reduces bureaucratic delays.
The success of the latter two cases was due to the fact that
the workers who were being asked to change were not having
an unknown change forced on them. They were involved and had
input into the change process. The new systems represented
the users’ thoughts and needs. As Frances concluded, “Our
capacity to handle unwanted or imposed change is closely correlated
with our belief that our reactions are understood and respected
on our own terms.” In both cases, workers’ input
was sought and their concerns carefully considered.
The systems office chief and his staff learned many valuable
lessons about change from the failure described in case 1,
especially when compared to the successes of cases 2 and 3—
Planning for change must be include input from the workers
who are going to be affected. This is the only way that their
needs can be identified.
The concerns and fears of workers must be addressed. They are
real to the individuals who have them. Only after they are
addressed will an individual be ready to accept change.
An environment conducive to fostering change must be nurtured.
This environment is marked by open, honest, two-way communication.
An adversarial relationship must be avoided, or the organization
will risk resistance caused by anger, not just anxiety.
An implementation team consisting of representatives of all
affected organizations is helpful in maintaining communication.
The implementation of change will only go as far as the support
of management allows. Change can happen at the grassroots level
if the individuals at that level believe in it and management
does not resist the change and provides at least some level
When all else fails and there are no other options, managers
can take away the old technology and replace it with the new.
Unfortunately, this occurred when a few clerical staff refused
to use a new word-processing software that had become the Army
standard. After an appropriate opportunity for transition,
and in consultation with their supervisors, the old software
was removed from their computers, leaving the workers no choice
but to learn to use the new software to do their jobs.
Other technological changes buffeted the directorate in following
years. New computers replaced the first ones (several times),
new software replaced older software, and, in order to take
advantage of newer technologies, new procedures replaced former
processes. Problems associated with these changes still occurred,
but, by using the lessons learned listed above, problems were
held to a minimum. The workforce gradually became used to the
continuous change and, for the most part, was able to accommodate
to the different initiatives.
Managers must remember that they are susceptible to the same
reactions to change as their subordinates. For affected managers
involved in implementing change, it is therefore simply a matter
of treating their workers as they want to be treated by their
own superiors. The establishment of honest, two-way communication
will facilitate the acceptance of change by the workforce and
will make the managers’ role as change agent a little
Dr. Craig C. Kuriger is an adjunct associate professor at Black
Hawk College in Illinois and Matanuska-Susitna College in
Alaska. A retired Department of the Army civilian, he has
an M.S. degree in systems management from the Florida Institute
of Technology and a Ph.D. degree in applied management and
decision sciences from Walden University. He is a graduate
of the National Security Management Course at the National
Defense University. This article was adapted from his book,
Organizational Change: Case Studies in the Real World, published
in 2005 by Universal Publishers.