Many of us get well rewarded for solving problems. In fact; arguably that is one of the top paying tasks in engineering. A good example - in the field of aviation - is that of Captain ‘Sully’ Sullenberger who saved hundreds of lives by bringing a passenger airliner down safely into the Hudson River after both engines had catastrophically failed - probably involving seconds in his entire career, or Red Adair putting out horrendous oil fires, or the astronauts bringing Apollo 13 back safely to earth. At the end of the day, as engineers, I believe problems are our stock-in-trade.
For some reason, we are taught that engineering is all about design and coming up with a nice construction - there is very little mention or discussion based on problems, until they occur. Think of your course at college – most of it was set in a pure world of building things and designing software where few problems exist. This is a huge oversight in teaching engineering. Students can be absolutely sure that a mammoth number of (irritating) practical problems will confront them, as engineers, on a daily basis. In some respects - if we don’t have problems, we don’t have a job. Interestingly, our most popular short courses (for engineers or technicians) are the troubleshooting and problem solving ones.
Fred Nickols (‘Solution Engineering: Ten Tips for Beefing up your Problem Solving Toolbox’) gives some really excellent (although perhaps rather dry) tips on a great sequence for problem solving which I have modified to my childlike (yes!) way of thinking:
1. Focus on the desired solved state
Most of the time we contemplate the problem with horror and ignore what we want to achieve. With this mind set we focus on the problem and then move from problem state to problem state. A better approach is to visualise clearly what you see as the final solution and focus on this unerringly throughout the entire problem solving process.
2. Be clear about ALL your objectives
To clarify this it is worth asking:
What are we trying to achieve/preserve/avoid/eliminate?
3. Expand your definition of the problem
The acclaimed ‘define the problem’ is the most poorly understood and executed step in the process. And as you solve the problem, this definition changes. Do the following:
Locate the problem/Isolate it/Describe it precisely/Define it
4. Bounce around like Sherlock Holmes in solving the problem
The information you need is not in one structured pile, but in a heap of little bits scattered far and wide; both written down and in many people’s heads. And changing. Be Sherlock Holmes – the brilliant detective; find it all and bring it together.
5. Picture it
We are engineers after all and tend to be visual thinkers. Diagrams and schematics should be used as much as possible.
6. Don’t always fret about the cause
Causes can sometimes be fixed and should be investigated. But don’t waste valuable time and effort looking into a cause where it is not going to help you solve the problem.
7. Avoid disconnects
We go through this every day. Top management gives instructions on fixing a perceived problem. By the time it gets down to the electrician on the shop floor, the problem has disappeared and he is merely doing a useless job for which the reason no longer exists.
8. Know your own vision
We all have built in biases and approaches to doing things. Sometimes good and sometimes not so good. It is best to be ruthless about what they are and understand the overlap between our personal and the rational objective world out there when assessing the problem. Stand back and watch yourself solve a problem and try to understand your biases for next time. Use your strengths, but guard against your weaknesses.
9. Create your own system
You know your skills and expertise the best. Develop your own system of fixing a problem.
10. Sharpen your knife
Keep refining your knowledge and expertise and sharpening your problem solving abilities.
I believe in what the famous mathematician and scientist, Rene Descartes observed:
‘Each problem that I solved became a rule which served afterwards to solve other problems.’
Yours in engineering learning
Steve
