What Role Should a Quality Department Play in a Lean Organization?
Dear Gemba Coach,
I really enjoy the passage (found on pages 29-30) in The Lean Manager where you discuss the relationship between a dedicated quality group and the overall quality system in a company. I'm thinking in particular of two quotes. The first: "I want you to shrink the quality department, while also lowering the number of quality incidents to customers." Second: "I don't give a damn about quality procedures or any quality-management systems you might have." How can this be true? How can you improve quality overall while reducing the number of people who are developing policies, supporting training, and doing their best to help the folks who are on the shop floor doing the work? What IS the relationship between the quality department, the quality management system, and overall quality? Does the quality management system even have a place in a lean organization?
Hmmm... first, let me confess that our friend Phil Jenkinson does get occasionally carried away. The Lean Manager is a work of fiction, and we may have occasionally let him act over the top when trying to make a point. Nonetheless, I believe you've hit on a very profound problem in the way that companies organize themselves when it comes to quality programs. Phil’s basic frustration stems from his belief that quality should be everyone's problem, plain and simple. Not, mind you, the exclusive province of the quality department. Phil believes that if the organizational lines are drawn so tightly that roles and responsibilities are overemphasized, the quality issues become the sole responsibility of the quality department. He worries also that if the quality system becomes too integrated, it will encourage people to work with the system rather than go and see at the Gemba. He wants his managers to find the right balance between generating quality expertise in a quality department and quality systems; and developing quality awareness on the shop floor from operators, team leaders, and frontline supervisors.
In any company, lean or otherwise, the quality department will be in charge of (1) inspectors, (2) information systems, (3) standards, and (4) procedures. In many companies I’ve visited, the quality department has become so embroiled in its "system" of procedures and audits that quality staffers lose the perspective of parts and customers. Rigorous compliance to procedures won't necessarily deliver good quality results, nor will rigorous evaluation of processes guarantee improvement. So how can a quality department work in a manner that supports lean?
Right First Time
Firstly, the quality department can act as a barometer. Final inspection operators are part of the quality function, as is the quality reporting system. The quality department should be aware of the hot spots in real time in terms of customer complaints and internal right first time quality. This is not a matter of establishing Pareto charts and conducting quality meetings. This is about being able to identify the areas in the factory that demand specific quality attention because too many problems and defects don't get spotted until final inspection. Pareto head problems are important, but so is the overall number of defects detected at final inspection. Each area is responsible for producing good work Right First Time, so the overall number of issues spotted at the quality wall highlights how well each team builds quality into the process and whether it needs help.
Secondly, the quality department can act as an early warning system. Rather than provide overall reports and audit grades, quality managers can use customer feedback or a quality information system to go straight to the shop floor where there's a problem, and tell the area manager that something is not right. This is not about just walking by and saying "Hey, Joe, by the way your quality sucks this month, see you later in the cafeteria." It's a question of pointing out a problem and offering to help with it. In order to be credible in this role, the quality staffer needs to have a detailed understanding of the problems emerging from this area, and must know exactly where the problems occur in the production process. Experts are called for here - not specialists. There is an old 1930s story about a consultant being called to fix a large complex machine. After looking at it carefully, the consultant draws a chalk cross on the machine and tells the maintenance guy: "hit it there." The machine starts at the first hammer blow, and the consultant asks for $20,000. "Twenty grand to draw a chalk cross!" exclaims the area manager, outraged. "No," answers the consultant. "$1 for the cross, and $19,999 to know where to draw it." This is exactly what is expected from "lean" quality staffers: being able to describe the quality problem on the parts precisely (such as the impact on the function and for the customer) and being able to point out what is out of standard in the production process.
Scotland Yard on Quality
In the case of a large problem, rapid response is critical. The quality department investigators must be able to be on the crime scene right away. Scotland Yard rules apply: if the investigators are not on the crime scene within the hour, the evidence will be lost. Genchi Genbutsu (go and see for yourself facts at the source) is particularly important in the case of quality problems because, as I was recently discussing with ex-Toyota employee Bertrand Humeau from McKinsey, many quality issues stem from a complex interaction between the physical processes and their human minders. Solving quality concerns is possible only when one can see for oneself the conditions which create the problem, as opposed to reading selective and pre-packaged reports after the fact.
Thirdly, quality is everyone's business, not just the quality department. More specifically, right first time is the area manager's direct responsibility. The quality staffer is not expected to solve this problem, which rests squarely on the area manager's shoulders. The only way she will learn how to avoid recurring defects is to have her solve problems now! The quality staffer, however, can significantly contribute in coaching the manager on how to solve the problem. The quality staffer can book the problem solving sessions, know which other stakeholders to include in the problem solving group, and make sure the problem solving methodology is applied rigorously. They can help managers avoid the natural impulse to change the process rather than solving the problems in the existing process. By keeping managers to the rigorous observation and hypothesis testing method, the quality staffer can contribute to both solving the problem and developing local competence.
Here again, expertise is of the essence. As John Shook has brilliantly illustrated in Managing to Learn, A3 problem solving methodologies are as much about knowledge transfer as they are about problem exploration. The A3 step-by-step method is a great way to teach people how to solve a problem without giving them the solution: it's an empowering method. However, it works much better if the teacher already has a good idea of what the problem is and what kind of generic solution to look for. Without that deep knowledge, as many have found out, the method can become a cumbersome exploration of what we don't know, and not so helpful.
The Heart of Quality Management
Finally, in lean thinking, standards and test methods are essential to problem solving. Before looking for solutions we want to know what the existing standard is and how we would test for the solution to see if it's adequate. work standards (including their quality components) are clearly owned by the local supervisor. But control methods for both parts entry and exit are the quality department's responsibility. The quality department must know how to test parts for quality and what are the key quality aspects in every part (some aspects are less influential on the product than others). To a large extent, this is the heart of the quality management system of a lean company.
True, in The Lean Manager, an irate Phil Jenkinson asks the German plant manager to reduce his quality department by a third. What Phil had in mind was a fundamental transformation of the quality department from an army of specialists (people who know about quality systems and procedures), to a cadre of real experts (people who know what a quality problem looks like and where it's likely to come from) with fewer controls on the shop floor (fewer direct control operators). There is no doubt a quality department and a quality management system can have an important role to play in a lean organization in terms of (1) maintaining a quality information system that helps spot problems so that managers can go and see immediately, ( 2) knowing a lot about how to distinguish a good part form a bad part and where in the process problems are likely to come from and coaching frontline managers to quality problem solving and (3) continuously developing knowledge on how to test products and processes, as well as conducting live-tests for an ongoing check that both parts and processes continue to behave in the way they're expected to. And all of this with less resources as well. No easy answers in lean, but it's never dull!
There are so many lean management principles to know and tools to master at the start – is there an easier way to begin?
Dear Gemba Coach,
Isn’t there an easier way to start lean? For a beginner, it seems like such a mountain to climb – all these things to know, tools to master, counter-intuitive principles to grapple with. Can’t we make access easier?
What can we do to instill some passion in leadership about our lean implementation?
Dear Gemba Coach,
I’m in a company that is trying to implement lean but sees it simply as a series of rote steps to iterate without the sort of passion by leadership inherent in a successful journey. What can we do to instill some passion?
Is agile project management simply lean thinking applied to software development?
Dear Gemba Coach,
You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?