The problem had plagued the plant since the 1970s: vessels were designed to ASME code but didn’t have code stamps. A true pedant — i.e., nitpicker — would have declared in a panic, “We must shut down the plant immediately!” Instead, the calm and rational response was to finally address the problem. The vessels aren’t going anywhere. Nothing had exploded. The issue was simply lack of proper documentation. The solution was to find an engineer to complete the code registration; do an inspection to provide that engineer with material specifications, thickness verifications and a visual inspection; prepare drawings and file for the “R” stamp. Case closed. It took a couple of days but I located a suitable engineer. Our vessel inspector had been through this before. The ball was rolling.
[pullquote]
Success in this business involves identifying the real problem, matching resources and communicating effectively. It’s not rocket science. However, that’s doesn’t mean it’s easy, especially if you haven’t faced the particular problem before.
A common error is trying to reinvent the wheel. For perhaps 90% of the problems you’ll face in your career, someone else already has come up with a solution. Find that person!
Don’t look for pearls in a pig pen. Instead, consider where the demand is greatest for the particular expertise because that’s where the person who can help you likely is. I went to Houston to solve my ASME code problem.
Don’t just make contact and then send a memo. Arrange to talk to the person. To avoid any lapses in your memory about relevant details during that conversation, beforehand send lots of annotated pictures and graphics. Pose questions in a Socratic manner (i.e., open-ended queries to stimulate thinking and draw out ideas). That way, you’ll know whether the person understands the issue you’re facing. Afterwards, write a follow-up memo that summarizes your understanding of the key points covered in the conversation. That memo will provide a record of what you agreed to do.
By far the biggest challenge that engineers within any company face is time management. Others want a piece of your day to solve their problem. They don’t necessarily see their problem in terms of the big picture — but you don’t have that luxury and neither should they. Always keep priorities in mind; yours should be safety, quality, production and politics. I include the later because scopes often adjust to please the strongest personalities. However, safety and quality vie for first and second place because they can turn out lights.
If you can’t control your time, then delegate. However, resign yourself to putting in hours at the beginning, middle, and end of projects, not to mention for recruiting. And that doesn’t include the time required to fill out vendor approval documentation. For a project involving 2,500 hours of engineering time, plan to spend at least 120 hours in the beginning, 40 hours in the middle and 80 hours at the end. That translates to about 10:1 contractor hours to your hours. The good news is that your hours really don’t increase much for bigger projects — up to a point where you need help. The bad news is that you don’t spend less time on smaller projects because managing a project always involves a fixed number of hours.
Finding the cause of a problem can be both challenging and exasperating. A fault tree analysis (FTA) tends to round up “the usual suspects,” a few offbeat ones and even some “tin hat” (i.e., completely off-the-wall) potential culprits. Don’t discount anything but use the opportunity to tune the hypothesis testing you already should have started before the FTA. Also, develop a spreadsheet that identifies measurements you can’t determine. For example, if there’s no way to know when a cooling water valve was open, put that on your list.
The exasperation comes from solving or ameliorating the problem without really knowing what led to the result. Chances are you’ll apply several recommendations from the FTA and never will know for certain which “solution” really had the greatest impact. If your effort was for naught, maybe you need to reconsider some of the tin-hat ideas. It’s frustrating when a seemingly foolish idea actually solves the problem. Sadly, that happens, despite all logic.
