As referenced in Chapter 1, total quality management (TQM) was a term that became popular in the mid-1980s. It was generally thought that the term originated with the Department of the Navy when it was trying to spread successful application of a set of principles in one location to multiple locations. A formal definition of the term comes from the Japanese Union of Scientists and Engineers (JUSE). They state that:

There are several key parts of this definition. The first is that TQM was systematic. It involved applying the concepts of continuous improvement(referenced in Chapter 1) throughout the organization. The tools and techniques of TQM were both qualitative and quantitative. The statistical methods for evaluating data (statistical process control, or SPC) were a key component of the system, as were the process mapping and analysis tools such as flowcharts, cause-and-effect diagrams, and so on. The tools were used in the context of PDCA (Plan-Do-Check-Act, sometimes also referred to as PDSA, or Plan-Do-Study-Act). The planning portion of the methodology held that analysis of certain processes should be performed, data collected, and theories advanced regarding what needed to be changed to deliver improved process performance. The do involved actually implementing the identified process change. The check or study component required evaluation of the change to determine whether it was successful and should be continued, modified, or rejected, and based on this analysis the team or company would act. Instilling the PDCA mindset in the workforce led to more efficient and effective processes; teams would constantly discover the problems in the processes within their functional area and find ways to solve them.

Successfully instilling this mindset into the workforce, however, could not be done without serious support from the management team. This is why the TQM definition stated that the entire organization had to be involved and that the goal was to achieve company objectives. Assigning employees the task of improving their processes required the cooperation and support of management, because process improvement does not come cheap. Management had to be willing not only to allocate resources to support process improvement ideas, but also to carve time out of the work schedule for employees and teams to focus on improvement. This was almost countercultural at the time, at least in the United States. The prior focus of “get it done and out the door as fast as you can” was replaced by “get it done properly so we don’t have to do it again later.”

A third key component of the definition was the customer satisfaction piece. TQM forced companies to think about customers instead of getting too absorbed with meeting internal targets. And the final statement regarding delivering at the appropriate time and price reinforces the notion that the definition of quality was total and process-focused. It would be impossible to deliver quickly, cheaply, and up to customer standards without strong process performance.

A typical TQM team would be assigned a problem, such as how to improve the yield on a certain production line. They would analyze the process and determine that the old machine routinely leaked oil on the pieces as they went by, and this was causing a 6% loss in productivity. The team would investigate the causes of the oil leak and further recognize that it wasn’t the machine, but rather the faulty maintenance practices regarding the machine’s upkeep. They would alter the practices, teach the maintenance people the new methods, and then collect data to substantiate that the 6% productivity gain was in fact realized. They would then put in place whatever safeguards were necessary to ensure that the new level would be maintained, and then they would disband.

This process was typically very formal at first. In other words, teams had to be approved by a management group, their progress carefully monitored by a facilitator, and their results documented for all to see. If the organization continued with TQM implementation over a number of years, the structure would gradually become unnecessary. Employees and teams would naturally be expected to think about process and solve problems using the methodology, without the need for so much formal supervision.

TQM was a popular methodology for several years, but unfortunately it was not always successful. There were multiple reasons for this, including but not limited to the following: (1) the initial structure needed to support the methodology was often too expensive and complicated to justify; (2) application of the statistical tools to non-manufacturing applications wasn’t properly implemented; (3) lack of process knowledge contributed to selecting inappropriate topics for teams; and (4) poor relationships between management and nonmanagement stifled interest in team participation. The list is long, but the most relevant issue to the process wave was this: TQM wasn’t set up to deliver order-of-magnitude types of improvement. To borrow a baseball analogy, the focus was on hitting singles versus hitting a home run. Changes that patched holes in existing processes were nice, but the speed of business was accelerating so rapidly that it became clear that a more aggressive type of process improvement would be needed.

Reengineering burst onto the scene in the early 1990s, popularized in the book Reengineering the Corporation, by Michael Hammer and James Champy. The focus of reengineering was dramatic and radical process redesign. It was the home run methodology many organizations with legacy process problems were looking for. To continue the analogy from the first chapter: 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. Product development might be summarized as shown in Exhibit 2.2.

Figure 2.2. Product Development Process: Main Steps

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.^[1] 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.

The IBM Credit example is an excellent illustration of the complexities that large-scale process redesign can impose on an organization. The solution sounds simple: just train everyone in six different departments to execute the entire process from beginning to end. Great idea, but what are the job descriptions for the new roles, who do the people report to, should a new department be created?—the list of organizational issues is long. This type of problem was the genesis for the third wave of process management, known as process-oriented organizational design. The purpose of the third wave is to set up an organizational structure that enhances the focus on process. This enables the key business processes within the organization to operate at maximum efficiency, delivering value both internally and to customers.

The trick when designing an organizational structure around processes is not to lose the functional benefits completely; there needs to be a balance between the two. Just like a heavily functional organization can suffer from process inefficiency, a totally process-oriented organization can suffer from lack of functional expertise. An interesting example of a process-oriented design comes from the State of Michigan Office of Retirement Services (ORS).

ORS was faced with significant challenges in the late 1990s and early 2000s. Impending retirement of the baby boomers threatened to overload processes that were already being stressed to their breaking point. Because the organization didn’t expect to have the opportunity to increase staff to handle the additional workload, its only real option was to improve process efficiency. Several reengineering projects got things off to a good start, and then they redesigned the organization to fit the model in Exhibit 2.3.

Figure 2.3. Office of Retirement Services Process-Oriented Organizational Design

The top of the diagram lists the Executive Director and his direct reports, just like any other traditional organizational structure. In this case the reporting functions were HR and Finance, Operations, Customer Service, and IT/Reengineering. Each of these functional areas had a director, middle management, front-line management, and employees. Reporting relationships were vertical/traditional, so ORS retained its emphasis on functional expertise.

What makes this example nontraditional is the process component illustrated on the left-hand side of the diagram. There were several groups of cross-functional processes, shown in the diagram as flowing from left to right. The organization created the titles of Business Process Executive (BPE) and Business Process Owner (BPO) to ensure that the core processes got the attention they needed as well. A BPO was someone with broad subject matter expertise who was responsible for delivering process results. A BPE was a member of the executive team who did not have a direct link to the process. In other words, their function was not part of process execution. The BPE’s responsibilities were to ensure that necessary cooperation and collaboration between functions happened so the overall process performance would not suffer.

For example, processes 1.1 Employee Reporting and 1.2 Employer Payments were closely related. Each is a core process rooted in operations. Therefore, the BPO title is listed under the Operations functional area, to note that the role is seated here. On the far left-hand side of the structure are the letters CS. This is to illustrate that the Director of Customer Service is the BPE for this group of processes. Because employee reporting and employer payments do not touch customer service, this manager will not be tempted to play favorites when overseeing process performance; the BPE can look out for the good of the process as opposed to worry about the impact on his or her own function. This setup also forces the management team to learn about processes from other parts of the organization, contributing to their ability to make better management decisions for the organization overall.

The end result of the ORS redesign was properly aligned leadership and employees, clear accountability for meeting customer needs, and dramatic process improvements such as those shown in Exhibit 2.4.

The challenge of the third wave was documenting the benefits of the redefined organizational structure. In the ORS example, processes were being reengineered as the structure was redesigned and implemented. Skeptics could claim that the impressive results were generated by process redesign and would have occurred regardless of organizational structure changes. Because the challenges of changing a structure were so formidable, many management teams determined that it wasn’t worth the risk. While this reluctance to modify the structure to fit new processes surely caused some reengineering efforts to fail, the precise number of efforts failing because of ill-matched structure and process is unknown and unknowable.

The significance of the third wave, however, was that more and more companies started to realize that process performance was a key factor in their high-level decision making. Gone were the days when an executive team could simply look at financial reports to determine how the organization was performing. Process thinking had to be integrated into all management decisions, up to and including the structure of the organization. The final frontier was planning for the future of the organization by proactively leveraging process performance.

The fourth wave is where process performance is integrated into strategy. This means not only identifying the process weaknesses that have the most strategic significance and fixing them, but also understanding how process strengths can be better leveraged. The traditional strategic process in many organizations followed the thought process illustrated in Exhibit 2.5.

Figure 2.5. The Strategy-Process Link

The links described in the diagram illustrate the traditional view of strategy. It was customary for the leaders of the organization to develop a strategic plan that would include a host of improvement initiatives. Some of these would inevitably be process improvement–type projects, whether of a continuous improvement or reengineering nature. Process improvement teams would then analyze the situation and develop new process innovations to help the organization run better, and these innovations would be integrated into the processes. But the fourth-wave picture is a bit different. It adds the link shown in Exhibit 2.6.

Figure 2.6. The Process-Strategy Link

The dark arrow illustrates that in the fourth wave, process can be used to drive strategy. In other words, superior process performance could drive the future of the organization, helping capture new customers and markets, establishing additional profit centers, enabling the organization to provide more complete solutions by controlling more links in the value chain, and so forth. Fourth-wave companies are uniquely positioned to control their own destiny.

The next chapter introduces the strategic assessment process. The questions asked and techniques described within the process-focused assessment are designed to promote fourth-wave thinking. Examples of companies that have flourished will be provided in the context of illustrating how the assessment tools can work.