“We need quatre binaries on this loop.” At this point, I’d heard this statement on what seemed like every loop we were discussing. I was in a meeting in Paris to define the DCS requirements of a paper machine project with the engineering company.
“Pour quoi?” I asked. Okay, I don’t really speak French, but I’d picked up a couple of things since arriving in France, and every time the engineer said that he had to have four discrete outputs associated with a control loop, it meant that I had to use a more expensive piece of hardware. So I finally asked the right question, “Why?” The answer stunned me. The only DCS he knew required the user to hardwire outputs back to inputs to generate an alarm! I explained to him that our system didn’t work that way, and so we started over in defining the system. If I’d never asked why, I’d have quoted a very over priced and overly capable system for a simple application and lost the project.
It was early in my career and this incident taught me a lot about getting to the real drivers of what seems to be a rather straightforward issue. As an engineer, I had been trained to take the data I was given, process it through some rather black-and-white filters and produce an answer. Did I have a controller with four discrete outputs? Yes. Did the customer ask for four discrete outputs? Yes. So that’s the controller he needed, n’est-ce pas? No. What he needed was a way to notify the operator of a problem in the system. What I needed was to understand what problem he was trying to solve.
Asking why is easy for kids, but can be very uncomfortable for adults. We take it as a challenge or even an affront to our intelligence, but asked the right way, it can save us from going down the wrong path. Saying “Help me understand…” is often the most revealing question you can ask. As Yogi Berra (supposedly) said, “If you don’t know where you’re going, you’ll probably end up some place else.”