Problem solving as a skill you can practise
Engineers are paid largely to solve problems, yet the method is rarely taught directly. Most people pick it up by experience, and the habits they develop vary widely. A deliberate approach does not guarantee a quick answer, but it tends to avoid common traps: solving the wrong problem, fixing a symptom, or declaring victory without evidence.
The steps below are a general routine. They apply to a failing circuit, a slow program, a production defect or a design that misses its targets. Real problems rarely follow the order neatly, and you will loop back. Treat the list as a map, not a procedure to be followed rigidly.
1. Define the problem
Many wasted hours come from an unclear starting point. Before looking for solutions, write down:
- What is happening? Describe observations, not guesses. “The pump stops after about ten minutes” is an observation; “the motor is overheating” is a guess until it has been checked.
- What should be happening? The gap between actual and expected behaviour is the problem.
- When and where does it occur? Note conditions, such as temperature, load, software version or batch.
- What has changed recently? New parts, settings, suppliers or code often matter.
- What is the impact? This tells you how much effort is justified and how urgent the matter is.
Where possible, put numbers on the gap and write the problem in a sentence or two. If you cannot, you probably need more information. Asking the people who see the problem first-hand is often the quickest way to get it.
2. Gather facts before theories
It is tempting to leap to an explanation. Instead, collect evidence: measurements, logs, photos, drawings, test records and the history of the item. Keep what you observed separate from what you assume. Mark assumptions clearly so that you can come back and test them.
Data does not have to be complicated. A simple chart of a measurement over time can reveal a pattern that a list of numbers hides, as discussed under data visualization. More careful handling of results is the subject of engineering data analysis.
3. Break the problem down
Large problems are hard to hold in your head. Splitting them into parts makes them tractable.
- Divide by function. Which sub-systems are involved? A block diagram with clear system boundaries helps you see where the problem could live.
- Divide by stage. If something passes through a sequence of steps, find the step where the output first goes wrong.
- Halve the space. Check the middle of the chain. If it is fine, the fault is downstream; if not, upstream. Repeating this narrows the search quickly.
- Simplify. Remove features until the problem disappears or can be reproduced in its simplest form.
Problems frequently sit at the joins between parts, a theme covered under system interfaces.
4. Find the cause, not just the symptom
A fix that addresses only a symptom may let the problem return. Root cause analysis is the discipline of asking why until you reach something you can actually change. A simple method is the repeated “why” question:
- The product failed the test. Why? A connector came loose.
- Why did it come loose? It was not fully seated.
- Why was it not fully seated? The assembly step has no clear check.
- Why is there no check? The procedure was never written down.
The last answer points to something that can be fixed in the process, rather than blaming the person who made the final mistake. There are several structured techniques, described in the article on root cause analysis. Be careful not to stop too early, and not to chase a single cause when several factors combine. For software, the specifics are covered under debugging strategies.
5. Generate and test hypotheses
Once you have evidence, propose explanations and rank them by how well they fit the facts. Then design a test that could prove a hypothesis wrong.
- Change one thing at a time, so you know what caused any difference.
- Predict the result before you run the test. If the result surprises you, your understanding was incomplete, which is useful to learn.
- Prefer cheap, fast, reversible tests first.
- Record what you tried and what happened, including dead ends. Notes stop you repeating work and let colleagues help, and the habits described under engineering note-taking are valuable here.
Explaining your reasoning to another person, or even to an inanimate object, often exposes gaps, as described under rubber duck debugging.
6. Choose and implement a solution
Several possible fixes may exist. Compare them against what matters: effectiveness, cost, time, risk, effect on other parts of the system, and ease of maintenance. A simple scoring table can structure the comparison, as explained under decision matrices, though the weights are judgement calls.
Think about side effects before you apply a fix. A change in one place can shift a problem elsewhere. Where the change affects safety, quality or regulated products, follow the formal change procedures that apply to you, and involve the qualified people responsible.
7. Verify the fix
Never assume that a fix works because the symptom has gone quiet. Check:
- Does the original problem stay away under the conditions in which it first appeared?
- Did the fix cause new problems?
- Is the result repeatable over enough trials to be confident? Intermittent faults need more testing than faults that appear every time.
- Have you compared against the original requirement and not just against your memory of what was wrong?
8. Learn from it
When the immediate work is finished, spend a little time on what you learned. What allowed the problem to occur and to go unnoticed? Could a check, a design change or better documentation prevent it? Writing a short summary lets others benefit, and in a team a blame-free discussion usually brings out more useful lessons than looking for someone to blame. The same spirit is behind blameless reviews, and many failures offer wider lessons when examined openly.
Habits that help
- Stay curious about your own assumptions.
- Take breaks. A fresh look often finds what a tired one missed.
- Ask for another view early rather than after hours of struggle.
- Keep a record, so you can retrace your steps.
- Match effort to the stakes. A quick fix is fine for a trivial issue; a thorough investigation is warranted where safety or major cost is involved.
This article offers general guidance. Where safety, regulation or professional responsibility is involved, follow the standards and procedures that apply to your industry and country.