This paper will give you an opportunity to evaluate a failed organizational change, identify a theory that could have been used to develop the change, and aapply that theory to the failed change. The paper must follow these standards:be 8-10 pages of content in lengthhave at least three outside professional resourcesfollow APA standardsOrganizational
Dr. Charles Poplos, PMP
Organizational Change Management
• Organized, systematic application of
– Knowledge
– Tools
– Resources of change
• To provide organizations with a key process to
achieve their business strategy
Difference Between Project and
Change Management
• Project Management focus is on specific
project activities and deliverables
• Change Management focus is on the impact
the project will have on the organization
• Project Management – the change
• Change Management – getting the change
Essential Components

Sponsor Management
End-user Communication
Transition Planning
Resistance Management
Sponsor Management
• Sponsor is key
• CM team works to produce
the Sponsor Roadmap
– Let the sponsor know about
expectations, and
– How the sponsor can help
achieve success
End-user Communication
• Permeate the gaining organization’s hierarchy
with change information
– Keep them informed
– Get them ready for the impact
– Make them comfortable
• Readiness involves
• Analyzing an organization to identify
– The current state
– The future desired state,
– What is required to move from one state to the other
• Organizations need to understand
– The specific impacts the new system will have on their own internal
– To prepare proactively for those impacts
• Training plays a critical role in
helping the gaining organization
adapt the new processes,
hardware, software, etc. into
their operations
• CM Team performs training
needs analysis
– Determines the training strategy
– Helps manage the training plan
– Identifies the skill gaps of the
affected end-user community
• The CM team works with
supervisors to ensure they are
aware of the
– Project or what is being changed
– Impacts
– Expectations of them
• The coaching effort can range from
– Coaching info sheets to
– Formal meetings with
managers/supervisors to advise
them on how best to coach their
Transition Planning
• Transition Planning involves
– Preparing the organization to support the new system once the change is
– The team
• Reviews the skills necessary to support the new system
• Works with individuals on the production side to develop transition plans
to successfully support the new application
– Users may

Require Training
Require remedial training in related skill sets
Need to acquire entirely new skill sets
Will have job reclassification issues
Resistance Management
• A resistance management plan is a proactive
approach to managing resistance
• It is important to identify potential resistance
points by defining
– What resistance may look like
– How to identify resistance
– How to mitigate the impact of resistance
In General
• Change Management
– Manages change as a process
– Recognizes that projects deal with people
– Helps people through the change with open and
honest communication
– Provides awareness of the new environment
– Ensuring readiness to function competently
Preparation For Major Change
• It is important for
organizations to
– Impacts the
implementation will have
on their own internal
• And to
– Prepare proactively for
those impacts
• Organizational Change
Management is
concerned with:
– Managing change as a
process and recognizing
that people are the focus
– Providing direct,
knowledgeable, and
frequent communication
The Change Problem
• Change problem is
– Some future state to be
– Some current state to be left
– A some structured, organized
process for getting from the
one to the other
Change Answers Three Questions
• How do we make the change?
• What needs to be changed?
• Why is it being changed?
How Do We Make The Change?
• How do we get people to
– Be more open?
– Assume more responsibility?
– Be more creative?
What Needs To Be Changed?

What are we trying to accomplish?
What changes are necessary?
What indicators will signal success?
What standards apply?
What measures of performance are we trying
to affect?
Why Is It Being Changed?
• Frequently chains and networks of business
must be traced out before one finds the “true”
reason for a change effort
• CM wants to find the ultimate purposes of
functions and find new and better ways of
performing them
– Why do we do what we do?
– Why do we do it the way we do it?
The Theories

Satir’s Change Process Model
Kubler-Ross Stages of Change Model
Kotter’s Phases of Change Model
Lewin’s Dynamic Stability Model
Prosci Change Management Model
Satir’s Change Process Model
• Satir’s change model is one of many tools
she invented to enhance communication
and encourage growth
– “Change” is the project announcement which
leads to a period of uncertainty, chaos, and
productivity decreases
– As people learn more and receive
training/coaching, their productivity begins to
– There is a period of flux until the new system
becomes the status quo.
Kubler-Ross Stages of Change Model
• Describes the process
by which people deal
with grief
– Significant changes in
the working
environment can bring
about a form of grief
Kubler-Ross Stages of Change Model
• Five stages
– Denial: The initial stage: It cant be happening.
– Anger: Why ME? Its not fair?! Recognition of changes in the day-today routine, perceived (or real) loss of prestige, power, knowledge,
movement to the new state where things are unfamiliar and
– Bargaining: Just let me live to see my son graduate. A sense of “just
leave me alone”, or “just don’t change this one particular thing too”.
Sometimes expressed as “as long as I don’t lose anything”, or “just
make sure I get the training I need”.
– Depression: Im so sad, why bother with anything? When a system
first implements feelings like “this is too hard”, “this is too slow”, “this
takes too much work”, and “this is stupid” are not uncommon.
– Acceptance: Its going to be OK. Once people get used to the new
system, they begin to accept it, and in time will defend it as strongly as
they defended the old system.
• Kotter’s change
phases model
deals with the
phases of change
Lewin’s Dynamic Stability Model
• Refers to “unfreezing, changing, and
– It gives rise to thinking about a staged approach to
changing things. Looking before you leap is usually
sound practice.
• Using Lewin’s approach as a starting point
– Most change associated with projects comes from
the envisioning of some future state yet to be
– To arrive at the “to be” state, it is important to
understand the “as is” state.
Prosci Change Management Model
• Prosci
– Is a nationally recognized research
and development company that
specializes in bench-marking change
management best practices
– Has made a significant step forward in
the integration of organizational
change management and project
– Released its Change Management
• Following eight years of
research with over 1000
Prosci Change Management Model
• Built into the process are scalable and
flexible components for customizing OCM
activities to the specific organizational
change being implemented
– ADKAR (Awareness, Desire, Knowledge,
Ability, Reinforcement) system for
working through change
• Includes
– Tools to perform organizational analysis
– Templates which can be customized to
aid the process of preparing
organizations for change
Selecting a Change Strategy

Degree of resistance
Target population
The stakes
Time frame
Organizational Strategy
Basic Change Management Steps
• Provide awareness of the change that is going to occur
• Ensure there is understanding about why the change needs to happen and
the benefits of that change
• Facilitate acceptance of the change
• Act as someone who cares, listens, and responds to individual needs and
• Manage people and expectations
• Assist people to use their insights, skills, and sense of values to move
forward with organization/team efforts.
In Summary
• Organizational Change Management is an important part of any process
• Getting the people to accept the change is essential in project success
• Organizational change management is made up of seven essential

Sponsor management
End-user communication
Transition Planning
Resistance Management
In Summary
• Change Management
– helps answer the question “how are we going to move from this
current state to the future state?”
– is drawn from the fields of psychology, sociology, business
administration, economics, industrial engineering, systems
engineering, and the study of human and organizational behavior
• Change Management and Project Management must work
together to ensure project success and acceptance of the
change brought about by new systems
An Improvisational Model of Change
Management: The Case of Groupware
Wanda J. Orlikowski and J. Debra Hofman
Massachusetts Institute of Technology
Sloan School of Management
50 Memorial Drive
MA 02142-1347
Sloan Management Review, January 1997
Table of Contents
An Improvisational Model for Managing Change
Case Example: Zeta
Summary of Zeta Case
Enabling Conditions
Aligning Key Change Dimensions
Dedicating Resources for Ongoing Support
We would like to thank the editor and reviewers for their helpful comments on an earlier version
of this manuscript. We gratefully appreciate the research support of MITs Center for
Coordination Science and Center for Information Systems Research.
An Improvisational Model of Change Management:The Case of Groupware Technologies
In this paper, we present an alternative way of thinking about technological change in
organizations. This alternative approach is motivated by a recognition that traditional models for
managing technological change – in which the major steps of the change are defined in advance
and the organization then strives to implement these changes as planned in a specified period of
time – are not particularly useful given the more turbulent, flexible, and uncertain organizational
situations that many companies face today. Traditional models are also not particularly useful for
helping the implementation of technologies such as groupware whose unprecedented, openended, and context-specific nature make it difficult to predefine the exact changes to be realized
and to predict their likely organizational impact.
We suggest an alternative model of managing technological change, one that reflects the
dynamic and variable nature of contemporary organizations and technologies, and which
accommodates iterative experimentation, use, and learning over time. We label such a model of
managing technological change improvisational, and suggest that it may enable organizations
to take advantage of the evolving capabilities, emerging practices, and unanticipated outcomes
that accompany use of new technologies in contemporary organizations.
In the preface to her discussion of technology design, Suchman (1987: vii) refers to two different
approaches to open sea navigation — the European and the Trukese:
The European navigator begins with a plan — a course — which he has charted according to
certain universal principles, and he carries out his voyage by relating his every move to that plan.
His effort throughout his voyage is directed to remaining on course. If unexpected events
occur, he must first alter the plan, then respond accordingly. The Trukese navigator begins with
an objective rather than a plan. He sets off toward the objective and responds to conditions as
they arise in an ad hoc fashion. He utilizes information provided by the wind, the waves, the tide
and current, the fauna, the stars, the clouds, the sound of the water on the side of the boat, and he
steers accordingly. His effort is directed to doing whatever is necessary to reach the objective.
(Berreman 1966, p.347)
Like Suchman, we too find this contrast in approaches instructive, and will use it here to
motivate our discussion of managing technological change. In particular, we suggest that how
people think about managing change in organizations most often resembles the European
approach to navigation. That is, they believe they need to start with a plan for the change, charted
according to certain general organizational principles, and that they need to relate their actions to
that plan, ensuring throughout that the change remains on course.
However, when we examine how change actually occurs in practice, we find that it much more
closely resembles the voyage of the Trukese. That is, people end up responding to conditions as
they arise, often in an ad hoc fashion, doing whatever is necessary to implement change. In a
manner similar to Argyris and Schons (1978) contrast between espoused theories and theoriesin-use, we suggest that there is a discrepancy between how people think about technological
change and how they do it. Moreover, we suggest that this discrepancy significantly contributes
to the difficulties and challenges that contemporary organizations face as they attempt to
introduce and effectively implement technology-based change.
Traditional ways of thinking about technological change have their roots in Lewins (1952) threestage change model of unfreezing, change, and refreezing (Kwon and Zmud, 1987).
According to this model, the organization prepares for change, implements the change, and then
strives to regain stability as soon as possible. Such a model, which treats change as an event to be
managed during a specified period (Pettigrew, 1985), may have been appropriate for
organizations that were relatively stable, bounded, and whose functionality was sufficiently fixed
to allow for detailed specification. Today however, given more turbulent, flexible, and uncertain
organizational and environmental conditions, such a model is becoming less appropriate; hence,
the discrepancy.
This discrepancy is particularly pronounced when the technology being implemented is openended and customizable, as in the case of the new information technologies that have come to be
known as groupware.[1] Groupware technologies provide electronic networks that support
communication, coordination, and collaboration through facilities such as information exchange,
shared repositories, discussion forums, and messaging. Such technologies are typically designed
with an open architecture that is adaptable by end users, allowing them to customize existing
features and create new applications (DeJean and DeJean, 1991; Malone et al., 1992). Rather
than automating a predefined sequence of operations and transactions, these technologies tend to
be general-purpose tools which are used in different ways across various organizational activities
and contexts. Organizations need the experience of using groupware technologies in particular
ways and in particular contexts to better understand how they may be most useful in practice. In
such a technological context, the traditional change model is thus particularly discrepant.
The discrepancy is also evident when organizations are using information technologies to
attempt unprecedented and complex changes such as global integration or distributed knowledge
management. A primary example of this is the current attempt by many companies to redefine
and integrate global value chain activities which were previously managed independently. While
there is typically some understanding up front of the magnitude of such a change, the depth and
complexity of the interactions among these activities is only fully understood as the changes are
implemented. For many organizations, such initiatives represent a new ball game, not only
because they havent played the game before but because most of the rules are still evolving. In a
world with uncertain rules, the traditional model for devising and executing a game plan is very
difficult to enact. And as recent strategy research has suggested (Mintzberg, 1994; McGrath and
McMillan, 1995), planning in such circumstances is more effective as an ongoing endeavor,
reflecting the changing and unfolding environments with which organizations interact.
In many situations, therefore, predefining the technological changes to be implemented and
accurately predicting their organizational impact is not feasible. Hence, the models of planned
change that often inform implementation of new technologies are less than effective. We suggest
that what would be more appropriate is a way of thinking about change that reflects the
unprecedented, uncertain, open-ended, complex, and flexible nature of the technologies and
organizational initiatives involved. Such a model would enable organizations to systematically
absorb, respond to, and even leverage unexpected events, evolving technological capabilities,
emerging practices, and unanticipated outcomes. Such a model for managing change would
accommodate — indeed, encourage — ongoing and iterative experimentation, use, and learning.
Such a model sees change management more as an ongoing improvisation than a staged event. In
this paper, we propose such an alternative model. After presenting the model, we describe a case
study of groupware implementation in a customer support organization to illustrate the value of
this alternative model in practice. We conclude by discussing the conditions under which such an
improvisational model may be a powerful way of managing the implementation and use of
advanced technologies.
An Improvisational Model for Managing Change
The improvisational model for managing technological change is based on research we have
done into the implementation and use of open-ended information technologies. The model rests
on two major assumptions which differentiate it from traditional models of change: first, that the
changes associated with technology implementations constitute an ongoing process rather than
an event with an end point after which the organization can expect to return to a reasonably
steady state; and second, that the various technological and organizational changes made during
the ongoing process cannot, by definition, all be anticipated ahead of time.
Given these assumptions, our improvisational change model recognizes three different types of
change: anticipated, emergent, and opportunity-based. These change types are elaborations on
Mintzbergs (1987) distinction between deliberate and emergent strategies. Here, we distinguish
between anticipated changes — changes that are planned ahead of time and occur as intended -and emergent changes — changes that arise spontaneously out of local innovation and which are
not originally anticipated or intended. An example of an anticipated change would be the
implementation of electronic mail software which accomplishes its intended aim to facilitate
increased and quicker communication among organizational members. An example of an
emergent change would be the use of the electronic mail network as an informal grapevine
disseminating rumors throughout an organization. This use of e-mail is typically not planned or
anticipated when the network is implemented, but often emerges tacitly over time in particular
organizational contexts.
We further differentiate these two types of changes from opportunity-based changes — changes
that are not anticipated ahead of time but are introduced purposefully and intentionally during the
change process in response to an unexpected opportunity, event, or breakdown. For example, as
companies gain experience with the World Wide Web, they are finding opportunities to apply
and leverage its capabilities in ways that were not anticipated or planned before the introduction
of the Web. Both anticipated and opportunity-based changes involve deliberate action, in
contrast to emergent changes which arise spontaneously and usually tacitly out of peoples
practices with the technology over time (Orlikowski, 1996).
These three types of change build on each other over time in an iterative fashion (see Figure 1).
While there is no predefined sequence in which the different types of change occur, the
deployment of new technology often entails an initial anticipated organizational change
associated with the installation of the new hardware/software. Over time, however, use of the
new technology will typically involve a series of opportunity-based, emergent, and further
anticipated changes, the order of which cannot be determined in advance because the changes
interact with each other in response to outcomes, events, and conditions arising through
experimentation and use.
One way of thinking about this model of change is to consider, as an analogy, a jazz band. While
members of a jazz band, unlike members of a symphony orchestra, do not decide in advance
exactly what notes each is going to play, they do decide ahead of time what musical composition
will form the basis of their performance. Once the performance begins, each player is free to
explore and innovate, departing from the original composition. Yet, the performance works
because all members are playing within the same rhythmic structure and have a shared
understanding of the rules of this musical genre. What they are doing is improvising — enacting
an ongoing series of local innovations which embellish the original structure, respond to
spontaneous departures and unexpected opportunities, and iterate and build on each other over
time. Using our earlier terminology, the jazz musicians are engaging in anticipated, opportunitybased, and emergent action during the course of their performance to create an effective and
creative response to local conditions.
Similarly, an improvisational model for managing technological change in organizations is not a
predefined program of change charted by management ahead of time. Rather, it recognizes that
technological change is an iterative series of different changes, many unpredictable at the start,
that evolve out of practical experience with the new technologies. Using such a model to manage
change requires a set of processes and mechanisms to recognize the different types of change as
they occur and to respond effectively to them. The illustrative case presented below suggests that
where an organization is open to the capabilities offered by a new technological platform and
willing to embrace an improvisational change model, innovative organizational changes can be
Case Example: Zeta
Zeta is one of the Top 50 software companies in the US, with $100 million in revenues and about
1000 employees. It produces and sells a range of powerful software products providing
capabilities such as decision support, executive information, and marketing analysis. Zeta is
headquartered in the Midwest, with sales and client service field offices throughout the world.
Specialists in the Customer Service Department (CSD) at Zeta provide technical support via
telephone to clients, consultants, value-added resellers, Zeta client service representatives in the
field, and other Zeta employees who use the products. This technical support can be quite
complex. Specialists typically devote several hours of research to each problem, often searching
through reference material, attempting to replicate the problem, and/or reviewing program source
code. Some incidents require interaction with members of other departments such as quality
assurance, documentation, and product development. The CSD employs approximately fifty
specialists and is headed by a director and two managers.
In 1992, the CSD purchased the Lotus Notes groupware technology within which they developed
a new Incident Tracking Support System (ITSS) to help them log customer calls and keep a
history of progress towards resolving the customers problems. Following a successful pilot of
the new system, the CSD decided to commit to the Notes platform and to deploy ITSS
throughout its department. The acquisition of new technology to facilitate customer call tracking
was motivated by a number of factors. The existing tracking system was a home-grown system
which had been developed when the department was much smaller and Zetas product portfolio
much narrower. The system was not real-time, entry of calls was haphazard, information
accuracy was a concern, and performance was slow and unreliable. It provided little assistance
for reusing prior solutions and no support for the management of resources in the department.
The volume and complexity of calls to the CSD had increased in recent years due to the
introduction of new products, the expanded sophistication of existing products, and the extended
range of operating platforms supported. Such shifts had made replacement of the tracking system
a priority, as CSD managers were particularly concerned that the home-grown system provided
no ability to track calls, query the status of particular calls, apprehend the workload, balance
resources, identify issues and problems before they became crises, and obtain up-to-date and
accurate documentation on work in progress and work completed. In addition, calls would
occasionally be lost, as the slips of paper on which they were recorded would get mislaid or
inadvertently thrown away.
The initial introduction of the new ITSS system was accompanied by anticipated changes in the
nature of both the specialists and managers work. In contrast to the previous system, which had
been designed to only capture a brief description of the problem and its final resolution, ITSS
was designed to allow specialists to document every step they took in their process of resolving a
particular incident. That is, it was designed to enable the capture of a full incident history. As
specialists began to use ITSS this way, the focus of their work shifted from primarily research-solving problems–to both research and documentation–solving problems and documenting work
in progress.
The ITSS database quickly began to grow as each specialist documented his/her resolution
process in detail. While documenting calls took time, it also saved time by providing a rich
database of information which could be searched for potential resolutions. Moreover, this new
database of rich information served as an unexpected and informal learning mechanism by
providing the specialists with exposure to a wide range of problems and solutions. As one
specialist noted: If it is quiet, I will check on my fellow colleagues to see what … kind of calls
they get, so I might learn something from them. … just in case something might ring a bell when
someone else calls. At the same time, however, using the ITSS database as a sole source of
information did pose some risk, since there were no guarantees as to the accuracy of the
information. To minimize this risk, the specialists tacitly developed a set of informal quality
indicators to help them distinguish between reliable and unreliable data. For example, resolutions
that were comprehensively documented, documented by certain individuals, or verified by the
customer were considered more reliable sources of information.
In addition to these changes in specialists work, use of the new system by the CSD managers
improved their ability to control the departments resources. Specialists use of ITSS to document
calls provided managers with detailed workload information, which was used to justify increased
headcount and adjust work schedules and shift assignments on a dynamic and as-needed basis.
ITSS also supplied managers with more accurate information on specialists work process, for
example, the particular steps followed to research and resolve a problem, the areas in which
specialists sought advice or were stalled, and the quality of their resolutions. As managers began
to rely on the ITSS data to evaluate specialists performance, they expanded the criteria they used
to do this evaluation. For example, quality of work-in-progress documentation was included as
an explicit evaluation criterion and documentation skills became a factor in the hiring process.
As the CSD gained experience with and better understood the capabilities of the groupware
technology, the managers opportunistically introduced a change in the structure of the
department to further leverage these capabilities. This change had not been planned prior to the
implementation of ITSS, but the growing reliance on ITSS and an appreciation of the capabilities
of the groupware technology created an opportunity for the CSD to redistribute call loads. In
particular, first line and second line support levels were established, with junior specialists
being assigned to the first line, and senior specialists to the second line. Partnerships were
created between the less experienced, junior specialists and the more experienced, senior
specialists. Front line specialists now took all incoming calls, resolved as many of these as they
could, and then electronically transferred calls to their second line partners when they were
overloaded or had calls which were especially difficult. In addition to handling calls transferred
to them, senior specialists were expected to proactively monitor their front line partners progress
on calls and to provide assistance as needed.
While this partnership idea was conceptually sound, it regularly broke down in practice. Junior
specialists were often reluctant to hand off calls, fearing that such transfers would reflect poorly
on their competence or that they would be overloading their more senior partners. Senior
specialists, in turn, were usually too busy resolving complex incidents to spend much time
monitoring their junior partners call status or progress. In response to this unanticipated
breakdown in the partnership idea, CSD managers introduced another opportunity-based
structural change. They created a new role, that of an intermediary, which was filled by a senior
specialist whose job it was to mediate between the first and second lines, regularly monitoring
junior specialists call loads and work in progress, and dynamically reassigning calls as
appropriate. The new intermediary role served as a buffer between the junior and senior
specialists, facilitating the transfer of calls and relieving senior specialists of the responsibility to
constantly monitor their front line partners. With these structural changes, ITSS in effect
changed the prior undifferentiated and fixed division of labor within the department to a dynamic
distribution of work reflecting different levels of experience, various areas of expertise, and
shifting workloads. In response to the new distribution of work, managers adjusted their
evaluation criteria to reflect the changed responsibilities and roles within the CSD.
Another change which emerged over time was a shift in the nature of collaboration within the
CSD from a primarily reactive mode of collaboration to one that was more proactive. Because all
specialists now had access to the database of calls being worked on in the department, they
began to browse through each others calls to see which ones they could provide help on. Rather
than waiting to be asked if they had a solution to a particular problem (which is how they had
solicited and received help in the past), specialists actively browsed through the database of calls
seeking problems for which they could offer help. This shift from solicited to unsolicited
assistance was facilitated by the capabilities of the groupware technology, the complex nature of
the work, existing evaluation criteria that stressed teamwork, and the long-standing cooperative
and collegial culture in the CSD. Consider the following specialists comments: Everyone
realizes that we all have a certain piece of the puzzle … I may have one critical piece, and Jenny
may have another piece. … And if we all work separately, were never going to get the puzzle
together. But by everybody working together, we have the entire puzzle; Here I dont care who
grabs credit for my work … this support department does well because were a team, not because
were all individuals (Orlikowski, 1995). Managers responded to this shift in work practices by
adjusting specialists evaluation criteria to specifically take unsolicited help giving into account.
As one manager explained: When Im looking at incidents, Ill see what help other people have
offered, and that does give me another indication of how well theyre working as a team.
After approximately one year of using ITSS, the CSD implemented two further organizational
changes around the groupware technology. Both of these had been anticipated in the initial
planning for ITSS, although the exact timing for their implementation had been left unspecified.
First, the ITSS application was installed in three overseas support offices, with copies of all the
ITSS databases replicated regularly across the four support sites (US, UK, Australia, and
Europe). This provided all support specialists with a more extensive knowledge base on which to
search for possibly helpful resolutions. The use of ITSS in all the support offices further allowed
specialists to transfer calls across offices, essentially enacting a global support department within
Second, the CSD initiated and funded the development of a number of bug tracking systems
which were implemented within groupware and deployed in Zetas departments of product
development, product management, and quality assurance. These bug tracking applications,
which were modeled on the ITSS application, were linked into ITSS and enabled specialists to
enter any bugs they had discovered in their problem resolution activities directly into the relevant
products bug tracking system. Previously, the reporting of bugs by the CSD to other departments
was done manually, took many weeks, and involved minimal communication. With the new bug
tracking applications and linkages to ITSS, specialists could also directly query the status of
particular bugs, and even change their priority if customer calls indicated that such an escalation
was needed. Specialists in particular found this change very valuable. For the other departments,
the link with ITSS allowed users such as product managers and developers to access the ITSS
records and trace the particular incidents that had uncovered certain bugs or uncovered certain
use problems. Only the developers had some reservations about the introduction of the bug
tracking application, reservations that were associated with the severe time constraints under
which they worked to produce new releases of Zeta products.
In addition to the improved coordination and integration achieved with other departments and
offices, the CSD also realized further opportunity-based innovations and emergent changes
within their own practices. For example, as the number of incidents in ITSS grew, some of the
senior specialists began to realize that the information in the system could be used to help train
newcomers. By extracting certain records from the ITSS database, these specialists
opportunistically created a training database of sample problems with which newly hired
specialists could work. Using the communication capabilities of the groupware technology, these
senior specialists could monitor their trainees progress through the sample database and
intervene to educate when necessary. As one senior specialist noted: So we can kind of keep up
to the minute on their progress. … If theyre on the wrong track, we can intercept them and say,
Go check this, go look at that. But its not like we have to actually sit with them and review
things. Its sort of an on-line, interactive thing. As a result of this new training mechanism, the
time that it took for new specialists to begin taking customer calls was reduced from eight weeks
to about five weeks.
An emergent change realized during this time related to access control. An ongoing issue for the
CSD was who (if anybody) outside of the CSD should be given access to the ITSS database with
its customer call information and specialists work-in-progress documentation. This issue was not
one that had been anticipated prior to the acquisition of the technology. While the managers were
worried about how to respond to the increasing demand for access to ITSS as the database
became more valuable and word about its content spread throughout the company, they
continued to handle each access request as it came up. Over time, they had used a variety of
control mechanisms ranging from giving limited access to some trusted individuals, generating
summary reports of selected ITSS information for others, and refusing any access to still others.
As one of the managers explained, it was only after some time that they realized that their
various ad hoc responses to different access requests amounted to, in essence, a set of rules and
procedures about access control. By responding locally to a variety of requests and situations
over time, an implicit access control policy for the use of ITSS had evolved and emerged.
Summary of Zeta Case
Figure 2 represents the change model around the groupware technology followed by Zeta in its
CSD. Along with the introduction of the new technology and the development of the ITSS
application, the CSD first implemented some planned organizational changes, expanding the
specialists work to include work-in-progress documentation and adjusting the managers work to
take advantage of the real-time access to workload information. These changes were anticipated
prior to introducing the new technology. As specialists and managers began to work in new ways
with the technology, a number of changes emerged in practice, such as the specialists developing
norms to determine the quality and value of prior resolutions, and managers paying attention to
documentation skills in hiring and evaluation decisions.
Building on these anticipated and emergent changes, the CSD introduced a set of opportunitybased changes, creating junior-senior specialist partnerships to take advantage of the shared
database and communication capabilities of the technology, and then adding the new role of
intermediary in response to the unexpected problems that arose around partnership and work
reassignment. These changes were not anticipated at the start, nor did they simply emerge
spontaneously in working with the new technology. Rather, they were conceived of and
implemented in situ and in response to the opportunities and issues which arose as the CSD
gained experience and developed a deeper understanding of the new technology and their
particular use of it. This change process around the groupware technology continued through the
second year at Zeta when some anticipated organizational changes were followed by both
emergent and opportunity-based changes associated with unfolding events and the learning and
experience gained by using the new technology in practice.
Overall, what we see here is an iterative and ongoing series of anticipated, emergent, and
opportunity-based changes which allowed Zeta to learn from practical experience, respond to
unexpected outcomes and capabilities, and adapt both the technology and the organization as
appropriate. In effect, Zetas change model cycles through anticipated, emergent, and
opportunity-based organizational changes over time. It is a change model which explicitly
recognizes the inevitability, legitimacy, and value of ongoing learning and change in practice.
Enabling Conditions
Clearly, there were certain aspects of the CSD and the Zeta organization which enabled it to
effectively adopt an improvisational change model to implement and use the groupware
technology. Our research at Zeta and other companies suggests that at least two sets of enabling
conditions are critical: aligning key dimensions of the change process, and dedicating resources
to provide ongoing support for the ongoing change process. We will consider each in turn.
Aligning Key Change Dimensions
An important influence on the effectiveness of any change process is the interdependent
relationship among three dimensions: the technology, the organizational context (including
culture, structure, roles and responsibilities), and the change model used to manage change (see
Figure 3). Ideally, the interaction among these three dimensions is compatible, or at a minimum,
not in opposition.
First, consider the relation of the change model and the technology being implemented. When
the technology has been designed to operate like a black box, allowing little adaptation by
users, an improvisational approach may not be more effective than the traditional approach to
technology implementation. Similarly, where the technology is well-established and its impacts
are reasonably well understood, a traditional planned change approach may be effective.
However, when the technology being implemented is new and unprecedented, and additionally
has an open-ended and customizable nature, an improvisational model providing the flexibility
for organizations to adapt and learn through use becomes more appropriate. Such is the case, we
believe, with the groupware technologies available today.
Second, the relation of the change model to organizational context is also relevant. A flexible
change model, while likely to be problematic in a rigid, control-oriented or bureaucratic culture,
is well-suited to a more informal and cooperative culture such as the one characterizing the CSD.
In another study (Gallivan et al., 1994), we examined the MidCo organizations successful
adoption and implementation of CASE (Computer-Aided Software Engineering) tools within its
IS organization. While MidCo, a multi-national chemical products company with revenues of
over $1.5 billion, was a relatively traditional organization in many ways, key aspects of its
culture–a commitment to total quality management, a focus on organizational learning and
employee empowerment, as well as a long-term time orientation–were particularly compatible
with the improvisational model it used to manage ongoing organizational changes around the
new software development technology.
Finally, there is the important relationship between the technology and the organizational
context. At Zeta, the CSDs cooperative, team-oriented culture was compatible with the
collaborative nature of the new groupware technology. Indeed, CSDs existing culture allowed it
to take advantage of the opportunity for improved collaboration afforded by the groupware
technology. Moreover, when existing roles, responsibilities, and evaluation criteria became less
salient, the CSD managers expanded or adjusted these to reflect new uses of the technology.
Compare these change efforts to those of Alpha, a professional services firm which introduced
the Notes groupware technology to leverage knowledge sharing and to coordinate distributed
activities (Orlikowski, 1992). While the physical deployment of groupware grew very rapidly,
anticipated benefits were realized much more slowly. Key to the reluctance to use groupware for
knowledge sharing was a perceived incompatibility between the collaborative nature of the
technology and the individualistic and competitive nature of the organization. As in many
professional services firms, Alpha rewarded individual rather than team performance, and
promoted employees via an up or out set of evaluation criteria. In such an environment,
knowledge sharing via a global Notes network was seen to threaten status, distinctive
competence, and power. In contrast to Zeta, managers at Alpha did not adjust policies, roles,
incentives, and evaluation criteria to better align their organization with the intended use and
capabilities of the technology they had invested in.
Dedicating Resources for Ongoing Support
An ongoing change process requires dedicated support over time to adapt both the organization
and the technology to changing organizational conditions, use practices, and technological
capabilities. Opportunity-based change, in particular, depends on the ability of the organization
to notice and recognize opportunities, issues, breakdowns, and unexpected outcomes as they
arise. This requires attention on the part of appropriate individuals in the organization to track
use of the technology over time and to implement or initiate organizational and/or technological
adjustments which will mitigate or take advantage of the identified problems or opportunities. At
Zeta, it was the managers and technologists who primarily played this role, incorporating it into
their other responsibilities. So, for example, the managers adjusted the structure of their
department by introducing first line/second line partnerships to facilitate a dynamic division of
labor, and then made further adaptations by introducing an intermediary role to overcome some
unanticipated difficulties associated with the initial change. Similarly, the technologists working
with the CSD incorporated enhancements to the ITSS system as they realized ways of improving
ease of use and access time. The CSDs commitment to noticing and responding to changes when
appropriate did not end after the implementation of the technology. The managers clearly
realized that the change process they had embarked on with the use of groupware was an
ongoing one, as one manager noted: Weve had ITSS for two years. Im surprised that the
enthusiasm hasnt gone away. … I think its because its been changed on a regular
basis….Knowing that [the changes are going to get implemented keeps you wanting to think
about it, and keep going.
Ongoing change around the use of groupware technology also requires ongoing adjustments to
the technology itself as users learn and gain experience with the new technologys capabilities
and their uses of it over time. Without dedicated technology support to implement these
adaptations and innovations, the continued experimentation and learning in use central to an
improvisational change model may be stalled or thwarted. At Zeta, the CSDs use of groupware
and ITSS was supported by a dedicated technology group. Initially consisting of one developer,
this group grew over time as use of the technology expanded. After two years of technology use,
the group included four full-time technologists who provided technology support for the various
systems that had been deployed within Zeta via the Notes platform. The group also maintained
strong ties with all their users through regular meetings and communications with them. This
dedicated and ongoing technical support ensured that the technology would continue to be
updated, adjusted, and expanded as appropriate.
The value of ongoing support to enable ongoing organizational and technological change was
similarly important in another organization we studied, the R&D division of a large Japanese
manufacturing firm (Orlikowski et al., 1995). A newly-formed product development team within
the R&D division installed its own groupware technology, the Usenet news-system (a computer
conferencing system). Similar to Zeta, the teams use of this new technology also iterated among
anticipated, emergent, and opportunity-based changes over time. Here, a small group of users
who had previously used the groupware technology took on the responsibility to manage and
support its ongoing use for themselves and their colleagues. They tracked technology usage and
project events as they unfolded, responded as appropriate with adjustments to communication
policies and technology functionality, and proactively made changes to the teams use of the
conferencing system to leverage opportunities as they arose.
Global, responsive, team-based, networked–these are the watchwords for organizations of the
nineties. As managers redesign and reinvent organizations in a new image, many are turning to
information technologies to enable more flexible processes, greater knowledge sharing, and
global integration. At the same time, effectively implementing the organizational changes
associated with these technologies remains difficult in a turbulent, complex, and uncertain
environment. We believe that a significant factor contributing to these challenges is the growing
discrepancy between the way people think about technological change and the way they actually
do it.
We have proposed here that peoples assumptions about technology-based change and the way it
is supposed to happen are based on models which are no longer appropriate. Traditional models
for managing technology-based change treat change as a sequential series of predefined steps
which are bounded within a specified period of time. With these models as a guide, it makes
sense — as the European navigator does — to define a plan of action in advance of the change and
track events against the plan, striving throughout the change to remain on track. Deviations from
the intended course — the anticipated versus the actual — then require explanation, the subtle (and
sometimes not-so-subtle) implication being that there has been some failure, some inadequacy in
planning, that has led to this deviation. Indeed, many organizational mechanisms such as
budgeting and resource planning are based on these notions. The problem is that change as it
actually occurs today more closely resembles the voyage of the Trukese navigator, and the
models and mechanisms most commonly used to think about and manage change do not
effectively support the experience of change in practice.
In this paper, we have offered an improvisational change model as a different way of thinking
about managing the introduction and ongoing use of information technologies to support the
more flexible, complex, and integrated structures and processes demanded by organizations
today. In contrast to traditional models of technological change, this improvisational model
recognizes that change is typically an ongoing process made up of opportunities and challenges
which are not necessarily predictable at the start. It defines a process which iterates among three
types of change — anticipated, emergent and opportunity-based — and which allows the
organization to experiment and learn as it uses the technology over time. Most importantly, it
offers a systematic approach with which to understand and better manage the realities of
technology-based change in organizations today.
Because such a model requires a flexible and responsive environment, adopting it implies that
managers relinquish what is often an implicit paradigm of command and control (Zuboff,
1995). An improvisational model, however, is not anarchy and neither is it a matter of muddling
through. We are not implying that planning is an activity which is unnecessary or should be
abandoned. We are suggesting, instead, that a plan is a guide rather than a blueprint (Suchman,
1987), and that deviations from the plan, rather than being seen as a symptom of failure, are to be
expected and actively managed.
Rather than pre-defining each step to be taken and then controlling events to fit the plan, the idea
is to create an environment which facilitates improvisation. In such an environment, management
provides, supports, and nurtures a set of expectations, norms, and resources which guide the
ongoing change process. Malone (1996) refers to such a style of managing as cultivation.
Consider again the jazz band. While each member of the band is free to improvise during the
performance, the result is typically not discordant. Rather, it is harmonious because each player
operates within an overall framework, conforms to a shared set of values and norms, and has
access to a known repertoire of rules and resources. Similarly, while many of the changes at
Zetas CSD were not pre-planned, they were compatible with the overall objectives and
intentions of the departments members, their shared norms and team orientation, and the designs
and capabilities of the technology at hand.
Effectively executing an improvisational change model also requires aligning the technology and
the organizational context with the change model. Such alignment does not happen
automatically. It requires explicit and ongoing examination and adjustment, where and when
necessary, of the technology and the organization. As such, mechanisms and resources allocated
to ongoing support of the change process are critical. Tracking and noticing events and issues as
they unfold is a responsibility that needs to be owned by appropriate members of the
organization. Along with the responsibility, these organizational members require the authority,
credibility, influence, and resources to implement the ongoing changes. Creating the
environment, aligning the technology, context, and change model, and distributing the
appropriate responsibility and resources are critically important in the effective use of an
improvisational model, particularly as they represent a significant (and therefore challenging)
departure from the standard practice in effect in many organizations today.
It is important to bear in mind, however, that an improvisational model of change will not apply
to all situations. As we have noted, it is most appropriate for open-ended, customizable
technologies or for complex and unprecedented change. In addition, as one of our reviewers
noted, jazz is not everyones cup of tea… some people are incapable of playing jazz much less
able to listen to what they consider to be noise. We noted above that some cultures do not
support experimentation and learning. As a result, they are probably not receptive to an
improvisational model, and are less likely to succeed with it. However, as these organizations
attempt to implement new organizational forms, they too may find an improvisational model to
be a particularly valuable approach to managing technological change in the 21st century.
Argyris, C. and Schon, D.A. Organizational Learning, Reading, MA: Addison Wesley, 1978.
DeJean, D. and DeJean, S.B. Lotus Notes at Work, New York: Lotus Books: 1991.
Gallivan, M.J., Hofman, J.D., and Orlikowski, W.J. Implementing Radical Change: Gradual
Versus Rapid Pace, Proceedings of the Fifteenth International Conference on Information
Systems, Vancouver, British Columbia, Canada, December 14-17, 1994: 325-339.
Kwon, T.K. and Zmud, R.W. Unifying the Fragmented Models of Information Systems
Implementation, in R.J. Boland Jr. and R.A. Hirschheim (Eds.) Critical Issues in Information
Systems Research, New York: John Wiley and Sons, 1987: 227-251.
Lewin, K. Group Decision and Social Change, in Newcombe, E. and Harley, R. (Eds.)
Readings in Social Psychology, New York: Henry Holt, 1952: 459-473.
Malone, T.W., Lai, K.Y. and Fry, C. Experiments with OVAL: A Radically Tailorable Tool for
Cooperative Work, Proceedings of the Third Conference on Computer Supported Cooperative
Work, Toronto, Canada, November 1992: 289-297.
Malone, T.W. Private communication. 1996.
McGrath, R.G. and MacMillan, I.C. Discovery-Driven Planning, Harvard Business Review,
72, 1, 1995: 44-54.
Mintzberg, H. The Fall and Rise of Strategic Planning, Harvard Business Review, 72, 1, 1994:
Orlikowski, W.J. Learning from Notes: Organizational Issues in Groupware Implementation,
Proceedings of the Third Conference on Computer Supported Cooperative Work, Toronto,
November 1992: 362-369.
Orlikowski, W.J. Evolving with Notes: Organizational Change around Groupware
Technology, Sloan School of Management Working Paper #3823, MIT, Cambridge, MA, 1995.
Orlikowski, W.J. Improvising Organizational Transformation over Time: A Situated Change
Perspective, Information Systems Research, 7, 1, 1996: 63-92.
Orlikowski W.J., Yates, J., Okamura, K. and Fujimoto, M. Shaping Electronic Communication:
The Metastructuring of Technology in Use, Organization Science, 6, 1995: 423-444.
Pettigrew, A.M. The Awakening Giant. Oxford, UK: Blackwell Publishers, 1985.
Suchman, L. Plans and Situated Actions: The Problem of Human Machine Communication.
Cambridge, UK: Cambridge University Press, 1987.
Zuboff, S. In the Age of the Smart Machine, New York: Basic Books, 1988
[1] Not all goupware technologies are flexible and customizable (e.g., fixed-function electronic
mail systems). We are interested here only in those that are (e.g., Lotus Notes).
Managing Organizational Change
By Michael W. Durant, CCE, CPA
The increased pace of change that many of us have encountered over the past ten years
has been dramatic. During the late 1980s, many of us were grappling with issues that we
had never encountered. The accelerated use of leverage as a means of increasing
shareholder wealth left the balance sheet of some of America’s finest organizations in
disarray. Many of our largest customers, that for years represented minimal risk and
required a minimum amount of time to manage, consumed most of our energy. By the end
of 1993, many of these organizations had either resolved their financial troubles in
bankruptcy court or no longer existed.
Just as we began to think the external environment would settle down and our
professional lives would return to a normal pace, many of our organizations initiated
efforts to improve operating efficiency to become more competitive in the world
Competition has heated up across the board. To succeed, the organization of the future
must serve customers better, create new advantages and survive in bitterly contested
markets. To stay competitive, companies must do away with work and processes that
don’t add value.
This hypercompetition has invalidated the basic assumptions of sustainable markets.
There are few companies that have escaped this shift in competitiveness. Entry barriers,
which once exerted a stabilizing force on competition, have fallen in the face of the rapid
changes of the information age. These forces have challenged our capacity to cope with
organizational life.
Permanent White Water
Things are not going to settle down. Many things we used to take for granted are
probably gone forever. We cannot predict with any certainty what tomorrow will be like,
except to say that it will be different than today.
Peter Vaill has captured the essence of the problem of a continuously changing context in
a compelling image – “permanent white water.” In the past, many of us believed that by
using the means that were under our control we could pretty much accomplish anything
we set out to do. Sure, from time to time there would be temporary disruptions. But the
disruptions were only temporary, and things always settled back down. The mental image
generated by these thoughts is that of a canoe trip on a calm, still lake.
However, Vaill explains, in today’s environment, we never get out of the rapids. As soon
as we digest one change, another one comes along. Usually there are many changes
occurring simultaneously. We have limited control over the environment, but to navigate
the rapids we must exercise skill. The “permanent white water” image has a strong visual
appeal, conveying as it does a sense of energy and providing a visual sense of navigating
on an unpredictable wild river.
Creating the Vision
Vision and leadership drive successful change. As the change agent, first you must create a
vision of the future that is capable of focusing the group’s energy. The vision should
contrast what is with what can be and it must be comprehensive enough to direct
attention at how to bridge the gap to the future.
Change must become a core organizational value using customer feedback, internally
developed organizational improvements and other external feedback. Change initiatives
should also be linked to efforts to improve overall performance and profitability.
Commitment from senior management at the earliest stages of the change process is
required. Managing change effectively requires an understanding of the variables at play,
and adequate time must be allowed for implementation.
Three Stages of Change
To thrive in the chaotic world we live in, we must embrace strategies that have been
developed to successfully manage change. The theory and practice of organizational
change contains elements of both behaviorist and cognitive learning theories. An
investigation into change within an organizational setting reveals a three-stage process of
unfreezing, change and refreezing.
Unfreezing is the first stage of the change process and consist of unlearning past behavior.
The change process begins when the organization experiences disconfirmation.
Disconfirmation is experienced in the form of cognitive dissonance. Cognitive dissonance
is a concept taken from the field of psychology that refers to incompatibility between
two or more attitudes or between behavior and attitudes. Inconsistencies from the desired
state are uncomfortable and we try to reduce the dissonance and thus the discomfort.
Disconfirmation may be caused by external pressures or convincing data from within the
organization. An external example might occur due to pressure applied to senior
management by shareholders to increase the return on their investment. Dissonance may
be generated by internal benchmarking research that reveals areas in the organization that
require attention. If the factors creating the dissonance are relatively important the
pressure to correct the imbalance will be high.
Once a potential problem surfaces an information search begins to determine what action
is required to resolve the issue. If a problem exists, creative solutions are developed.
Support for unlearning develops when existing systems are challenged. Unfreezing
involves dismantling past learning.
The second stage of the change process consist of incorporating new behaviors into
organizational processes. Behavior and ideas that are embedded in the corporate culture
must be replaced. Redirecting people’s attention is an essential part of change. The
development of skills to enable people to do things differently is required. Training must
be provided to insure that employees understand their roles in making change happen.
Processes and people must be aligned to support change. Skills and competencies to
enable people to do things differently must be developed. Employees must understand
the dynamics of the change process and also the functional requirements of the job.
New rules and policies that reinforce the desired ways of operating must be created and
documented. Old customs and norms that reinforce the old ways of doing things must be
replaced with norms that reinforce the new ways. For example, if the organization is
developing teams and moving away from functional departments, then team work across
departmental boundaries should be emphasized. Rewards should be specific to the change
goals that have been set.
Refreezing is the final stage of the change process. It is comprised of reinforcing and
measuring behavior change. After the training requirements are defined, the reward
system, reporting relationships and other systems can be designed to reinforce the new
If the change process requires certain behaviors from employees, then performance
appraisals, promotions and bonuses should be based on the desired performance
outcomes. Creating objective measures for performance will demonstrate your
commitment to the change initiative.
Emotional Phases of Change
Organizational change has an element of loss inherent in the process, and it is a loss that is
often deeply felt by employees. The Kubler – Ross Grief Model addresses the emotional
issues associated with change. The four emotional states experienced throughout the
change process may be expressed by employees in behaviors that are obstacles to the
process of change. By understanding the emotions employees often encounter during
change, you will be better prepared to facilitate the change process.
Kubler – Ross Grief Model
Stage 1
Stage 2
Stage 3
Stage 4
The first emotional state experienced during change is denial. For example, employees
encountering a change initiative might be saying to themselves, “I can’t believe this is
happening to us.” Unresolved fears about the change initiative need to be addressed during
this phase. Fear and mistrust need to be replaced by acceptance. To be an effective change
agent, you should encourage acceptance to change by initiating trust-building activities.
The second emotional state is resistance to the change process. It is common for
employees to begin to resist the change initiative. During this phase, employees attempt
to slow down or derail the change initiative. You must be able to spot resistance when it
occurs and formulate sound strategies for overcoming it.
Resistance is a natural reaction to change, and it can take many forms. The easiest form of
resistance to recognize is those who loudly indicate their dissatisfaction with the changes
taking place in the organization. Soliciting feedback from these individuals lets you know
where they stand, so that you can overcome their objectives.
Employees often resist change through denial. These individuals refuse to acknowledge
that a problem exists. For example, competition might force a business to organize work
around processes to improve operating efficiencies. Functional departments involved in
these processes would be combined. Employees might not see a need for this change. The
reasons for change must be fully explained so that employees understand why it is
necessary to embrace the change.
Another common resistance is exhibited by individuals who willingly embrace the change,
but when they realize that it takes additional time and effort, they begin to undermine the
change process. It is best to slow down and allow people to absorb change gradually
before forging ahead.
Sometimes employees use confusion to postpone change. After explaining the changes
repeatedly, employees ask the same questions over and over again. They may truly be
confused or they may be using confusion as a form of resistance to avoid accepting
The most dangerous form of resistance is referred to as malicious compliance. Employees
enthusiastically support change, but covertly undermine the effort. For example, during
presentations, the questions are polite and employees seem accepting. As you move
forward they act as though they are implementing the new program. Months later you
find out nothing has changed.
How we respond to resistance is very important. Forcing compliance may increase
resistance. Those affected by the change probably know a lot about what is required to
implement something new, and their input is important to the change process. The degree
to which employees will support your new initiatives depends on how many of their
recommendations are used. Compromise can accelerate the change process.
The third emotional state encountered is exploration. If employees are unable to stop the
changes from occurring, they begin to explore their new roles. Both individual roles as
well as the overall role of the group are specifically defined in this stage. During the
exploring stage, it is important that unresolved issues that continue to surface be
addressed. Be alert for employees who remain angry about the change initiative. Those
individuals should be counseled at the first sign of falling back to old behaviors. If trust
has been created among the group, then peer influence can be used to encourage behavioral
The final emotional state is commitment to the change initiative. Mutual commitment is
established for the change effort. Obstacles have been removed and the focus is on
successful implementation of the changes.
Reasons for Failure
Research indicates that two-thirds of all organizational changes fail. This represents a
tremendous cost to companies in money, resources, and time. Several of the most
common reasons for failed change programs include a lack of commitment from the top,
change overload, lack of incentives tied to the change initiative and a lack of training.
Commitment from senior management is required if the change program is to succeed.
People reveal their values through their actions, not their words. Employees infer what is
important from management’s behavior.
Trying to do too much at once is often an obstacle because trying to accomplish too many
activities can create confusion. Helping the group to on well-defined steps that carry them
from one initiative to another will instill a sense of order and confidence in the process.
Often change programs are initiated without changing incentives to reinforce the desired
new behavior. Change is expected, but the old behavior is still being rewarded. The
organization must publicly recognize and reward employees who change by linking
promotion and pay rewards to the desired behaviors. Rewards that reinforce old methods
must be eliminated.
Another cause of failure is that too little attention is given to developing the skills people
require to make a new technology work. The organization must develop experiential
training that provides real time hands-on experience with new processes and procedures.
The physical environment must also reinforce these changes.
Communicate the Facts
Employees view the change process differently. They often view change as disruptive. A
successful change program requires that employees understand why the need for change is
necessary. Employees must buy into the change program. Employees’ commitments
must be linked to the company’s change outcomes.
During transitions, employees speculate about how change will benefit or possibly harm
them. People require more information during the change process. They want to know
how changes will affect them and how to prepare. By providing specific information to
everyone at the same time, rumors can be minimized.
Communicate only the facts. Not communicating to employees when implementing
change programs is the worst mistake a company can make. During times of uncertainty
communication voids are filled with rumors. Communication lowers stress and anxiety.
When restructuring jobs or refocusing the organization’s direction, it is very important to
clarify roles and how they support each other. Role clarification helps raise issues in a
neutral manner and avoids confusion when change is in process.
Change must be continually managed to yield sustained results. Measurement provides a
way to track progress. An effective measurement system would be specific, simple to
understand, creative and involve both managers and employees. The results should be
visually displayed so that employees can track their progress. A consistent process of
measuring the results of the change initiative combined with a rewards program that
reinforces the desired behavior is the backbone of an effective change program.
Michael W. Durant, CCE, CPA is the Director of Credit, VF Jeanswear, Greensboro NC.
He is the former Director of Research for Credit Research Foundation.
Burke, W. Warner, and Bill Trahant,Traveling Through Transitions, Training &
Development, 1996, 50, 37 – 41.
Buchel, Mary, Accelerating Change, Training & Development, 1996, 50, 48 – 51.
D’Aveni, Richard A., Hypercompetition: Managing the Dynamics of Strategic
Maneuvering, New York: The Free Press, 1994.
Galpin, Timothy, Connecting Culture to Organizational Change, HRMagazine, 1996, 41,
85 – 90.
Henderson – Loney, Jane, Tuckman and Tears: Developing Teams During Profound
Organizational Change, Supervision, 1996, 57, 3 – 5.
Hendry, Chris, Understanding and Creating Whole Organizational Change Through
Learning Theory, Human Relations, 1996, 49, 621 – 639.
Kemp, Alex, Aleda V. Roth, Ann S. Marucheck, and Doug Trimble, The Knowledge
Factory for Accelerated Learning Practices, Planning Review, 1994, 22, 26 – 33.
Larkin, Sandar and T.J. Larkin, Reaching and Changing Frontline Employees, Harvard
Business Review, 1996, 74, 95 – 104.
Strebel, Paul, Why Do Employees Resist Change?, Harvard Business Review, 74, 86 – 92.
The Team Killers, HRFocus,1996, 73, 22 – 23.
Vaill, Peter B., Managing as a Performing Art, San Francisco: Jossey – Bass Publishers,
 Copyright 1999 by the Credit Research Foundation.
All rights in this book are reserved.
No part of the book may be reproduced in any manner whatsoever without written
Printed in the United States of America
Credit Research Foundation
8840 Columbia 100 Parkway
Columbia MD 21045
Organizational Change
Management Paper
Your paper MUST follow this outline:
◦ Identify and describe a failed organizational change
◦ Identify and describe one organizational change theory
◦ Apply the theory above to the failed change above
In General
Strict APA formatting
Minimum three professional sources
Full use of in-text citations
8-10 pages on content
Title page
Running head
Table of Contents
Reference page
Due Date
Due by the 7th class meeting at class time
Late papers will suffer a 10\% grade reduction

Purchase answer to see full

Why Choose Us

  • 100% non-plagiarized Papers
  • 24/7 /365 Service Available
  • Affordable Prices
  • Any Paper, Urgency, and Subject
  • Will complete your papers in 6 hours
  • On-time Delivery
  • Money-back and Privacy guarantees
  • Unlimited Amendments upon request
  • Satisfaction guarantee

How it Works

  • Click on the “Place Order” tab at the top menu or “Order Now” icon at the bottom and a new page will appear with an order form to be filled.
  • Fill in your paper’s requirements in the "PAPER DETAILS" section.
  • Fill in your paper’s academic level, deadline, and the required number of pages from the drop-down menus.
  • Click “CREATE ACCOUNT & SIGN IN” to enter your registration details and get an account with us for record-keeping and then, click on “PROCEED TO CHECKOUT” at the bottom of the page.
  • From there, the payment sections will show, follow the guided payment process and your order will be available for our writing team to work on it.