A running list of problem solving techniques I use at work and in my everyday life.
I currently (18 July 2021) work as an equipment engineer at a major semiconductor company's fab. My days are often filled with problem solving (PS): why did this happen, how can we prevent this, etc. And yet I continually find myself missing or overlooking things that are related to problems I've solved before, because I either forgot or just didn't apply a certain technique. I distinguish between two types of PS: reactive and proactive. Reactive PS (RPS) involves finding why something suddenly stopped working. Proactive PS (PPS) involves finding how to accomplish something. Some techniques overlap between the two, but will only be entered in one. For techniques that fit equally in both or equally in neither, they will be placed in the Other Techniques section.
This is my attempt to minimize future occurrences of that. The following techniques come from myself or other credited resources. Some work better in certain instances than others. Examples are provided for each, mostly in the context of my job. "PSer" is individual problem solver.
Assumptions make PS easier because they eliminate variables to consider during the process. However, many times assumptions prove to be false, leading the individual to look at other non-issues. Assumptions may be explicitly stated or subliminally assumed, the former of which is a bit better, as it gives more chance for someone else to bring up issue with it.
Writing down a complete list of assumptions before PS can be helpful, albeit a bit awkward and momentum-stopping. Can any of these assumptions be quickly verified? Have any of these assumptions been false in the past, whether in this system or another?
What has changed within or happened to the system since this problem arose? Was anything non-standard performed? Was the work performed standardized (i.e., anyone who does it does it the exact same way)
Often times, maintenance on the system can cause a problem to occur, whether due to the operator performing the maintenance doing something incorrectly, a replacement part being bad, etc. If there is a clear change in the before-after values/conditions/etc, then whatever occurred on that date is worth looking into.
Partition testing, or partitioning, is stepping through a procedure item-by-item, line-by-line, piece-by-piece and verifying the outcome. This is fairly tedious (depending on the system) and in very tedious circumstances, should only be done after other, easier options have been attempted.
My personal example involves particles, which are a big no-no in the semiconductor world. My tool continued to have particle issues, despite us verifying a few different mechanisms of the tool. To partition test, we would have done the following ad nauseum (movement refers to movement of the FOUP—there are around 10 to test), beginning with n = 1, where n ≤ [number of items/lines/pieces to test]:
Note that partitioning only works for individual or grouped pairs of components within a system. If two components only normally work when paired with one another, they must be paired during partitioning.
As discussed in the Standardization section below, systems should be as identical as possible to one another to improve PS capabilities. In some cases, identical systems is not possible, but can still be helpful. With two systems—A and B—that are identical with the exception of one component, if A begins acting up while B continues to operate fine, efforts can be focused on A's different component.
The Ishikawa diagram, also known as a fishbone diagram, lists the causes of a problem by the following topics:
This forces the PSer to examine each topic's possible causes, instead of glossing over or not even considering them.
The five whys method continually asks "why?" (it can be more than five times) until the root cause of a problem is found. 3x5 Why extends it to a manufacturing and quality setting with the following three questions:
The first question finds the root cause of the problem itself. The root cause should be as low-level as possible. The second and third questions take both the root cause and the answers to all of the "Why?"s and looks for the evident gaps in the system that were not able to detect the failure. In the end, a few improvements can/should be made: the procedure and the detection.
Standardization helps future troubleshooting efforts by minimizing variability of variables. The ultimate idea of reactive PS is finding the variable that is causing the problem. Finding this can be done two ways: getting lucky by guessing the variable or systematically eliminating variables until only the problem one is remaining. The latter approach is significantly easier when there are fewer variables involved. The lower number prevents time from being wasted, and some variables can be immensely complex, causing undue headache when trying to relate them back to the original problem. For example, if a procedure calls for 10 items to be completed, it is much easier to pinpoint the issue if there is variation on two items rather than all 10.
Another aspect of RPS is sorting through data, often massive amounts of it. Standardizing data collection and reporting makes data analysis much easier.
Finally, standardization between systems allows comparison between the two, something that's not nearly as useful when the systems are slightly different. If they are different, the number of differences should again be minimized.
Notes: Tradecraft Primer
Link: Tradecraft Primer: Structured Analytic Techniques for Improving Intelligence Analysis