Success Assured®

This short 3-minute video is a quick overview on Better Collaborative Problem-Solving:

(but please read the rest of this page for more details and an interesting side story)

ABOUT THE SITUATION

Why are teams of good problem solvers so bad at solving problems?

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.

Here's a list of a few of those studies:

The Automotive Industry Action Group's (AIAG) Quality 2020 report, conducted in conjunction with Deloitte Consulting, identified "Problem Solving" as the #1 most important issue for improving quality. 95% of respondents felt improving problem solving would have significant impact; 69% high impact. ("Poor root cause analysis" was the top cause of poor Problem-Solving.)
The World Economic Forum's 2016 "The Future of Jobs" report identified the Top 10 Skills needed in 2015 and projected to 2020. "Complex Problem Solving" was #1 in both. ("Critical Thinking", "Creativity", and "Judgement and Decision Making" were also on both lists.)
PricewaterhouseCoopers' 20th Annual Global CEO Survey's rankings of most important skills had both "Problem-Solving" and "Creativity & Innovation" on the top of their list at 97%, followed by "Collaboration" at 95%.
The National Association of Colleges and Employers' (NACE) annual Job Outlook survey has had "Critical Thinking / Problem Solving" top their list of essential needs the past 3 years.

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"...

A Related Story...

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).

ABOUT CONVENTIONAL PROBLEM-SOLVING

Getting to Root Cause is Just 1/3 of a Good Causal Analysis!

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.

There are a few additional reasons for bad problem-solving. Most are relatively small compared to the fundamental issues mentioned above; however, there is one particularly worthy of mention: we do not efficiently pull in all the expertise that we really need into the problem-solving discussions. And here are a few of the common reasons for that:

Time. It takes significant time to bring each new expert up to speed on the problem analysis such that they can be effective at finding holes or bad assumptions in that analysis.
Unavailability. Getting on those experts calendars for a big enough block of time can be very difficult. And when your problem is not their priority, often you're the first to get bumped.
Complexity. Even if you manage to get the required time from the required expert, if bringing them up to speed involves navigating significant complexity, you can quickly overload their mental capacity to wade through all that complexity (on something that isn't their priority), and find where their particular expertise can provide the most benefit.
Miscommunication. In a world where you're trying to respect their limited availability by minimizing the time you consume as you try to navigate through the complexity, there is tremendous likelihood for miscommunication where you think they "get it", they think they "get it", and they give you an affirmative answer – when in fact, what they understood is not what you understood, and the affirmative should have been a negative.

Given all that, it is not surprising that a lot of teams don't bother to seek out expertise if they can at all justify it's probably not needed.

Now, imagine there's a solution that fixes that communication problem such that it cuts through that complexity focusing in on he holes where you need the experts' help, thereby greatly reducing the required time to bring experts up to speed, which in turn makes it a smaller block you need to schedule, increasing their availability...

So, what went wrong?

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!)

ABOUT OUR SOLUTION

Successfully Navigating Multi-Dimensional Trade Spaces

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:

When presented a Chart or Solver, if the reviewer wants to understand what those computations are based on, they are always just one button away from a visual Trade-Off Map showing them the underlying Decision Map and how that multi-dimensional trade space is being mapped into the Chart. That makes challenging and auditing the logic of your decision-making quick and easy, and makes continuous improvement efficient.
Further, the reviewers can use that same Trade-Off Map to quickly reconfigure the Charts to show them the limits and sensitivities the way they want to see those. The right 3D slices through the multi-dimensional space may be different for those with different expertise or different focus.
If certain Relations are of concern, it is easy to substitute in an alternative and see the impact. If the impact is small, then the team may gain comfort their decisions are resilient to that uncertainty; if the impact is large, then the team may have the justification they need to close that knowledge gap.
That prior capability is also used to deal with multi-fidelity situations; you can potentially have substitute Relations with different levels of fidelity as appropriate for the situation (e.g., how early in the decision process; availability of knowledge; time constraints for the computations).
Our software leverages strong typing, units of measure, and dimensional analysis to automate error-checking of the end-user formulations, further reducing mistakes, and simplifying “end user development” by automating some of the most error-prone work (like converting between different units of measure).
Our equation editor uses the natural 2D mathematical notation for equations, along with use of visual cues to aid in human reading and auditing of those equations to further reduce errors and improve collaboration and analysis.

All together, that collection of visual and computational tools allows you to cut through the complexity and narrow into the specific relations that need to be understood to make the decisions that need to be made. And that allows the experts you pull in to quickly check what you're using against what they know.

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):

Enables human-in-the-loop optimization that corresponds better to how people need to make decisions, particularly regarding how customers will react
Exposes worst-case limits and safe vs. unsafe regions for making wise decisions, even in the face of uncertainty
Avoids models that miss key anomalies or catastrophic failure points
Enables "eliminate the weak" optimization, which in turn enables efficient convergent decision-making

How should have Jon done it?

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!)

Three Layers of Reusable Knowledge

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.

Decision Maps

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.

Charts & Solvers

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.

K-Briefs

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.

Contact Us

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 prestigious Las Colinas region of Irving, TX:

Targeted Convergence Corporation

320 Decker Dr #254-03

Irving, TX 75062-3999

You can visit (and Like! or Follow) us at our official pages on LinkedIn and Google Maps.

Success Assured®

Contact Us to Schedule a Demo today!

Do you have a past problem causal analysis with trade-offs you can share? If so, send it to us and we'll demo using your own data!

Confidently make decisions you won't need to change...

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.

What if Jon started with 3 Layers of Reusable Knowledge?

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.