HomeAbout UsBrowse This IssueBack IssuesNews DispatchesSubscribing to Army LogisticianWriting for Army LogisticianContact UsLinks

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
Workplace Change and Worker Fears

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 concerns.

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, each 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 director.

IMIS Implementation

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 effort.

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 change.

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.

Lessons Learned

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 of support.
• 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 more effective.
ALOG

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.