Skip to content


July 6, 2008

To continue the analogy from the first post: continuous improvement meant ironing the wrinkles out of the shirt. Reengineering said the shirt is still four sizes too small, so ironing the wrinkles out won’t help—you need to get a new one. Reengineering was therefore a much more aggressive approach, reasoning that the process wouldn’t perform at an acceptable level even if all the wrinkles were gone. So reengineering was about starting with a blank sheet of paper and drawing up the perfect process, without regard to incumbent organizational barriers. This was a very exciting prospect to management team members who were charged with making significant strides quickly, so interest in the methodology blossomed rapidly.

Reengineering was a higher-risk, higher-reward proposition than TQM. The processes in question were typically larger, cross-functional, and of higher visibility within the organization. This meant that successful dramatic redesign would be of immense value to the company, but the obstacles to successfully doing it were also immense. The cross-functional nature of the process to be redesigned almost always meant that some departments would be seen as winners when a process was redesigned and others would be seen as losers. Managing the perceived losers represented a large behavioral challenge for the management team. The skills needed by the workforce to be successful in a reengineered process were often quite different than what the existing workforce was good at. This meant that success would not be possible without managing the workforce’s fear of change and preparing them to succeed in their new roles.

While these were certainly not the only barriers, it is significant that the issues referenced previously were all behavioral in nature. It became apparent early in the reengineering years that technical solutions to technical problems were relatively easy to develop and implement. It was the challenge of dealing with change that often caused reengineering to fail. It has been estimated that 80% of the reengineering efforts that failed were caused by the inability to address the social issues.

A typical reengineering team would be formed to analyze not only a process but the surrounding stakeholders as well. If the process to be reengineered was product development, the team might include representatives from the departments responsible for current execution as well as IT, HR, customers, suppliers—anyone with a stake in the process might be eligible. The thought process of quantifying the current situation, making changes, and measuring improvement was similar to TQM, but the development of solutions followed a much different path. Instead of mapping out the existing process and looking for trouble spots, the team might take out a blank flipchart page and simply map out what the necessary functions of the process were.

This flow does not take the current process into account; there is no mention of who does what nor how they do it. The purpose of this diagram is to note the essential tasks and then determine potential new methods for performing them. For example, the research process might currently be done by the person who generated the idea. This could be changed in many ways. A formal research and development department could be formed, research could be outsourced, research for certain products could be deemed unnecessary, and so on. Everything is fair game when trying to find a reengineering type of solution. After proposing the new methods, the preferred option is selected and implementation begins.

Reengineering unfairly became a euphemism for downsizing in many organizations. The word was trendy, so whenever a company had layoffs it would claim it was because they had become more efficient and label it reengineering. Because of this there was often a negative stigma attached to the word, but many organizations were able to produce dramatic results by applying the concepts. For example, IBM Credit had a process that involved roughly a half-dozen departments and took over a week—simply to tell a customer whether they would approve financing for the mainframe computer they had already decided to buy. A quick overview of the process revealed that only about two hours of work was actually being performed throughout the entire process, and the rest of the time the multiple departments were simply passing the application back and forth.

The cross-functional solution was to break down the departmental walls and train everybody how to execute the entire process. Instead of having many people perform small and separate individual tasks, one person would work the application all the way through. The cycle time shrank from over a week down to just a few hours, delivering the order-of-magnitude reengineering-style improvement. Note that this problem could not have been resolved by a functional TQM team. The focus of the functional team would have been on the processing time of two hours, not the cycle time of over a week. Even cutting the processing time in half would not have had a significant impact on the overall cycle time. And the new process did not necessarily require fewer people, because the tasks being performed were virtually identical to what had been done previously. The difference was that most of the delay time for handoffs had been removed from the process.

Solutions like this one were widespread enough that many organizations realized there were huge gains to be made through focusing on process. But sometimes the cross-functional nature of reengineering improvements caused stress on the current functionally oriented organizational structure. In many organizations this caused a barrier that would force them to rethink how they were set up.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: