“We’re doing Lean + Six Sigma!” The look in his eyes was confident, with a hint of smugness.
I knew what I was supposed to say… “Well, then, you’re at the leading edge, doing all you possibly could be doing for your organization.” But I’m a poor liar. I couldn’t say that with a straight face. I just sighed and said, “I hope it helps.”
When a hot method becomes the buzz, there are people who think it’s the answer to everything. That causes two problems: One, other important initiatives are displaced. And two, the method is applied to problems it was never meant to solve. When this happens, it can do as much harm as good.
Lean and Six Sigma are two distinct organizational improvement methods that are being combined into an organizational streamlining program. Each has its capabilities and its limits. Let’s take a rational look at Lean + Six Sigma and get a perspective on what they are, and are not, supposed to do.
The Lean method (short for Lean Manufacturing) is a modern version of an old tradition—business process reengineering (BPR). It’s a method to redesign, and hopefully optimize, a workflow and reduce waste. Originally, it focused on seven ways to reduce waste in manufacturing (transportation, inventory, motion, waiting time, over-production, processing efficiencies and defects). In addition to its reengineering roots, Lean employs kaizen style project management—week-long blitzes and quick experiments that speed the process.
All reengineering processes have their origins in a method pioneered in coal mines in the late 1940s by the Tavistock Institute in Great Britain. The method, called “socio-technical systems analysis” (STS), engaged those doing the work in rethinking how the work is accomplished. STS guides workers to design a fresh approach to both the technical system (steps and work-processes) and the social system (communications and coordination).
James C. Taylor (in the United States) and Enid Mumford (in the U.K.) pioneered the application of STS to white-collar work. A few years ago, I spoke with Dr. Taylor about STS and the many subsequent reincarnations (including BPR of the 1990s and now Lean). Too polite to criticize the work of others, Jim described the key lessons of STS that we can use to evaluate newer methods.
First, participation is essential. Many of the recent methods look more like Frederick Taylor’s “scientific management” and 1950s-style industrial engineering, where so-called “experts” redesign processes with little more than token participation from the workers who know how things really get done.
Some BRP advocates would counter that you can’t allow participation if you’re after real savings, since people won’t participate in their own demise. They’re right. Basic change management says you never mix up a downsizing with a positive organizational improvement process. Take your cuts before or after, but not as an outcome of an organizational improvement process. With that understood, there’s little excuse for excluding those doing the work from the redesign of their new processes.
Second, STS deliberately maps the social coordination system just like it does the technical system. STS teaches us that when the social system is not designed alongside the technical system, the result is processes that are streamlined and logical on paper, but so rigid and fragile that the entire organization breaks down when anything unusual occurs (like an unexpected opportunity, a problem or, worse, a disaster).
Third, STS advocates “whole jobs,” where individuals or teams do everything it takes to produce a product (or a module of a product). Recall the well-publicized reorganizations at Volvo, Saab and Saturn plants, where teams assembled cars, rather than each worker bolting on the same part day after day.
The opposite is job narrowing, where workers are expected to perform repetitive tasks in an assembly-line environment. In that environment, people have little identity with the end product, and hence little incentive to work efficiently or do a quality job.
Without meaningful participation, a synergistic “social” coordination system and whole jobs, the people involved become disenfranchised, demotivated or even antagonistic. Instead of kaizen (change for the better), the result is kaiaku (change for the worse). Resistance to change is common, and in some cases so virulent that the workers sabotage the new process. The end result is an organization that’s cheaper but ineffective.
Fourth, Dr. Taylor stressed the importance of a well-bounded process. It’s not “everything these people do.” It’s “everything that needs to be done to create a very specific outcome.” The idea is to redesign processes, not jobs or organizations.
Fifth, in STS, people study the work that needs to get done—the fundamental transformations from raw materials to end product, not the way it’s done today—before they design a new process. They only study the way that things are done today at the very end of the method, to assess feasibility and design the migration process. Dr. Taylor says he found that studying current processes gets people’s minds fixed on the status quo and reduces their creativity.
What about Lean? Well, you can judge for yourself. A cynic might say it’s making all the same mistakes BPR made, but doing so more quickly thanks to kaizen. At least you’ve got a few tough questions to ask your process-improvement consultants.
Six Sigma is a change method that has its roots in the Quality movement, pioneered in the 1940s by W. Edwards Deming and in the 1950s by Joseph M. Juran. (The term Six Sigma was coined by Motorola in the 1980s to define its target for defect reductions while implementing Juran’s techniques.)
At its core, Six Sigma uses statistical metrics to reduce defects in a known process. It describes four steps to process improvement: measure, analyze, improve, control.
For existing processes, this takes the form of DMAIC: define, measure, analyze, improve, control. For new processes, the steps are DMADV: define, measure, analyze, design, verify. What they have in common is the use of measurements to reduce defects.
It has certainly evolved since the early days of statistical quality management. Six Sigma now includes some change management techniques such as root-cause analysis, structure problem solving and meeting facilitation.
Separating the two pieces—the statistical quality control techniques and the change management techniques—is useful. Effective change management can be built into any method. What makes Six Sigma unique is its emphasis on metrics to improve process control.
When to Apply What
Lean redesigns processes for efficiency. Six Sigma optimizes the reliability of processes. The synergies are clear. Together, they add up to highly efficient workflows that produce high-quality products. You certainly can use one without the other. For example, ITIL defines a number of IT service-management processes. In these cases, you don’t need Lean to generate the optimum process. But you can still use Six Sigma to optimize those processes once they’re installed.
The key is knowing when to use either or both. And here’s the punchline: Both these methods are only applicable to well-structured work.
The success stories are centered in manufacturing environments, and for good reason. Both techniques presume that workflows are routine, predictable, stable and can be flow charted. Apply Lean and Six Sigma to a job that involves diverse tasks, relationships and creative problem solving (like what most IT staff do) and you may find you’ve created a very efficient organization that fails to accomplish its purpose.
Furthermore, neither of these methods is appropriate for designing your organization chart. Putting together all the people who work on a given process creates “stovepipe” organizations that replicate skills, reduce specialization, undermine synergies, limit flexibility and ultimately damage overall performance. In healthy organizations, multiple processes cut across the structure, combining just the right skills from throughout an organization into well-planned teams and well-defined work-flows.
Lean and Six Sigma can make certain operational functions within an IT organization more efficient. But these two methods are certainly not appropriate centerpieces of an organizational transformation program.
Click here for a version of this article on the author’s website, with links to relevant white papers, books and other resources.
Dean Meyer coaches CIOs on organizational, political and leadership issues. He listens, and offers perspective with his compelling business-within-a-business paradigm and the common sense built over 35 years in the IT industry. He works with you to plan practical solutions, drawing from a wealth of implementation experiences and proven systemic change processes. For a no-obligation get-to-know-you chat, contact his office at email@example.com or 203-431-0029.
Efficient IT Shops: Lean and SOASix Sigma Comes to IT
Do Process Improvement Programs Inhibit Innovation?