Do you solve problems like a NASA rocket scientist?

By Corey Pappel

Most manufacturing and industrial businesses are not solving their toughest problems because common problem solving tools are ineffective at addressing the hardest, most technical problems. By attempting to solve challenging technical problems with ineffective tools organizations create beliefs that hard problems are “impossible” to resolve instead of bringing in the necessary tools and horsepower to overcome them. Organizations like NASA and SpaceX that face some of the hardest, most technical problems use the same, less common approach.

To understand why NASA needs a more powerful approach it helps to understand the complexity of problems they solve. A NASA space shuttle is one of the most complicated machines on (and off) the planet. A space shuttle has over 2.5 million parts, over 230 miles of wiring, and tens of thousands of valves, circuits, sensors, and other components. When something goes wrong with a NASA rocket, there are hundreds or thousands of potential root causes. To make NASA problems even more complex, problems often happen thousands of miles away which limits observation and the ability to collect data.

When confronted with their hardest technical challenges NASA, SpaceX, and other rocket scientists turn to the same powerful approach called Fault Tree Analysis (FTA). FTA involves following a logical deductive progression from the initial problem to what simple yet exhaustive set of factors (“faults”) can directly impact it physically. This deductive problem deconstruction is iterated as many times as required until the root cause is found.

While FTA is mainstream for deeply technical organizations like NASA, industrial companies generally only apply it during dire catastrophes like the BP Horizon or Fukushima Nuclear Plant disasters, when solving a technical problem rapidly is paramount. When approaching operational problems, industrial problem solvers instead prefer tools like Brainstorming, 5 Whys, Fishbone Diagrams, and DMAIC. This difference in application results because traits that are critical to the powerful and robust nature of Fault Tree Analysis make it less palatable to leaders and practitioners in industry.

When you compare NASA’s FTA to common industrial problem solving approaches, you see several fundamental differences that contribute to the difference in their gap in effectiveness and industrial adoption.


Maximalist – Industry tools generate as many potential ideas, solutions, and variables as possible.

Bounded – Industry tools have defined finish lines. For example, structures imply that once you’ve reached your 5th Why or 6th Fishbone you’re finished the exercise.

Brainstorm Driven – Industry tools rely on group brainstorming of ideas (5 Why, Fishbone) or variables (DMAIC) to generate lists of potential root causes and solutions.


Minimalist – FTA uses first principles to examine as few variables as possible at every point in the process

Unbounded – FTA fault trees can extend and progress as long as necessary to find a root cause

Logically Driven – FTA uses deductive logic to progress systematically towards a root cause.


There are many perceived strengths that lead industrial problem solvers to not use FTA and leaders to not expect to see FTA in practice. While these reasons are believed to be managerially valid, they come at the price of underperformance and blindness to the potential within an organization. Let’s explore a few perceived reasons an organization may prefer standard industrial tools:

They involve as many people as possible – Many companies use brainstorming as a way to engage the broader organization. Group engagement builds alignment behind solutions that allow the organization to push forward. While this approach makes managerial sense, it assumes the brainstorming process can uncover the correct solution. For hard technical challenges typically nobody knows the solution at the on-set because the problem is new, so brainstorming activities more commonly create alignment behind guesses and pet projects rather than logically deduced solutions. By using a formal deductive process FTA is specifically designed to be only logic and fact-driven. This intentionally excludes the biases and motivations of individuals to expedite problem solving by ensuring only fact-supported problem sources are investigated.

They generate many ideas for solutions – When faced with a problem to solve, most leaders expect their organizations to take action and implement a solution. Given this metric for success, problem solvers are incented to use approaches that quickly generate lists of work to do so they’re seen as effective. For hard problems, the solution usually isn’t known at the onset, so when attempted solutions fail, the problem either gets the next-best idea at additional cost or gets relegated to the list of problems that are “just part of the process” and can’t be fixed. Conversely, the deductive FTA process invests resource first into understanding the problem to ensure a solution is correct before trying to implement any fix. From a short-term perspective FTA can be seen as resource-intensive without a defined end in sight. However, when you take the view that all problems are solvable, solution-generating approaches that fail to solve the problem on the first or second try ultimately consume much more bandwidth and money than a structured FTA. By focusing upfront on detailed problem exploration rather than solution-generation, FTA increases confidence that a single solution will actually resolve the problem in the long term.

They are broadly accessible to all levels of technical ability – FTA’s deductive process involves systematic application of logical and scientific principles which can be complex to understand and even more complex to effectively facilitate within an organization. Given its difficulty and rigor, it’s understandable that practitioners might shy from using FTA in favor of simpler tools. When individuals lack the training or horsepower to apply FTA appropriately they’re unlikely to apply it correctly if they use it at all. Additionally, when a practitioner is inexperienced at solving technical problems with FTA they’re unlikely to seek out technical problems where FTA may be required. This selection bias reinforces cultural beliefs and narratives that problems are “unsolvable” rather than just “really hard.”

Ultimately, the goal of every approach is to resolve problems. Organizations know that failed problem solving wastes resources and demotivates employees. The less visible but often more costly price is the cultivation of cultures that write off hard technical problems as “unsolvable.” By failing to solve hard, technical problems, ineffective problem solving efforts create narratives that certain problems are “impossible” or are “just part of the process.” These narratives arise because political, organizational, and capability factors often make it easier to rationalize failure as proving a problem is “impossible” than to admit that a dedicate effort was ineffective. This rationalized belief can permanently stop the organization from attempting to fix the problem, even if it may have a simple solution that just eluded a team applying an inappropriate tool.

When the problems get tough and technical in nature, leaders must reconsider the use of standard problem solving tools in exchange for more powerful approaches like FTA or risk constraining their organizations to never reach their full potential.


Like this article? You might like: 

You are just guessing; stop it!

To Solve a Hard Problem, Change These Two Mindsets

Reducing Quality Failures by 90%