Albert Einstein is credited with saying, “If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
We at Inuktun fully agree. The importance of defining the problem frequently gets lost in the desire to get on with the solution.
For example, last week's Friday Op-Ed raised the issue of inspecting old infrastructure that was never designed to be inspected. At first glance, it may appear as though engineers or designers ought to share in the blame for such a situation, but in reality, that's rarely the case. More often, it is a result of a poor or incomplete definition of the problem at the outset. Simply stated, most old infrastructure was never designed to be inspected; inspection simply wasn’t part of the problem definition (at least, not at the time of design). Not that we're complaining — the challenge of inspecting the unexpected is the lifeblood of Inuktun's business.
Admit it: as engineers, we've all been there. Even with a well-defined design process that emphasizes thorough exploration and definition of the problem, we will sometimes find — usually not until much later in the process — that our problem description was somehow incomplete.
Take the new MaggUT crawler system. Our engineers did a brilliant job designing a system that could perform visual and ultrasonic inspections on a variety of steel surfaces. Targeted at above ground tank inspection, the vehicle should be perfect for API653 certified inspectors. And indeed, the first system (with a little tweaking) performed very well in the laboratory, per initial target specifications. But just this week we took the prototype to a local pulp mill to test it in real world conditions and found out what we'd missed. When crawling vertically over large and uneven welds, the vehicle fell off the surface. Trial and error showed the problem, and it was easily fixed — but, had we thought harder about weld characteristics in the beginning, we could have saved ourselves significant heartache (and time... and money). This is, nevertheless, a fairly trivial example of the potentially critical consequences of incomplete problem definitions.
We regularly tell our clients, “If you give us your best requirements, we can give you our best solution.” All too often, we deal with projects where the scope changes as the project progresses — this frequently proves costly in terms of scheduling and price. We don’t believe there is any way to guarantee that all issues have been considered at the beginning of a project, short of engaging virtually unlimited resources. Moreover, 'paralysis by analysis' is a trap that can be even costlier than a poor definition.
In an attempt to improve project requirements definitions, we have created a questionnaire to help our customers think about aspects of their project that they may not otherwise consider. It’s not perfect, but it can make a big difference. And when the cost of failure can be unsurmountable, a little extra consideration in the beginning is well worth the investment.