Five Fundamental Principles of SPPS (Systematic Problem Solving Process)
A structured problem-solving framework emphasizing objectivity, firsthand observation, delayed solution identification, fact-based cause-effect analysis, and persistent root cause inquiry.
THE IDEA
Five Fundamental Principles of SPPS
-
Be objective; think like a scientist. Begin with a theory you are willing to test, rather than an answer you are determined to defend. Look for evidence that challenges it as well as evidence that supports it.
-
Go to where the problem occurs. When possible, observe it directly instead of trying to “see” it only in your imagination or reconstructing it from memory. Compare those observations with reports and expert explanations.
-
Delay choosing a solution until you understand the problem. Define what is happening before investigating its causes; otherwise you may be “solving” the wrong problem.
-
Establish cause-and-effect relationships with evidence. State the proposed link and check whether the observations support it. Distinguish confirmed information from assumptions that still need testing.
-
Continue asking “why?” to investigate the causes. Each answer should lead to evidence, rather than another unsupported story. Ask “why” until you have identified causes that can be tested and addressed, recognizing that more than one may contribute.
When to use it
Debugging a complex software issue in a development team
Investigating a decline in customer satisfaction scores
Analyzing a production bottleneck in a manufacturing plant
Understanding the underlying causes of a recurring conflict in a team
FROM THEORY TO EVERYDAY LIFE
In practice
Software Bug Investigation
A development team faces recurring crashes in their application. Instead of immediately patching the symptoms, they apply SPPS: they go to the actual codebase and reproduce the bug, delay proposing fixes until they understand the full context, establish a cause-effect link (e.g., a memory leak due to unclosed database connections), and repeatedly ask 'why' until they discover the root cause (e.g., a missing resource cleanup mechanism in a specific module).
Manufacturing Production Delay
A factory is experiencing unexpected downtime. The manager goes to the production floor (principle 2) and observes that a conveyor belt stops intermittently. Instead of assuming a motor issue, they delay solving, collect data, and find that the belt stops only when a certain sensor is triggered. By asking 'why' repeatedly, they uncover that the sensor is misaligned due to vibration from a nearby machine, which is the root cause. Adjusting the sensor and dampening the vibration prevents recurrence.
A MOMENT TO REFLECT
Put it to work.
Think of a recent problem you encountered. Did you go see it firsthand or rely on reports? How might applying principle 2 have changed your approach?
When have you started solving a problem before fully understanding it? What was the consequence?
Recall a time you stopped asking 'why' too early. What root cause did you miss?
Often confused with
CONTINUE THE CONVERSATION
Source texts
- Thinking in Systems and Mental Models Think Like a Super Thinker (Dawson, Marcus P)