Defining the Right Problem: Framing and Assumptions in Engineering

The Hidden Failure: Solving the Wrong Problem

Engineering failures are more often caused by good engineering solving an unspecified problem than by bad engineering caused by incorrect math. I see this all the time. An engineer works hard for two weeks to make a bracket just slightly lighter. The result comes in at 1150 grams, two grams under the target. After the team has a victory meeting to celebrate the excellent engineering, someone else notices that the failure mode hasn't changed. The failure analysis still shows high stress. The bracket is still cracking due to thermal cycles. It was never too heavy in the first place.

Problem framing. This is hard to do, but it's essential to tackle a real problem before you start calculating, before you start CAD, before you start thinking of solutions. This is before you even think the stakeholders have a clear idea of the problem they are asking to solve. This is before you even think you understand the problem they have asked to solve.

Engineering failures rarely originate from incorrect mathematical calculations but rather from having solved the wrong problem exceptionally well. One can run a series of perfect FEA or simulations on a component that shouldn't exist in the first place, or painstakingly optimize parameters that aren't worth the marginal gain. Months or weeks of work are wasted by creating an excellent solution to an improperly defined problem. It is the framing of the problem that must be understood correctly in order to spend time effectively solving it.

Every Engineering Problem Is Incomplete

Common ignorance: Every problem statement you receive is missing crucial detail. Often, the person who gave you the task does not realise what missing pieces I can think of. They might say "design a bracket for 500 N" and you'll proceed to draw neat little rectangular tubes and calculate some bearing loads. Error waiting to happen.

Every assumption you DON'T challenge is a failure mode you'll find out about "the hard way" later on. Assumptions (untested) affect math to produce precise (but incorrect) answers to the problem as YOU perceive it, not as it REALLY is. Expose your assumptions so you can test them BEFORE they lock you into a bad design.

The Questions Engineers Ask Before Designing Anything

Junior engineers typically want to dive straight into solutions. Experienced engineers want to ask uncomfortable questions first. Not because they are trying to be difficult, but because they have been burned by poor design in the past. Here's what really gets asked in the first 10 minutes of a real project.

"what's the real problem" — not what the request says. What's really broken, expensive, or dangerous.

"what if I did nothing" — A series of hand written letters exploring the idea "what happens if we do nothing?". Nobody asks this question enough. Is inactivity ever the right answer?

"what are we not allowed to change?" The budget and the deadline, the materials the previous designers worked with, the regulations that dictate the design of the mascot, the existing tooling that makes the previous mascots. These are all things that can not be changed and must be taken into account as we brainstorm.

"how do you know when you are done" – very vague success criteria which will come back to bite you in the posterior later on.

"what's going to kill this design?" fatigue, corrosion, wear, thermal cycling, misuse, manufacturing defects. Start from the failure modes.

"what don't we know yet" — Missing data, uncertain loads, unknown operating conditions. I would like to list out all of these.

Do these questions slow you down? No, these questions slow you down so you don't go in the wrong direction for 3 weeks. This is the time to get problem definition wrong before you go and start solving the wrong problem.

What Fails When Problem Framing Is Ignored

When problem framing is ignored, several things fail. Here's a breakdown of the repercussions. Pay attention to the subtle yet far-reaching effects on your work. Let's dive in together!

This video explores a few examples of Poor problem framing and how to fix them. The first example: optimize for minimum weight because someone says "lightweight design". Optimizing for minimum weight (in this case the shaft mass) after finding that the original design was already 35% below its ultimate limit load. Calculating that with a 20% reduction in mass, the design would be 50% below its ultimate limit load. The question then becomes: what were you thinking not doing a fatigue analysis?

It is often the correct solution to the wrong problem that kills designs. A subtle vibration problem is fixed by better dampening, when the real problem is resonance. That extra stiffening to reinforce a failing part only concentrates the thermal stress elsewhere. Designs are spec'd to perfection, meeting every requirement, only to fail in the field.

Problem framing forces you to write down your assumptions so you can test them against reality. Without problem framing your assumptions will only work in the realm of paper, and not in the reality you're trying to address.

A Practical Method for Framing Engineering Problems

I sometimes think that problem framing is mistakenly viewed as a formal, up-front activity that needs to be done for a project to be successful, and then can be mostly forgotten until someone points out that it hasn't been forgotten for everyone else. In reality, good problem framing should be a familiar process that you enter automatically whenever you're about to start designing, or unexpectedly reminded of during project Planning or expansion, or interrupted by a coworker with a quick question for you to answer at your desk.

First write the actual problem. The proposed problem statement (design a bracket with reduced weight) won't help. Components are failing from thermal cycling during startup. Assembly time is too long because access is limited. Current design can't be manufactured with available tooling. One sentence that defines the actual problem.

Statements of assumptions. Not all assumptions need to be made explicit. Aim for those which would cause serious harm to your design if they prove incorrect. " The worst case load on the part will be 500 N". " The part will operate at room temperature". " Stainless steel is an acceptable choice for cost reasons". Write down these assumptions and put a ? next to any which you have not verified against the needs of the customer.

Formulate the notion of success in quantifiable terms. I mean more than "good enough". I mean more than "acceptable performance". I mean numbers. "The PCB has no visible deformation when subjected to a load of 500 N." "The PCB survives 10,000 thermal cycles for which the temperature is cycled between 20°C and 80°C." "The assembled product can be completed in less than 5 minutes using hand tools." If you haven't defined success in numbers then you'll have trouble verifying that you achieved success.

What could I be missing? What failure mode wasn't considered? What constraint was unspoken? What operating condition am I assuming will be true? These questions have saved more projects from the design dead pool than all of calculus combined.

You might think the best engineers are those who can do the most math in the shortest amount of time and have the broadest base of knowledge. But the reality is that the best engineers are those who do the best engineering, and that starts with identifying the actual problem to be solved before they dive into creating a solution. Defining the problem is the habit at the root of great engineering.