The Biggest Misconception in Selecting a Problem Solving Methodology
Here at CAEDENCE we’re big fans of structured problem-solving. A quick search will yield at least half a dozen problem-solving methodologies. As a rule, adherents to each one will claim it’s the best one, and sell it as the latest ”shiny object”. Invariably, they’ll disparage all the other methods. That’s nonsense!
Over the years we’ve been exposed to Six Sigma, Juran, Deming PDCA, 8D, Dale Carnegie, A3, Shainin, and more. Each technique works pretty well, and has been demonstrated many times in a wide variety of industries and circumstances. At the core they are all essentially the same!
Each approach relies on an underlying logical flow that goes like this: [a] make sure the problem is clearly defined; [b] be open to all sources of information; [c] vet the information for relevance and accuracy; [d] use the process of elimination to narrow down all possible causes to the most likely few; [e] prove which of the suspects is really the cause of the issue; [f] generate a number of potential solutions; [g] evaluate the effectiveness, feasibility and risk of the potential solutions; [h] implement the winning solution(s); and [i] take steps to make sure your solution(s) don’t unravel in the future.
The differences between the paradigms resides in supplementary steps and toolkits. For example, 8D contains the important “Interim Containment Action” step (to protect the customer from the symptoms of the issue before the root cause is known) that is not generally seen among the other systems. Meanwhile, Six Sigma is loaded with statistical data analysis tools generally absent from the others. Shainin provides good tools around looking at best and worst performers and component swaps to find the issue. These are apparent but not critical differences - hardly reason to reject any approach outright.
To become the most effective problem solver you can be, avoid zealotry – use whichever of the paradigm you prefer (after all, the logic and steps are so similar) and borrow supplementary steps and tools as-needed from any of the other approaches - mix and match as needed. Remember, your goal is to solve problems – it would be foolish to ignore a potentially helpful tool because it happened to be part of a different toolkit. Use what works best for your particular situation.
Note: If you are implementing structured problem-solving across an organization, we do recommend you pick one paradigm as “primary” - this is because each approach comes with unique jargon and it can be confusing when there are several phrases for what is essentially the same concept - you want to make sure your team members can communicate seamlessly. You can (and should) introduce the supplementary steps or specific tools from the rival systems as-needed, but do it within the framework of your chosen primary approach.
We’re here to help solve your toughest problems, and set up systems to prevent future problems. Message us any time.
Your team is marching through the tools of your company's chosen problem-solving approach. This is time not spent on growing your business or delivering cost reductions. Yet your customers are suffering, and they're not shy about letting you know it! Why isn't it working?
Does your team struggle to deliver the kind of rapid and effective problem-solving your business requires? Can you really afford the unhappy customers, wasted engineering hours, cost of poor quality, and lost opportunities? Use the Visual 8D™ / Visual CAPA™ approach by CAEDENCE.
Negative customer experiences can destroy your business! Have you been faced with any angry customers this year? CAEDENCE's Visual 8D™ / Visual CAPA™ enhanced problem-solving toolkit was the answer. It integrates seamlessly with your existing problem-solving approach and systems.
Your primary role as a manager is to ensure your team’s success. Internalize this. Make sure your team members know this. Build an environment of trust and collaboration. A direct report of mine would frequently leave me out of the loop as problems escalated, preferring instead to “work harder”. It was clear that he felt uncomfortable delivering bad news to me (his boss) when things were not going according to plan. Let me tell you the rest of the story.
I was struggling to get updates from my regional project management directors. Sensing my frustration at having to constantly repeat my (apparently futile) requests to the team to provide their updates consistently, my boss suggested, “If you want something done, schedule it.” He meant that if updates are needed at a specific time, actually schedule them directly on people's calendars, making the expectation and reminder "automatic" each month, and emphasizing the importance of the updates by turning them into meetings – people tend not to show up empty handed to meetings where they're expected to present. Scheduling removed a bit of "friction" and created a sense of urgency that resulted in real progress. Amazingly, they didn’t miss any updates after that point!
One of the best bits of advice I received when I first became a manager was to “delegate a task when your team member is 70% as good at it as you are, not 99%.” Many times, people are promoted to management positions because of their strong performance as individual contributors, but then they’re shocked to learn that a whole separate set of skills is required to succeed in their new role. Delegation is high on this list of new skills. Delegation means handing off tasks for someone else to do them. A common mistake is to only hand off a task when the team member is as good as you are at it. This is a trap! While it may seem like a good idea to protect the quality of the task, it doesn’t work in practice.
Don’t be fooled by the latest fad in project management, Agile. Agile is pitched as a revolutionary method, but the fact is, it simply DOES NOT GET THE RESULTS that visual waterfall approaches do. Period.
We see team after team fail using Agile methods, for very specific reasons. Let’s look at the 6 painful TRUTHs of using Agile methods. You don't need the latest fad, you need to use the best practices to manage a project to completion.
Problem-solving methods haven’t changed in over 20 years, and some methods have been around for 30-50 years without significant improvement. CAEDENCE has released a novel improvement to problem-solving that overcomes shortfalls in existing methods.
Applicable to all structured problem-solving approaches, Visual 8D™ enables teams to execute the familiar problem-solving steps (with no additional effort), while capturing plans and progress in easy-to-follow diagrams. Visual 8D™ puts teams in the position of providing answers to management and customer questions before being asked, resulting in improved control of the situation and minimizing time wasted on extraneous actions.
Being action-oriented is a good thing, right? Well, yes and no. There's a big difference between learning and adjusting quickly ("failing fast") and wasting time and resources by "rushing off half cocked".
Executives and teams alike are eager to be (and be seen) "doing something", but they often fail to recognize the distinction between 'activity' and 'progress'. As a result, they act upon the first reasonable idea that comes along. The trouble with acting on the first reasonable idea is twofold. First, there might have been much better ideas, and second, once you start working on the first idea, you stop looking for the better ones. Outcomes are often sub-optimal – problems not solved, product not launched, etc.
Want to dramatically improve your team's odds of achieving consistently strong outcomes? Next time everyone's ready to run with the first reasonable idea, set aside just 30 minutes and challenge the group with this 3-step process.
I was asked to take over the redesign project as lead engineer after a team from another site had struggled and failed to meet the financial target. The assignment came with one condition (which, in hindsight, should have been a big red flag): “Don’t let the original leader know he’s not in charge anymore, we need to keep him engaged.” If I had it to do over again, I’m quite certain we could have delivered on the goal in half the time if team leadership had been clearly defined.
Management made several fundamental errors with this team: (1) They should have recognized the original project was not on track and intervened to course-correct much sooner. (2) They should have trusted the original team leader to act professionally and contribute despite being displaced, rather than feel it necessary to deceive him. (3) They should have made the leadership responsibilities unambiguous to everyone involved.
