Examples of Organizational Change

Home

Organizational change can be thought of as stretching the goals and improving the way an organization thinks about and does its work. Such efforts range from the very large – such as merging two business units – to quite small – such as changing the focus of the company newsletter to be less of a gossip sheet and more of a business tool.  Examples of organizational change efforts could include implementing an Enterprise Resource Program (such as SAP or Clarify), changing the compensation structure to reflect new corporate needs, implementing computer-based-training, or creating a usable knowledge management system. 

The following descriptions of organizational change efforts help illustrate their variability and the importance of understanding how to manage them successfully.

A company, with a diverse and successful personal care product line, launched a program to understand and anticipate evolving consumer needs better.  The leadership did an excellent job of creating the “burning platform” or explaining why the company needed to understand consumer needs better to stay in front of the competition.  Realizing the importance of empowerment, they drove the responsibility of implementation down to middle level managers.  However, they did not provide a clear vision or framework of what they expected.  This resulted in “turf battles” among market research and human factors and sales teams.  Each felt better equipped to understand consumer needs.  These turf wars put significant drag on the program.  They moved the focus away from creating a better understanding of consumer needs to focusing on which team could dominate the others without challenging its own ideas on consumer needs.

An OEM manufacturer – with a large market share - was instituting a customer mandated quality program.  This manufacturer had built its reputation on its ability to respond quickly and to add features to meet customer's needs.  Its responsive reputation was being drowned out by quality problems – some of which were visible to the customers' customers.  To continue to enjoy its market position, it had to address its quality problems.  They began the quality program with a huge kickoff – inviting customers and employees.  In the subsequent few weeks there were posters and articles everywhere on the quality program.  Employees were interested in increasing quality, but few really knew what was expected from them.  Further, leadership had problems walking the talk.  While they talked quality, there were no quality metrics presented at periodic reviews, and they continued to emphasize schedule and new features.  There were no financial rewards or formal recognition for managers and employees who improved quality.  The infrastructure to track quality – such as tools for capturing variation or statistical programs for keeping track of the variation – was not in place. After over a year, the quality program hardly got off the ground, and this adversely impacted the manufacturer's market share.

A large corporation with a global customer base and semi-autonomous business units realized that they were duplicating work, as customers in different locations were demanding similar products.  They felt that a knowledge management system would help them keep track of similar projects and allow them to leverage the learnings and avoid duplication.  They assigned the task to the Senior VP of IT.  His team immediately began the process of adapting a commercially available “knowledge management” system.  There was no research into understanding what aspects of the corporate culture limited knowledge sharing.  The system was made available in all the business units.  However, nothing was done to foster knowledge sharing.  There were no rewards and recognitions for sharing knowledge.  Few employees saw value to sharing knowledge – in fact they felt that it might be giving away their edge

to bonuses and promotion within the corporation.  Further there  were no metrics in place to measure the value to the corporation as a whole of sharing knowledge – so the business case could not be made for the knowledge management system.  It became a little used – and expensive – piece of software.

A large high-tech company had an organizational change imposed on them when two of their largest customers merged.  The two customer companies had very different reputations, corporate cultures, and approaches to business. The biggest change within the high-tech company was the effect on the two account teams that served these two customer companies. Each account team reflected the values of their respective accounts.  No one – not even in the two customer companies – knew which corporate culture the merged company would reflect.  The high-tech company prepared for inevitable changes in the new merged customer company.  They appointed an account executive who had worked in the past on both account teams and who was respected by both teams.  She immediately commissioned a study of the strengths of each account team and of their attitudes toward the “other” company in the merger company.  She made sure that every salesman's opinions were heard.  She made herself responsible to foster contacts between the two account teams and had a “knowledge-base” created to help the two teams get acquainted with each other's customers.  She was careful to structure financial rewards to support cooperation between them, and dealt quickly with problems.  By all traditional measures, such as sales, profits, and customer relations, the organizational change was successful.

A medium sized software development firm in a very competitive environment introduced a new step in the development cycle to improve quality – code inspections.  The affected population – the designers and testers – recognized the value of code inspections.  They saw the value to both to quality and to improving all designers' familiarity with software that they did not design, but with which they might have to interface.  Everyone affected was given training in how to conduct and participate in code inspections.  However, like most quality efforts, code inspections require a fair amount of data collection and analysis.  The firm failed to provide any tools or automated way to collect and collate the data.  There were designers who actually created and made available such tools on their own, but the company did not recognize them for their spontaneous efforts.  Further, the firm did not add any time in the design schedule to accomplish the extra design step.  This lack of infrastructure and poor recognition for extraordinary efforts quickly soured the affected population.  This organizational change had clear business value and eventually was implemented.  However, properly supported, it could have been accomplished in one design cycle and less than one year.  Instead, full implementation dragged on over several years and impacted many design cycles.

These examples highlight the variability of changes within organizations.  They also illustrate that managing organizational change requires attention to many interacting factors. The Tipping Point is applicable in the pre-planning or early planning stages of a change effort – or at a time when leaders are re-evaluating their current change strategy. It sparks conversation about how change happens and what factors affect change. This is valuable valuable because it fosters and informs more extensive, realistic planning.