Thursday, April 8, 2010
The Nine Pitfalls of Organizational Change
David Chaudron, PhD
The Wall St. Journal has many times reported on the struggling efforts of companies trying to effectively change their organization. With such national focus on the needs of organizations to respond to today’s volatile climate, why all the failure?
Based on our experience, there are several significant causes to an organization's change efforts to stumble or stagnate. You can use this information to avoid these pitfalls, or recover from them if you have fallen in.
This problem occurs so often it isn’t funny any more. A manager hires a consultant to help implement buzzword X. After conducting a thorough analysis, the consultant says, “You don’t need X. You need buzzword Y instead. The manager then replies, “That may be, but I already told my boss that we are implementing X?” A common example of this is when an organization hires someone to conduct a skills training course, but the lack of skill isn’t what is causing the organization’s problems. Many organizations put in one IT system after another to solve specific issues, but never realize the lack of integration among the systems they have is the primary cause of their problems.
More fundamentally, however, is the mismatch that occurs on a larger scale. Organizations often use small-scale, incremental techniques such as Six Sigma, when instead they need to evaluate their reactions to future scenarios of a radically changed business climate. They may need to divest themselves of a money-losing division instead of pouring more money into an industry that is dying a slow death.
Not making systemic changes
Management must realize that to fully implement change, satisfy its customers, and promote teamwork in the entire organization, often wrenching systemic changes must be made: Profit sharing may be introduced; individual performance appraisals may be radically changed or eliminated; organizational structure may be realigned away from functions (production, quality, engineering) to a customer-, process- or geographic-based structure; information may be given to employees formerly reserved for senior management; and significantly more authority may be given to line employees.
If management does not align these systems, the effect will be like Dr. Doolittle's Pushme-Pullyou” animal (a horse with two heads, each pulling in the opposite direction). Each system (rewards, structure, information, etc.) is tugging the organization in a different direction. The result will be much struggle and confusion, but little success.
Overuse of process teams
Some organizations treat Six Sigma teams (SSTs) like candy: They want dessert before having dinner.
I know of a 3000-person organization with over 70 current SSTs) working on a variety of issues. The organization avoids measuring their success, provides them little technical support, and still has not addressed "dinner" of the systemic changes (see next section) needed to support them. This implementation strategy has a high risk of failure, and organizational change will probably not become an integral part of their culture.
This problem occurs when, paradoxically enough, an organization achieves successes with its first teams, or hears about wild successes of other companies. They then buy a canned training program, or hire a trainer to setup their programs. Much training occurs and many SSTs formed. With various degrees of management support, these SSTs attack a variety of problems. Unfortunately, because of unclear long-term plans, and the lack of system changes, (see next section) many of these SSTs fail. As a result, the organizational change effort may stagnate, and once ardent supporters become disillusioned.
In addition, management often delegates a problem to a team as a way of avoiding hard management or personnel decisions. For example, one manager in a software company assembled a SST because the customer complained of too many bugs in the product. In addition, the manager needed a reporting system to evaluate the progress of the bug fixes. The SST quickly realized that this was not a "process" problem, but a personnel problem: One employee of the manager just wasn't doing his job. The SST knew this, and the manager knew it. Unfortunately, the manager was unwilling the confront the problem, and hoped the SST would find away around it.
Not making decisions up front
Many organizations need to design the architecture of their quality effort. If they do not, they risk pouring time and dollars into an effort that will eventually collapse. Among the decisions that should be made up-front, before implementing a quality effort are: the measures of success; the degree of employee involvement; the depth and breadth of implementation; and the techniques to be used. As someone once said, If you don't know where you are going, you may not like getting there.”
Caught between the square peg and NIH diseases
Many organizations buy canned implementation efforts that describe for them, step by step, what to do. This square peg approach is often not appropriate for the round hole of the organization. This kind of effort can often lead to the overuse of SST's and the problems with mass training (see the section on training).
On the other hand, organizations can also become infected with the not invented here (NIH) disease. They insist in reinventing the wheel when it isn't necessary to do so. I know one consultant who made a lot of money because of this disease. The rivalry between two manufacturing plants belonging to the same company was so fierce that they refused to talk to or learn from each other. This is despite the fact that they were located only a few miles apart. The consultant made his money by helping one plan with organizational change, and then driving to the other plant to do the same thing. The secret to implementation is not to choose between one disease and the other, but to decide what aspects of implementation can be bought, and what aspects need unique solutions agreed upon by management and employees.
If you wish employees to use their training, organizations must train them in skills specific to their needs just in time to use them. Too many organizations have spent untold thousands of dollars and hours on training employees on concepts they may never need. If they do need these concepts, they will need refresher courses because their training was long ago. Because mass training puts such a burden on organizational resources, not all members of work teams are trained at once. As a result, some know what to do but others do not, which causes more confusion.
The no top management support excuse
Supervisors and line employees have often complained that they do not receive management support for their efforts. I believe all parties are at fault for this problem. Management may not fully realize what they specifically need to do to support SSTs, and SSTs choose to 1) work on problems that don't interest management or 2) don't get the proper authority and specific support from management before they start their efforts. This no management support is caused by unclear or unknown expectations.
An interesting problem in organizational change is hero worship. There are Deming worshippers, Crosby worshippers and Covey worshippers. These cults of personality often get in the way because any concept not uttered by one's hero is suspect and probably not true. Organizations can often get into this labelitis by swallowing a buzzword and avoiding any concept not labeled as such. One example of this happened earlier this month: A client said he wasn't interested in becoming a “team-based” organization because it wasn't “Six Sigma.”
Much the same thing has happened in Latin America with the word “reengineering”. The word has been misapplied so much that any mention of it is returned by a look of disgust. To properly implement organizational change, organizations must look beyond the label, and ask serious questions about what changes are needed and what they should do about them.
Not measuring results
No only do organizations not measure results, they often desperately try to figure out if they were successful after organizational change has already taken place. This is the messiest way to determine if change happened, because sometimes 1) the data should have been gathered before the organizational change happened and can’t be collected afterwards; 2) politics play their role as those asking if the change was successful may have hidden agendas seeking to either justify what has already been done or destroy what is taking shape.