The Spectrum of Problem-Solving

by Michael Reames and Gabriel Kemeny - ProcessGPS on August 28, 2013

Linkedin Facebook Twitter Email

  ProcessGPS_-_Spectrum_of_Problem_Solving.pdf (846.2 KiB)

When you’ve got a hammer, everything looks like a nail

“When you’ve got a hammer, everything looks like a nail.” 

Translation: If you only have a certain ability or mind set, you try to apply it to every situation even if that situation calls for a different ability or mind set.

Process improvement can take many forms. As long-time consultants in the field of Six Sigma, we at ProcessGPS have occasionally encountered newly trained practitioners who enthusiastically advocate a Six Sigma (nowadays, Lean Six Sigma) approach to every problem or issue in an organization. It’s unfortunate, because it tends to give the approach a bad name – its adherents erroneously proclaim that there’s only one way to solve problems. A more reasoned attitude considers that there are a number of approaches to problem solving, and the appropriate resolution to every issue or crisis in an organization fits somewhere along a spectrum. Some of those are ripe for a Lean or a Six Sigma approach, but not all.

To avoid considering every problem a nail when we have learned the “hammer” of Lean Six Sigma, let’s review the spectrum of problem-solving approaches, from the very simplest to the most complex.


Managers of many organizations occasionally get so caught up in day-to-day issues that they fail to see obvious, intuitive things that their workers may do to improve operations or to create a more satisfying experience for their customers. In other instances, they lose sight of the marketplace and fail to realize that competitive inroads are making the outputs of their own processes less competitive, even though they are providing the same quality output as before.

As Lean Six Sigma consultants, ProcessGPS even encounters situations when enthusiasm for measuring variation and eliminating waste in a process may initially blind us to opportunities for our clients to make some very good progress simply by doing what’s fast, cheap, and easy to do. These are what we call “quick wins,” and there are two additional characteristics:

(1) The ‘solution’ should be within a team’s control: in other words, there should be no significant change management issues that would make an otherwise easy solution not acceptable to those being asked to do something differently;

(2) The ‘solution’ should be reversible: if we’re acting intuitively, then likely we’re not using data to demonstrate a valid root cause; thus, we’d be good process stewards by ensuring that we are able to reverse to the old status quo quickly if the quick win has unintended consequences and moves results in an unfavorable direction.

“Just do it” efforts can be accomplished quickly, typically in a week or so. The cause is generally known or confidently suspected (thus, the intuitive assurance of making a difference), but often are not actual root causes. For these reasons, this approach is used when managers and leaders are impatient and want quick results; however, they must be willing to accept responsibility for the risks associated with using intuition without supporting data. In our experiences with senior leadership, the urgency to “just do it” begs the question: then why hasn’t it already been implemented before? Often the answer is that they have been too caught up with other issues. However, be aware that the time that managers spend handling other issues may allow sufficient time to gather the appropriate data to prove or disprove root causes (See Lean and Six Sigma approaches below).

Other types of just-do-it efforts start out as more complicated projects (i.e., DMAIC), but early on the team realizes that either the sponsor or the Project Leader has a pre-conceived notion of what the solution is or should be. In the extreme, the solution has been pre-determined, and the leader and his/her team is appointed solely to implement the solution. While this may be appropriate when installing a new server or upgrading technology platforms – it is not considered an improvement effort. Hence, “Just do it.” But a project manager is needed, not an improvement team. 

Actual financial and/or customer benefits may be limited. Still, if one can drive process results in a favorable direction, even only slightly, with an easy implementation, then “just do it!” Quick wins are sometimes known as “low-hanging fruit,” suggesting sweet successes that don’t require ladders or pruning shears to gather. By all means, gather these fruit and achieve quick wins before taking on the more complex issues.


Kaizen is a well-established Lean technique for driving continual incremental improvement. Visualize incremental improvement as small step functions, suggesting a continuing effort to find new ways to increase productivity, remove waste, and become more effective with our processes. As with the entire spectrum of problem solving, front-line process workers are the most qualified to see waste and inefficiency; and they are often the ones to hear the customer complaints. Thus, Kaizen is an appropriate approach for relatively simple, sometimes urgent issues where subject matter experts have good insight, even if they don’t know or agree on the root causes. In contrast to “just do it” efforts, a Kaizen “event” or “blitz” involves diligent and often intensive preparation that may require a few weeks of effort with a manager and an experienced facilitator. The actual Kaizen event engages a team of subject matter experts for 2-5 days – about a business week – followed by expedited implementation of solutions that may take another week to a month. 

Benefits of a Kaizen effort are typically greater than just-do-it efforts, due largely to the increased structure, preparation, and concentrated efforts of the process workers.  Success at Kaizen depends on the expertise of the team, the quality of the limited amount of data used, and a strong, confident facilitator who is well versed in the Kaizen method and deliverables. Perhaps most importantly, in order for Kaizen to produce worthwhile results, it is important for senior management to trust and support the improvement teams, and to have a strong bias for implementing their recommendations.


Compared to “just do it” and Kaizen, Lean efforts are moderately complex. These projects potentially involve a number of sophisticated tools with which an organization achieves process efficiencies. Addressing such issues as lengthy cycle times, easily identifiable waste, and non-value-added activity are ideal for a Lean approach. Typically, root causes are unknown, and use of Lean tools and techniques can assist in identifying obstacles standing in the way of performing the process in the least amount of time and with minimal use of resources.

The time involved in completing a Lean project varies according to its scope and use of tools; however, a typical value stream project may take between one and three months, with some solutions taking longer to implement. Benefits, however, may be significant – any time waste is removed, cycle time is reduced, or internal efficiencies are gained, there is the potential for substantial cost reduction. In addition, no Lean project is performed in a vacuum: customers are always a consideration, and there is the likelihood of increased customer satisfaction with the process output.

As with all other approaches, a critical success factor is the acceptability of the solution to front-line workers. In fact, change management is so important that there is an apocryphal saying from a Master Black Belt: “Very few process improvement efforts fail because of a bad Pareto, but many projects fail because they don’t consider all aspects of change management.”


For many quality practitioners, the “sweet spot” of process improvement is Six Sigma or Lean Six Sigma. So, to be precise, what makes for an appropriate process or problem that lends itself to this type of approach? One characteristic is that the issue being addressed is a chronic one – a problem that has been solved before (maybe several times before), and here we are again, addressing the same thing. This is a signal that the repeated attempts to “solve” the issue has only “fixed” the issue over the short term – the lack of addressing the root cause means that it will re-surface over and over again.

Another characteristic is that the process is repetitive; and the more highly repetitive, the better. While LSS can be used for processes that yield only a few outputs annually, the approach is much better suited for processes that turn out several outputs (products or services) per day or per week. A simple example of a highly repetitive process is the activity of a call center – each call to the call center triggers a process that results in resolution to the satisfaction of the caller (or not). Even medium-size call centers may handle hundreds or thousands of calls in a day, and tens of thousands of calls per month.

Still another characteristic is the reasonable availability of data for ready collection and analysis. One company implementing LSS referred to this as “data due diligence.” When data are not available via automated systems, then manual collection is necessary. The inability or difficulty of collecting the right data is a real obstacle to analysis. Data analysis to establish statistically valid root cause is one of the most critical aspects of a LSS project. Without appropriate data, the team either fails at the effort, or is forced to make decisions intuitively (the “just do it” approach).

Another point here is that Lean Six Sigma emphasizes the importance of choosing the right metrics (output, process, input measures). It is misguided to think that the more measure you collect, the better. A project team identifies the “vital few” input and process measures that they suspect contribute most significantly to output variability. Truly effective improvement teams have the courage to discontinue the collection of process data that are not value-added.

A key aspect of the approach to a Lean Six Sigma project is that variability in the process output tends to create output that fails to meet customer requirements. The variability in the output can be thought of as a result of variability in the process itself and variability of inputs to the process. We denote the output measure as “Y” and process and input measures as “x’s”, and paraphrase this concept in the equation Y = f(x1 , x2, x3. . . xn). The data-gathering effort collects Y data in order to understand the extent of the problem (the output variation and/or the level of customer dissatisfaction), and the “x” data as the causes of the defects that dissatisfies the customer. We have a colorful way of describing this: “Torture the data until they begin to confess.”

Root causes and solutions are unknown, although sponsors, stakeholders, and even team members may have their biases/intuition about what the root causes are and/or solutions should be. The important point, however, is that all are willing to follow the DMAIC process and let the data tell the story. As the data analysis validates the root cause, then whoever intuitively knew it now has the data that backs them up. Because of root cause validation, tweaking a process to drive an “x” in a favorable direction will drive the Y in a favorable direction also.

Due to the chronic nature of the issue, a LSS effort tends to take 3-6 months to generate actionable solutions and improved performance. The advantage of taking this amount of time is that there is a much greater likelihood that the solution permanently resolves the chronic problem. Additionally, the improved process can be properly monitored and maintained by a designated Process Owner. Benefits tend to be higher with this type of effort, because the leadership would have selected this issue as one that will significantly increase customer satisfaction (thus potentially generating higher revenue) and/or reducing internal expenses. ProcessGPS consultants have coached many efforts that have generated financial benefits in excess of $500,000. Although average savings tend to be less, even a handful of projects generating $250,000 in financial benefits will more than compensate for the time and efforts of the project leader, the team, and the coach. 

Many world-class organizations identify potentially important (complex) opportunities for process improvement, and then learn that sufficient data are not available to apply the DMAIC methodology fully. For these critical projects, we often recommend that a representative data sample be collected prior to initiating the project. Often it is worth the investment of time and effort to collect the data and then to apply powerful analysis tools to validate root causes with a high level of confidence. The additional effort significantly reduces the risk of failure of urgent process improvement initiatives.

Critical success factors for successful DMAIC projects include: (1) addressing an important issue that is linked to strategic objectives; (2) scope and complexity of the issue; (3) availability of data; (4) a capable project leader/Black Belt; (5) dedicated and motivated team members; and (6) effective sponsor support.


At the complex end of the spectrum is a design or re-design effort. In problem solving, we occasionally encounter a process that is very poorly defined, or one that happens differently each time an output is required. We call these “ad hoc” processes – non-systematic or not formalized. It’s even possible that they may satisfy the customer, but the very non-systematic nature makes it unlikely that this happens consistently; it may simply be that a customer is flexible, or that a process worker is particularly well skilled to execute this process. Another person executing the process for a different customer may create a very different customer reaction.

In other instances, there may be a formalized process, but the team finds that it is so broken (or so unlikely to be improved to meet competitor performance or customer expectations) that a “clean sheet” approach is best invoked. In other words, the process team would be better off throwing out the old process entirely and re-designing the process with no preconceived notions about how it used to be done. A final example is a process that needs to be created because of a new revenue stream. This could be a new product or service that has not previously been provided, and that needs a process to deliver it consistently to the customer’s requirements.

Any of these situations make a Design for Lean Six Sigma (DFSS or DFLSS) approach the appropriate way to proceed. While many of the tools and techniques from DMAIC may be employed, there are even more that may be used in this more sophisticated approach.

The “data” that are gathered in this approach are customer and competitive data, since any other process data either doesn’t exist or cannot be reliably gathered. Thus, the process is designed with key output (“Y”) data – what the customer requires and how well the competition delivers it – and a process is designed such that the “x’s” – input and process measures – drive the Y to low variability and high consistency in delivering to the customer’s requirements. Design for Lean Six Sigma, through the use of scorecards for each step of the methodology, helps a team to design a new process to a performance level chosen in advance, according to customer needs.

Depending on the complexity of the design or re-design project, a DFLSS effort may take up to 18 months to complete. In some cases, however, narrowly scoped DFLSS projects may be completed in as few as three months. Optimally, the new process functions at high efficiency and effectiveness from the outset, thus justifying the concentrated effort up front. Compared to the traditional approach for developing something entirely new, DFLSS teams spend considerably more time in initial phases so that it’s done right the first time. Thus, it is a superior approach to one emphasizing speed, since speed often results in spending significant effort fixing the inevitable problems that haste failed to anticipate. Paradoxically, it reduces overall development time, in addition to the amount of re-design after launch.


A few final comments on this spectrum of problem-solving approaches:

  1. Each approach uses common sense and practical tools, with a good amount of tool overlap. Project leaders can benefit tremendously by understanding these tools and how powerful they can be when used appropriately. 
  2. Effective project leaders master all (or most) problem-solving tools, and develop the skill to know when and how to apply them, according to the particular circumstances. Too bad, then, that some organizations make strategic decisions to embrace only Lean, or Kaizen, and miss the opportunity to employ the full spectrum of options. And rest assured, the spectrum of problems exist in all organizations. By picking and choosing approaches to implement, the organization effectively creates a hammer for itself.    
  3. Once the tools and techniques are mastered, parts of each methodology (and many of the tools) can be used outside the context of a project and may reveal important process knowledge or even root causes. World-class organizations are able to integrate this attitude throughout the employee body. In particular, we see this mindset evident in many Baldrige award recipients.
  4. Once mastered, the comprehensive set of tools and techniques are a veritable “tool box” of methods for addressing all types of issues. Any given project throughout the spectrum uses a sub-set of tools. The good project leader is able to recognize which tools to employ.     
  5. To emphasize and reinforce, the best projects — using any approach in the spectrum — are linked with the organization’s strategic objectives. By design, this ensures that project success will achieve something important for the organization. Although other efforts may also be worthwhile, limited resources (people’s time and financial outlays) make a strong case for prioritizing activities. This has the added benefit of ensuring senior management alliance with subject matter expertise at the front lines. For more on this important topic, see our article, “Project Alignment, Selection and Prioritization Using Quality Function Deployment (QFD).”

A reference table (provided below) summarizes the spectrum and may assist in guiding practitioners to select the right approach for the right kinds of issues.  Arm yourself with a spectrum of approaches, and not just the “hammer” of Lean Six Sigma! (Click to Enlarge)

Spectrum of Problem Solving

Comments on this entry are closed.

Previous post:

Next post: