Most engineers consider themselves good problem solvers. And most engineering managers have those positions because they are the better problem solvers among the good problem solvers. When hiring, we actively pursue good problem solvers. And yet, most surveys of what organizations feel they most need rank "Better Problem Solving" #1 or #2. Why?
Because most organizations continue to experience:
A seemingly endless backlog of problems on their past projects preventing engineers from moving to their next-gen projects.
65-75% of their engineering capacity being consumed by rework – re-solving problems they thought they had already solved.
Running into the same sorts of problems on each successive project.
Each time they solve one problem, they seem to cause another problem (or two).
Heated debates in painfully long meetings make it clear there is little consensus – so, as good as each individual in the room may be, it would seem the majority of them must be wrong the majority of the time.
Given that is the consistent experience in organizations, it is little surprise that "Better Problem-Solving" tends to top the list of needs.
Also high on those lists are "Critical Thinking", "Decision-Making", "Collaboration", "Teamwork", and "Creativity" – all things that Success Assured® is designed to improve along with "Problem-Solving"...
This is based on a true story, but all the names and details have been changed...
It is Monday morning and Jon gets called into his boss Jack's office. "Good morning, Jon. We have another big problem with the new camera... customers are reporting dead batteries. We need to solve this fast – our reputation in the market is suffering badly at this point!"
"No problem," Jon replies, "I'm on it!"
"I'd like a solution that I can report at the executive meeting on Friday. I need to give them some confidence that we have this solved."
Jon is one of Jack's best problem solvers, fully embracing the Lean Problem-Solving A3s that the organization had adopted. So, he started by going and looking at the problem and then visually framing the problem description, making clear the objectives of the Problem A3 (of the problem-solving effort).
Almost all problem-solving methodologies emphasize:
Capturing the proper Problem Description without jumping to solutions.
Setting a clear, measurable objective for the problem-solving effort.
Digging to the root cause of the problem before devising solutions.
However, almost all also:
Use a fishbone diagram, like the one shown above, as a visual for getting to root cause. But the fishbone diagram is a 5- or 6-M's brainstorming tool at best. It doesn't allow you to go more than 2 deep from there; yet even simple 5-Why analysis says you need to go at least 5 deep!
Once you get to root cause, they assert you are ready to solve the problem, as if the answer should be obvious once you know the root cause. That fallacy is actually the root cause of most problems' solutions causing other problems!
Knowing the root cause just tells you what needs to change – doesn't tell you what to change it to. We argue that getting to root cause is just the first 1/3 of a proper Causal Analysis! The other two thirds:
You need to map back out from the root causes to everything that may be caused / impacted by changing that root cause.
You need to learn the sensitivities between the root cause and all that it impacts so that you can determine the trade-offs between the different solutions.
In the end, most problems are caused by engineers optimizing one thing, not realizing they are impacting another (that there was a trade-off they were not considering). So, solving that problem without considering the things the original engineer was optimizing is almost sure to just cause some other problem because you are almost sure to be impacting that optimization.
The fishbone diagram was already ill-equipped to do the first third (get to root cause), but it is completely incapable of helping a team work back out from root causes to all of the other impacts, let alone helping the team capture the sensitivities to make the trade-offs visible.
Given all that, it becomes clear why teams of brilliant engineers can actually be so bad at problem-solving – they are using tools and methodologies ill-suited for the job.
Jon had built a "proper" Problem A3, determined root cause, and got his solution reviewed and approved.
Further, the prior Problem A3 that had solved the door popping open problem was in their A3 database – that knowledge had been captured and was available to Jon.
So, where did this effort go wrong?
The first problem is that their problem-solving and causal analysis process does not include working back out to all the potential impacts of changing contact force. And even if it did, that fishbone diagram wouldn't have supported it.
Worse, in the short time frame Jon was given for problem solving, Jon couldn't easily find and pull in the original designers to review his Problem A3.
And he wouldn't have known to do a search on their Problem A3's for battery doors jiggling open. He could have searched for "battery", but then he would have gotten hundreds of matches. He would not have had time to wade through all that. (Any "knowledge reuse" approach based on keyword search will tend to suffer that same problem!)
Our solution starts like most others: with a Problem K-Brief that starts with a Problem Description asking you to fully and visually describe the problem without jumping to solutions. And it encourages you to agree on clear and measurable objectives for the problem-solving effort, scoped properly for the available resources.
However, from there we depart from standard practices...
Our solution is built around the Causal Map tool, which enables:
asking "Why?" five or more times (you can go arbitrarily deep)
getting back multiple answers to each "Why?" asked (arbitrarily broad)
multiple answers that are independent causes ("or"s) or require combinations ("and"s)
Without a visual model that supports all that, you will actually have a tough time getting a team to collaborate and get to root cause on anything with significant complexity.
But that's not enough (that's just the first third)! The Causal Map also enables:
asking "So what?" 5 or more times (you can go arbitrarily far back out)
getting multiple answers to each "So what?" asked (arbitrarily broad)
capturing "So what"s that may depend upon certain other conditions
Without that visibility, you can't efficiently pull in experts from multiple different disciplines to help you identify the other things that you may impact when you try to fix the root causes.
In some cases that might be enough. But in most cases in this modern age when everything has been optimized, there will almost surely be critical trade-offs between the different things that will be impacted. So, to actually solve the problem such that you don't cause other problems, you then need to make those trade-offs visible so that you can pull in the right customers / stakeholders to determine where they want to be on those trade-off curves.
By capturing the actual sensitivities between the different decisions in your Causal Map into computable Relations, your Causal Map becomes a Decision Map from which our software can generate Trade-Off Charts and Trade-Off Solvers to help you do the trade-off analyses needed to make the right decisions in solving the problem.
Most of our problems are fairly complex, meaning we need to be able to navigate a multi-dimensional trade space in that decision-making effort. Our Success Assured® software enables that by allowing the team to easily move between those three different visual models of the trade space, making adjustments in each to what 2D or 3D slices through that multi-D space they want to understand (but can't directly see, since our brains are limited to 3D vision).
Further, our software's visual modeling tools support in-depth reviews and audits by people from different disciplines with different expertise, resulting in fewer errors, better continuous improvement, and more innovation:
Furthermore, all of those visual tools are organized in a K-Brief designed for telling that problem-solving story most efficiently. Each time you review that with another expert, you can be continuously improving its efficiency at telling that story, thereby minimizing the time to bring all future experts up to speed. The compounding effects of that can hugely improve your team's problem-solving.
Finally, the optimization of your delivered products isn't just the quality of your initial design optimization; it is the quality of the optimization done in your problem-solving efforts that are then resulting in engineering changes to those designs. So, it is critical that the decision-making in your problem-solving efforts are able to perform those optimizations with high quality.
The Set-Based computational engine in Success Assured® enables superior optimization within the entire trade space (all infinite points):
We will look at the case where Jon had reusable knowledge from the past design and problem-solving efforts in the next section. Here we'll assume he's solving this problem from scratch...
Rather than a fishbone, Jon would have dug to root cause in a Causal Map, which at first would not have looked a lot different, identifying numerous things that need to be looked at, tested, and validated as causes.
But the causal analysis would have continued digging to all the design decisions that together drive the battery contact force such that the sensitivities could be seen.
From there, they would have been working out from the decisions that they proposed to change, such as putting a shim behind the spring to change the compartment length, to find all the things that might be impacted. They would have then done similar testing and validation on those impacts to understand those sensitivities.
With that testing done and the sensitivities captured, they'd be able to use that Decision Map to generate the Chart to the left here that shows how the sensitivity to Battery Length is impacted by the Spring Length. The longer Spring Lengths are key to de-sensitizing the design to the variant Battery Lengths.
With that selected, Jon could then use that same Decision Map to generate the lower Chart that shows what Battery Compartment Length gets the curve safely between the upper limit due to the battery door and the lower limit due to the electrical conductivity, and cover the full range of actual battery lengths. Without understanding that 4D, multi-relation trade-off, it would be very easy to violate one of those constraints. (And this is a relatively low complexity problem!)
A tremendous amount of valuable knowledge is generated in most good problem-solving efforts. And given the significant effort involved, it is a waste if that knowledge is not easily reused. The key to reuse is that the generic reusable knowledge needs to be separate from the highly situation-specific knowledge. And the mechanisms need to do that automatically – it cannot be an extra effort to make the knowledge reusable. Rather, the natural flow of building the knowledge to get your work done, should capture it in a resuable format and organization. If making it reusable requires extra work, it will rarely be done.
A Decision Map is a collection of related Decisions and Relations that together connect the decisions you can directly control to the customer interests you want to satisfy. The Relations capture the critical knowledge from the different disciplines.
The Charts and Solvers capture how best to see the sensitivities and limits of the trade space and how best to optimize your competing decisions within that trade space to best satisfy your customers (all the stakeholders). From any Chart or Solver, you're always just one click away from the underlying Decision Map that it was computed from.
The Project, Problem, and similar K-Briefs tell the story of how the Charts and Solvers are being used to make the required decisions, based on the underlying knowledge. That may include identification of gaps in that knowledge that should be closed prior to further converging those decisions.
If you have questions, would like a demo, or would like to schedule us to visit you, please email us at Answers@TargetedConvergence.Com. Alternatively, you may call us at 1-888-LRN-FRST (1-888-576-3778). Either way, we'll route you to the right person.
Or if you prefer, you can send email direct to:
Our Sales Team at Sales@TargetedConvergence.Com.
Our On-the-Job Coaching Team at Mentors@TargetedConvergence.Com.
Our Software Support Team at Support@TargetedConvergence.Com.
Our Website Team at Webmaster@TargetedConvergence.Com.
Our Accounting Team at Accounting@TargetedConvergence.Com.
Our Human Resources Team at HR@TargetedConvergence.Com.
After 10 years in Carrollton, we have moved a few miles south to the Dallas Communications Complex in the prestigious Las Colinas region of Irving, TX:
Targeted Convergence Corporation
400 E Royal Ln Ste 290 Bldg 3
Irving, TX 75039-3602
In looking at the "failed batteries", Jon observed that the batteries were fine; the issue was the batteries were making poor contact with the camera. Asking "Why?" identified a number of possibilities, which he went to work confirming.
Modeling shows the reduced spring deflection due to some of the batteries being shorter than spec results in the poor contact.
So, Jon shows that inserting a small splint to increase spring deflection will increase the contact force on the batteries and fix the problem.
Jon presents all of that as a Problem A3 to Jack, who reviews and approves it, and Jon gets to work on the implementation.
Three weeks after implementation, Jack gets a call, "We are getting a lot of complaints about the battery compartment door jiggling open and the batteries popping out of the cameras."
Jack instantly knew the problem – because they ran into that issue during early testing – it actually delayed the initial launch several weeks – evidently, by increasing the force on the shorter batteries, they increased it so much on the longer batteries they have now re-created that problem. Jack contemplates retirement. Sigh.
Jon would have been able to pull up the Project K-Brief associated with that Camera. In it, he would have found any Trade-Off Charts the prior designers felt particularly important, along with the set-based specifications for the product.
However, given his knew knowledge that the design has battery contact problems with shorter batteries, clearly there is a flaw in their Project K-Brief, or the layers of knowledge underneath it. Can Jon find the error?
Looking at their Chart at right, he can see they were only considering batteries down to 50mm; he was holding batteries that were 49.6 and 49.75mm. So, that is potentially a problem. But growing that range down to 49mm, it seems his batteries should work.
At that point, the root cause analysis process is similar to before – he would need to discover the new knowledge that there is a minimum Battery Contact Force to get good electrical contact.
With that learned, he would then add that new knowledge into the existing knowledge such that he has the Charts shown earlier and can then make the appropriate adjustments for the new knowledge, but still leveraging all 3 layers of the existing knowledge, such that no past problems would be re-created.
And, since he had put his new knowledge into those 3 Layers of Reusable Knowledge, now this new problem will never be re-created by others.