Ideas to explore.People to learn with.Better ways to work.

The old adage goes: "A problem that is well stated is a problem half-solved" (Charles Kettering). The other half? It hinges on the ability of problem-solving teams or continuous improvement advocates to determine the factors that influence a well-defined problem statement. Filtering these factors is very challenging; a miss in the determination process could decide the outcome of the solution(s).

The process of determining root causes has taken varying forms from the early stages of the Industrial Revolution to the present. In the Six Sigma or Lean Six Sigma discipline, determining the significant factors usually starts in the Measure phase (the M in DMAIC). During this phase, uncovering the root causes means a rigorous walk-through of the process flow, deep dives on the identified factors, and characterizing the process behaviour with statistical tools. It is critical at this stage to exhaust all potential root causes affecting the focus area of an LSS project, and then to probe these "significant X's" in the Analyze phase (the A in DMAIC). A question LSS practitioners commonly ask is: how many significant X's should there be going into the Improve phase (the I in DMAIC)? Is there a magic number?

One project leader in a big FMCG manufacturing company proved that following the DMAIC process will lead you to the right root causes, and that the power of hypothesis testing helps in the sifting process. The project was about streamlining a process that had been established because of quality issues in the past. Six years earlier, the company's quality group had collaborated with the engineering team to set up an off-line bottle rinsing line to mitigate (if not eliminate) the presence of foreign particles in their bottles. Substantial time and effort had gone into designing, commissioning and installing the equipment, and then there was the labour involved in the whole process, plus operations management time. For years it was part of the end-to-end process, until, just recently, a Lean Six Sigma project leader challenged whether it was necessary. The LSS project team realized that the decision to set up the line was a response to quality issues, and that the root causes of the problem had never been fully exhausted, hence the "band-aid solution". The team collected a tremendous amount of data, applied statistical analyses to it (e.g. hypothesis testing), and concluded which of the root causes were indeed causing quality issues. To the team's surprise, out of the fourteen (14) identified root causes, only two (2) factors had a statistically significant effect on the problem at hand. At first, the LSS project lead was a bit doubtful about the results, saying it could not be possible that there were only two (2) significant X's. But nobody had tampered with the data, and the team had strictly followed the LSS process. The team's subsequent actions to address those root causes included redesigning the packaging, reconfiguring the orientation of raw materials during delivery, and working with vendors on complying with quality standards, among others. By the end of implementation, the significant X's had been addressed, which eventually reduced the need for off-line bottle rinsing. The project team also achieved 140% of the committed annualized hard savings.

Is there a real magic number for significant X's? There's none! There's no such thing as too few or too many significant X's… Following the LSS process will lead you to the "valid" root causes.

I have long been fascinated by how business process improvement and operational excellence methodologies have evolved over the years. In scholarly and academic circles, the discourse about this evolution is called "management fashion" or "management fad", and it traces back as early as the Industrial Revolution of the 19th century. These methodologies evolved with the changing industrial landscape and moved from the manufacturing sector to the services sector. Take Total Quality Management (TQM), which started as an approach to improving overall product quality by empowering the workforce and focusing intensely on customers' requirements. The early adopters of TQM were mainly from the manufacturing industry, but the approach itself is industry-agnostic, so its diffusion and institutionalization in the services sector was seamless. Moreover, TQM became the umbrella program for anything to do with continuous improvement. Approaches and programs of the '90s, such as Quality Circles, suggestion schemes and 5S, crossed paths with TQM and grew into staple organizational strategies for many industries in the Philippines.

It is in the nature of many management fashions that, at some point in their evolution, they come to be used together, not by design but because market needs make it necessary to integrate them. This brings me to the next potential crossroads of two potent approaches to continuous improvement and innovation: Lean Six Sigma and Design Thinking. I have worked in many industries and practiced continuous improvement long enough in my career to say that Lean Six Sigma is a fusion of elements of Total Quality Management, Statistical Quality Control, the Toyota Production System, Total Productive Maintenance and Industrial Engineering. These methodologies have one thing in common: finding ways to make products and services… faster, better and cheaper. Design Thinking, on the other hand, has a similar intent, but its process centres on empathizing deeply with the needs of the end user and developing solutions through prototyping. The Design Thinking literature describes it as a human-centred approach to innovation, one that does not focus on scientific methods or data analysis. The process is more concerned with the customer's experience once they use the solution that comes out of the Design Thinking exercise, and it iterates until the ideal solution is achieved.

So where will the crossroads be? These seem to be two totally different approaches to continuous improvement, problem solving and innovation. Lean Six Sigma is known for relying on empirical data, observable evidence and scientific methods, while the Design Thinking process revolves around empathy for the end user, ideation and prototyping. The answer lies in Dr. W. Edwards Deming's Plan-Do-Check-Act (PDCA) cycle! Both are grounded in Dr. Deming's popular PDCA cycle.

We know that the foundation of Lean Six Sigma's DMAIC methodology is the PDCA cycle. Now let's look closely at the five stages of the Design Thinking process:

The framework on which Design Thinking operates has the same simple construct as the PDCA cycle and closely resembles the DMAIC methodology. Mapping the three models shows how they intersect:

Since Design Thinking is a non-linear process, its elements can be integrated practically with the Lean Six Sigma methodology. In the mapping above, both Lean Six Sigma and Design Thinking have a laser-like focus on the Voice of the Customer (VOC). In Lean Six Sigma, we use techniques such as Kano Analysis or Quality Function Deployment to define our VOCs and CTQs (Critical to Quality requirements). Design Thinking, on the other hand, has a powerful technique for unearthing customers' or users' requirements called Empathy Mapping (I'll write more about this in my next article). Using these approaches in an organized way will make VOC determination more defined, even close to granular. Furthermore, in the Improve phase of a Lean Six Sigma project, the Belt would normally facilitate the generation of solutions, which are then prioritized, tested through experiments (if necessary) and pilots, and measured for effectiveness. These are the same processes as Design Thinking's Ideate, Prototype and Test. I believe it will be advantageous for a Lean Six Sigma project leader to leverage the tools and processes of Design Thinking's Ideate, Prototype and Test stages, especially when project solutions won't need deep mathematical modelling or an experimental design such as Response Surface Methodology.

The synergy of the two methodologies can be used in a variety of business situations, whether in product development and design or in business process improvement. As in any management fashion evolution, the integration of Lean Six Sigma and Design Thinking is inevitable; it's really a matter of when and how it will be diffused and adopted across industries. In my assessment, it's just around the corner…

I was standing in front of an operator, observing the process improvement we had implemented on a production module (a TV line). The project was for a large Japanese consumer electronics company based in Jakarta, Indonesia. While I watched the production process, the operator in front of me began to murmur in Bahasa Indonesia. Apparently, he was complaining about the new production line configuration we had implemented, and he wasn't the only one grumbling. To me, it was nothing; I shrugged and told myself, "Why should I be concerned?" We had achieved a 20% productivity improvement on that project and delivered the savings as promised. The CEO of the company was happy! But looking back, was there anything else we should have done to ease the workers' complaints while still keeping our promise to the CEO, or better yet, to go beyond the target productivity gains?

The management consultant in me focused too much on one persona at the time… and, no surprise, it was the CEO of the company. We designed the processes to achieve the cost savings and productivity targets. We used industrial engineering tools and techniques (including human factors engineering and ergonomics), statistical analysis and the Lean approach to reach our goals. In the process, we relied heavily on our engineering design and our project management and implementation skills, believing that everything would work out our way. We also piloted our solutions with little objection from the control group. We did everything by the book, didn't we? Fast forward several years: I encountered Design Thinking at Big Blue (IBM), where it was then a newcomer in the field of innovation and product and process design. I didn't pay much attention to it, as I was busy spreading the gospel of Six Sigma, Lean, automation and quality improvement in the company. During one of my down times (yes, I did have one!), I came across an article by Tim Brown on Design Thinking, and voilà! The answer to the million-dollar question, "What else should have been done?", was staring me in the face.

Design Thinking was originally developed as a product design and innovation process. It hinges on the principle that the design of products and processes should be customer- or user-centric, or, in Design Thinking terms, "persona"-based. The starting point of the Design Thinking process is the discovery phase, where deeper insights about the persona are unearthed. A variety of methods can be used to gain a deeper understanding of the persona you are designing a product or process for. The more popular and structured approach is Empathy Mapping, a collaborative tool used to organize and synthesize insights into the persona's pain points around the identified problem. Below is the structure of a typical Empathy Map:

As with any collaboration tool, a team is convened to discuss and populate the chart with sticky notes (Post-it notes) that answer questions such as:

• What is the persona saying about their work or process?
• What do they think about the problem?
• How does this persona feel about their process?
• What steps does this persona take to handle the process problem?

The Empathy Mapping session surfaces key pain points that help in the later activities of the Design Thinking process, particularly the "Ideation" (idea generation) phase. To make the discovery phase more effective, the final Empathy Map should be validated by actually observing and interviewing the persona. Whenever possible, the team should conduct a DILO (Day in the Life Of…) of the persona to make the inputs in the Empathy Map concrete.

My earlier projects focused only on what we perceived as effective in achieving the business objectives. As in the consumer electronics project I managed, the solutions were all based on what we knew as engineers. We did use human factors engineering on that project, but it was based on prescriptive standards rather than on the operators' day-to-day circumstances. Worse, we didn't consider the operators an important persona when formulating our solutions. Perhaps by using the Empathy Mapping process and surfacing the pain points of that persona (the operators), we could have generated more ideas, combining improvements that required technical or technology changes with an acceptable working experience for the operators. This could have reduced the complaints from the line, since the manufacturing design would have had an element of user-centricity, and it could have yielded even better productivity and efficiency.

As change agents, we need to be creative and exhaust every possible avenue to drive process improvement. I have run and completed successful business process improvement projects, including the one in this article, but I can't claim that all of them were seamless and problem-free. My moment of serendipity with Design Thinking came too late for me to rectify decisions on previous projects; it was simply a matter of accepting that there is always a better way.

As a Green Belt, the projects you usually lead are "just-do-it" projects where the solutions are fairly straightforward. The necessary action needs no further analysis and is only a matter of implementation.

But occasionally you and your team may face a blank wall. You need to be creative and come up with an innovative solution, generating as many solutions as possible so you can evaluate their viability.

This is where a brainstorming session comes in handy. A brainstorming session generates a workable list that the team can take forward for evaluation.

However, a brainstorming session does not always yield productive results. As a project leader, it is crucial that you steer the team towards a productive session.

Here are some of the most common reasons a brainstorming session might fail, and what you can do to avoid them.

1. Not setting a goal. Your project always has a goal, so why not set one for your brainstorming session? Framing or clarifying the question that needs to be answered might seem obvious, but it is worth the effort to put it up front. What is the goal of the session? Is it to list the top 3 ways to generate website traffic? Is it to list possible enhancements to a new model? Framing the question helps the team decide how much time to devote to the session and establish its success indicators.

2. Not using a method. While a brainstorming session is mostly a free-for-all of idea generation and involves a lot of right-brain thinking, the facilitation process needs structure. This is where your skill as a project leader comes in. Decide on the best tool to facilitate your session. In my experience, the most effective ones are SCAMPER, Mind Mapping, Anti-Solution and Six Thinking Hats.

3. No pre-work done. Some team members might think the session is just a series of rambling and sharing, and some could come unprepared. The best way to start the session and get the ball rolling is to assign a bit of pre-work. For example, before the actual meeting, ask the members to come up with 1 or 2 ideas aligned with the question being asked.

4. No follow-through. The brainstorming session is not an end in itself. Once you have generated a list at the end, you need to follow up to ensure that the proposed solutions are evaluated (there are several tools for this as well, such as the PICK matrix).

5. Too many or too few members. The number of members can ultimately dictate the number of proposals to evaluate at the end. An additional member can have a synergistic effect on the ideas. Too many members, though, can be hard to facilitate, and an hour or two will not be enough to cover everyone. The workable number is around 5 to 6.

6. Too many distractions. Successful brainstorming sessions require focus. The last thing you want is distracted members who keep checking their mobile phones for messages, or members who step out for a few minutes to respond to operational concerns. Implement a closed-door, no-outside-communication policy so that all effort and attention go to the session.

7. Not in the proper mindset. The most innovative solutions require a spark of creativity and ingenuity. They require lateral thinking. You won't know where that insight will come from, but you can prime your team members for lateral thinking by giving them out-of-the-box thinking puzzles ahead of the session or in its first few minutes. Popular puzzles include the Completion Test, the Word Association Test and the Incomplete Picture.

A successful brainstorming session can ultimately determine the best solution to the problem at hand and have a tremendous impact on the success of a project. As a Green Belt practitioner, make sure you avoid the pitfalls above so you can make the most of your session.