Performance Improvement: Ain’t Misbehaving: The Behavioral Side of Improvement Work

Improvement practitioners (in which we would include BPM, Lean Six Sigma, IT, OD, OCM and any other disciplines that engage in the design or implementation of performance solutions for organizations) are equipped like line technicians for power companies. They wear figurative utility belts bristling with tools and supplies, they are adept at running up poles and connecting wires. They are tool-savvy and tool-adept. But they are not necessarily good at dealing with the so-called soft stuff: the behavioral aspects of improving organizations. But without solutions for the human side of change, well-intended transformations get derailed and good solutions tend not to take hold or be sustained.

So this is the first Column in a series in which we will address the behavioral side of improvement, an arena in which we must succeed as practitioners and for which we should be as well-equipped as we are for the technical aspects of performance improvement.

What do we mean by the behavioral side of improvement? It is often called “culture” or the “people side”, and “leadership”—those things that are not necessarily addressed by the improvement methodology itself, whether that's Lean Six Sigma, reengineering, or technology development. It's what people—leaders, followers and the specialists who lead or support the projects—should do versus what they actually do (or fail to do).

Is there a need to better understand and deal with the people side of change efforts? There certainly is from our own experience, but there is also plenty of evidence…

The Focus on Failure

The literature on failed organizational change is stupendous, with improvement efforts a large part of the focus. There have been dozens of studies, articles and books on the causes of failed organizational change, starting (from what we can tell) in the days of reengineering up to the present. In 1993—the same year that Hammer and Champy published their blockbuster book on reengineeringi–there were cautionary articles like Thomas Stewart's with the daunting statement that “By one estimate, between 50% and 70% of reengineering efforts fail to achieve the goals set for them.”ii But that was only the beginning; what followed was an avalanche of investigationiii questioning the validity of the reengineering phenomenon. Our guess is that this happened because the premises of reengineering were so in-your-face, because of the instant praise and hype lavished on its authors, and because reengineering soon became a cover story for mass layoffs.

By now that failure rate of 70% has been repeated so often (most recently at Gartner's latest BPM conference, where the theme was “big change”iv ) it's not questionedv, but numerous academic studies have verified the likelihood of failure for any big organizational change is disturbingly Many of these studies have found the same dismal failure rate for many types of business changes other than process improvement or reengineering—for example, restructuring, and mergers/acquisitions. If you add technology implementation failures, the examples balloon to thousands.vii And the failure rate is sometimes even worse than all others, as high as 94%.viii

There are similarities in most of these studies:

  • The failure rate varies little from one study to another, even with those that take pains to distinguish degrees of failure, from complete crash-and-burn projects to ones that achieve their goals but at a much higher cost and effort than estimated. But after subtracting the unqualified successes, the projects that failed to one degree or other tend to add up to that same 70%.
  • The focus tends to be on implementation, probably because it is often only at that point it becomes evident an improvement effort is about to go south. Yet many of the studies point out that the causes of failure are to be found all along the way, from inception of a project to its conclusion
  • The causes of failure identified in this body of literature are also remarkably similar. They tend to boil down to a few things:
    • Failures of leadership in initiating, championing and supporting change efforts;
    • Failures in change management (somewhat the same as the first cause, but the culprits include more than senior leaders) in dealing with people issues, especially employee resistance to change, stakeholder management planning, and an over-reliance on just “instructing” people in what they need to do;
    • Inadequate planning, structuring, funding and resourcing of projects.

In other words, it's management that screws up and people who resist what is going to hurt them. And we would agree, heck, yeah, it's management. Hammer and Champy themselves pointed fingers at management when the second-guessing about reengineering started. Champy was quoted as saying, “I didn't see management to be the obstacle it has been… the redesign, as brilliant as it may be, doesn't get results because of managerial thought and ideology. Either top management isn't aligned behind the change, or others are threatened by a loss of power.”ix And Hammer acknowledged, “I wasn't smart enough about that. I was reflecting my engineering background and was insufficient appreciative of the human dimension. I've learned that's critical.”x Hammer and Champy later wrote separate books explaining their ideas about process management.

The Failure of Change Management

The revisionist thinking about reengineering triggered another business fad—that of “change management”. One of the most prominent writers on the subject is John Kotter, who wrote his first article on the subject in 1994xi specifically as a reaction to reengineering. He followed up with several highly regarded booksxii on change, and has been followed by many others.

The approach used by Kotter was to propose a set of principles for the leaders of change, and his books are built around those broad, but vague, principles. And thus he set a standard imitated by the other authors of change management books. All of them tend to be rather general, pitching sets of principles or practices, but with little detail about how exactly to execute change management. Instead the advice is about things like developing and communicating a vision of the future.

There is almost universal acceptance of the need for change management in today's organizations—many of which have a cadre of employees involved full-time in roles that purport to perform change management functions. But what does change management mean to those practitioners and those organizations? What is it they actually do?

Most theories of change management focus on what their adherents call “resistance to change”, the notion being that people tend to dislike change and find ways to fight it or ignore it, so the efforts of change management experts is to find ways to overcome that inevitable resistance. The underlying attitude toward the people being affected by the change (sometimes called “targets”) ranges from patronizing (“Poor dears. They just can't let go of their paradigms.”) to coercive (“Change happens. Get with the program or get out.”)

What this fixation on resistance has resulted in is a heavy emphasis on leadership support, communication and training in—what else—resistance to change. About the only real tools in the typical change management expert's utility belt are a communication plan and a stakeholder management plan, where the change expert's attention is focused is on “messaging” and “leadership” with little or no concern about the actual nature of the change. Whether the coming change is a good idea or a bad one, the change expert's job is to get people to buy into it, like it or not (and we know they won't, so that's why you need us).

So do we think change has to be managed? Of course, but it is far more than developing communication and stakeholder management plans, far more than providing vague theories and homilies about the agony of change.

We would argue that one reason for the lousy project success record cited above is the lack of attention paid to behavioral issues until the implementation stage has been reached in many projects. Most improvement methodologies lack any tools for identifying and dealing with behavioral needs or requirements during the majority of a project—during the definition, analysis and design phases. It is not until almost forced to acknowledge the need for addressing people needs—that is, when it's time to implement the solution—that there is a reluctant admission that “Now we gotta deal with the soft stuff.” And even when the need is understood, there is often little that practitioners know to do on the behavioral side.

The Failure of Improvement Methodologies

An examination of extant improvement methodologies will reveal scant tools and techniques for identifying and addressing the cultural, or behavioral, side of projects—other than things we've already mentioned, such as leadership events to spell out the vision, communication plans and training in change theory. It's not that there is anything wrong with vision statements, communication or training but they are all what we call “antecedents”. They happen before the desired change is taking place—they don't actually deal with the on-the-ground things that people are doing differently—and thus they are relatively weak in causing the change they hope to cause.

There is also lots of evidence that the most prominent improvement methodologies underestimate, skip or mishandle the behavioral issues. Part of that evidence is all of the above—that is, the various studies cited in this article pointing to weaknesses in leadership and cultural issues as major reasons for project failure. These weaknesses are repeated in articles and studies of specific improvement methodologies such as Lean Six Sigma.

For example, Marvin Wurtzl, an instructor for the BPM Institute, points out failures of leadership in Six Sigma project that echo the views of Kotter, Davenport, Strassmann, etc., but he adds failures by the practitioners—the Black Belts and Master Black Belts who guide and support the improvement efforts, a particular negative behavior being to focus excessively on statistics while “failing to appreciate the complexity of dealing with people.”xiii

In a study of the challenges in deployment of Lean Six Sigma projects, author Robert Crescenzi found once again that poor leadership and inadequate attention to “culture change” were the biggest obstacles to success.xiv

A Few Points about this Series

In summary, here is what we will try to achieve in this series of articles:

  • Given the weaknesses of improvement methodologies when it comes to culture change and people issues, we will step past theories about change and provide some real tools for addressing those issues.
  • We will look more closely at a few popular approaches to improvement–including Lean Six Sigma, BPM and technology deployment—and recommend how to integrate into them some practical tools for dealing with cultural and people issues and needs.
  • Finally, we will address the notion of transforming an organization's culture and how that can be done using a behavioral approach.

A lot to promise for just three articles, so we know in advance that we can't say everything we might want to say but we'll do our best.

Bottom line principle for this series: Behavior can be reengineered—must be, in fact, to achieve any lasting organizational change.

iHammer, Michael & James Champy, Reengineering the Corporation: A Manifesto for Business Revolution (New York, NY: Harper Business, 1993).

iiStewart, Thomas A., “Reengineering: The Hot New Managing Tool,” Fortune, August 23, 1993, pp. 41-48.

iiiMoad Jeff, (1993), “Does reengineering really work?”, Datamation, 1 August 1, 1993.
Hall, J., Rosenthal, J. and Wade, J., ”How to make reengineering really work”, Harvard Business Review, November-December, 1993.
King, Julia, “Reengineering Slammed”, Computerworld, June 13, 1994.
Caldwell, Bruce, “Missteps, Miscues: Business Reengineering Failures”, InformationWeek, June 20, 1994.
Strassmann, Paul A., “The Hocus-Pocus of Reengineering,” Across the Board, June 1994.
Economist Newspaper Group, “Reengineering Reviewed”, The Economist, June 1994.
Coulson-Thomas, C. (Ed.), Business Process Reengineering: Myth and Reality, Kogan Page, London, 1994.
Lloyd, Tom, “Giant with Feet of Clay/ Tom Lloyd Offers a Contrasting View of Business Process Reengineering”, Financial Times, December 5, 1994
May, Thornton, “Not-So-Successful Reengineering”, Byte, December 1994.
Davenport, Thomas H., “Will Participative Makeovers of Business Processes Succeed Where Reengineering Failed?”, Planning Review, January 1995.
Ettore, Barbara, “Reengineering Tales from the Front”, Management Review, January 1995.
Davenport, Thomas H., “Reengineering: Business Change of Mythic Proportions?” MIS Quarterly, June 1994.
Davenport, Thomas H., “The Fad that People Forgot,” Fast Company, November 1995.
Zack, Jeffrey, “After the Reengineering Hype, An Ambiguous Legacy”, American Banker, April 1, 1996
“Is Re-engineering A Fad?” Chief Executive, No. 113, May 1996.
Mumford, Enid, et al, “Business Process Reengineering RIP,” People Management, May 2, 1996
Galliers, B., “Reflections on BPR, IT and Organisational Change,” Information Technology and Organisational Transformation, John Wiley & Sons, Ltd., 1998.

ivHill, Janelle, “Digital Business: From Process Improvement to Big Change”, Gartner 2014 BPM Conference, Las Vegas, December 2014

vBillows, Dick, “Why Do So Many Projects Fail?”, Project Management Institute online, April 27, 2014.

viDeloitte and Touche, Survey of 400 U.S. and Canadian CIO's, 1993
CSC Index, “State of Reengineering Report”, 1994.
Caron, Raymond J., “Business Reengineering at CIGNA Corporation: Experiences and Lessons Learned from the First Five Years”, MIS Quarterly, September 1994.
Clemons, E. K., et al, “Identifying sources of reengineering failures A study of the behavioral factors contributing to reengineering risks”, Journal of Management Information Systems, 1995.
Grover, Jeong, et al, “The Implementation of Business Process Reengineering” 1995
McCarthy, Allan J., The Transition Equation: A Proven Strategy for Organizational Change, Lexington Books, 1995.
Smith, Douglas K., Taking Charge of Change, Addison-Wesley, 1996.
Kettinger, William J., “Business Process Change: A Study of Methodologies, Techniques and Tools,” MIS Quarterly, March 1997.
Murphy, Felicity, et al, “Reengineering in Australia: Factors Affecting Success (1998)”, Australian Journal of Information Systems, 1998.
Al-Mashari, Majed, and Mohamed Zairi, “BP implementation process: an analysis of key success and failure factors”, Business Process Management Journal, Vol. 5, No. 1, 1999.
Broadbent, Marianne, Peter Weill, and Don St. Clair, “The implications of information technology infrastructure for business process redesign.” MIS quarterly, 1999.
Gore, Edward W. Jr., “Organization Culture, TQM and Business Process Reengineering: An Empirical Comparison”, Sacred Heart University, 1999.
Vakola, Maria and Yacine Rezgui, “Critique of Existing Business Process Re-engineering Methodologies”, Business Process Management Journal, Vol. 6, No. 3, 2000.
Mourier, Pierre and Martin Smith, Conquering Organizational Change: How to Succeed Where Most Companies Fail, CEP Press, 2001. (This book lists failure rates for dozens of different types of project studies.)
IBM Institute for Business Value, “Making Change Work…While the Work keeps Changing”, Executive Report, IBM Global Services, August 2014.

viiWailgum, Thomas, “10 Famous ERP Disasters, Dustups and Disappointments”, CIO Magazine, March 24, 2009.

viiiDitmore, Jim, “Why Do Big IT Projects Fail So Often?” InformationWeek, October 28, 2013

ixLancaster, Hal, “Reengineering Authors Reconsider Reengineering”, Associated Press, January 17, 1995.

xWhite, J.B., “Next big thing: re-engineering gurus take steps to remodel their stalling vehicles”, Wall Street Journal, November 26, 1996

xiKotter, John P., Leading Change: Why Transformation Efforts Fail,” Harvard Business Review, fall 1994.

xiiKotter, John P, Leading Change, Harvard Business School Press, 1996.
Kotter, John P. and Dan S. Cohen, The Heart of Change, Harvard Business School Press, 2002.

xiiiWurtzl, Marvin, “Reasons for Six Sigma Deployment Failures”, BPM Institute website.

xivCrescenzi, Robert, “Maximizing the ROI of a Lean Six Sigma Deployment”, iSix Sigma Magazine, May/June 2010.

Alan Ramias & Paul Fjelsta

Alan Ramias & Paul Fjelsta

Alan Ramias is a Partner of the Performance Design Lab (PDL), a consulting, coaching and training company that specializes in organizational performance improvement and an instructor with the BPM Institute. He brings 30 years of consulting experience in the analysis, design and implementation with organizations in Asia, Europe and North America. He is a co-author of the books White Space Revisited: Creating Value through Process and Rediscovering Value: Leading the 3-D Enterprise to Sustainable Success. Before becoming a management consultant, Alan was an instructional designer, training manager and organizational development manager at Motorola. Alan joined The Rummler-Brache Group (RBG) in 1991, and led improvement projects, became a Partner and Managing Director of Consulting Services at RBG and was responsible for selecting, training and overseeing RBG’s consultant teams. Paul Fjelsta is a Founding Partner of accomplir where he specializes in developing integrated, next-generation process improvement frameworks that link Behavioral Leadership & Behavioral Change Management tools with Lean Sigma (DMAIC) and Rummler Process Methodology (RPM) toolsets to create "Sustainable Lean Sigma" and "Behavioral BPM". These blended toolsets enable client ownership of the organizational, business process, technology, and behavior changes required to bring about timely, sustainable and measurable business results.

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.