Dear Colleagues
As we all know there is a burgeoning environmental catastrophe occurring in the Gulf of Mexico. BP’s CEO has announced that a massive containment dome (also known as a cofferdam) will be dropped through 5000 feet of water to cover the oil leak and funnel the oil to the surface - something that has never been done before, let alone at these depths.
Engineering professionals always rise to the occasion - coming up with ingenious solutions to engineering problems (whether they always solve the crises is another issue). Furthermore, these solutions do much, ultimately, to make the processes, safer, more efficient and often more economical. We can learn so much and gain incredible experience from these endeavours too - making us much better engineers and technicians.
I am not suggesting that problems, and indeed disasters, are a good thing. But if the approach to the solution is constructive and thoughtful, an amazingly sustainable and positive outcome can be achieved - one of the ways in which engineering improves the world around us. In other words, a particularly elegant solution to an engineering problem is akin to the legendary phoenix bird arising from the ashes.
When I reflect on the array of engineering problems which has confronted me over the years I always think of the solutions in brackets – some less memorable than others I must confess:
• An enormous mining crusher which failed due to a lack of oil - (replace all trip circuits with triple back up and audit the rest of the plant to identify and fix similar problems).
• Data communication links which failed intermittently crashing an entire plant - (replace copper with fibre).
• A Programmable Logic Controller dropping out occasionally - (audit and fix poor earthing system).
• Cavitation problems in pumps - (reroute and change piping)
• Process control tuning problems - (fix instrumentation)
• Denial of service attack on our new VoIP telephone system - (improve firewall)
• PLC Ethernet card failure - (provide training in configuring MAC and IP addresses and ensure solution is detailed next to server).
How does one tackle engineering problems? I have always admired the Kepner-Tregoe approach to problem solving. One grizzled engineer remarked to me, recently, “You don’t have to go on the training to learn this, just buy a $20 book, read it a few times, ask lots of questions and practice the techniques”. In a nutshell:
Define the problem.
Keep asking “Why?” - Typically up to 5 times, to ensure you have a clear handle on the specific problem.
Describe the problem
Use these four questions to help you pin down a description of the problem:
• What it happening?
• Where does it occur?
• When does it occur?
• To what extent does it occur?
Establish possible causes
You should rely on the tried and tested question here - What has changed since it worked? Check all possible changes – no matter how trivial or inconsequential they may seem.
Test the most probable cause
List the causes and examine each one objectively.
Verify the true cause
Compare the possible root causes against the problem description. Thereafter consider solutions which may prevent its reoccurrence. Once the immediate problem is solved and the “heat is off” we tend to relax. In my opinion, however, it is critical to look at fixing the problem in all possible, or similar, areas to ensure the solutions are permanent.
Solving business problems? - Considerably more challenging and painful. They are often more unpalatable, for example the viability of a business unit - has the show moved on? For me, the past year has been tough, with these and similar questions mulled over from time to time, but we are still here providing engineering education and training.
I absolutely believe in this assertion by John W. Gardner:
We are continually faced with a series of great opportunities brilliantly disguised as insoluble problems.
Yours in engineering learning
Steve
