Solving Type III problems

There are occasions when we perfectly solve the wrong problem. This is a Type III error.

Following the statistics idea of Type I and Type II errors, when a sample provides information incorrectly about a population, Type III is the error of asking the wrong question to start.

Solving the wrong problem, even perfectly, is still an error.

So, how do you know you’re in a Type III situation?

As engineers, we love to solve problems, find solutions, and move on to the next task. If someone says, ‘Here’s a problem’, we tend to frame that problem and consider alternative paths to solve that problem.

Better engineers will also consider the impact of the solution on the overall system. Some will even consider the risk/benefit balance of even trying to solve the problem.

Very few, in my experience, consider is the problem is valid and in need of a solution.

A reliability prediction example

Reliability prediction is a useful endeavor for development teams as it provides a way to estimate the current design’s reliability performance. It is also a great way to spot design weaknesses of a design since the process requires the consideration of components, use/environment, and the design.

It is so useful that some contracts specify, Thy Shall Do Prediction, then may specify a specific method.

In this example, let’s say the contract specifies Mil Hdbk 217 parts count prediction. And, you are tasked with performing the prediction.

(for those that are unaware of the status of Mil Hdbk 217, it has been obsolete since 1994)

What do you do?

Do you open the old database and dive into doing the best you can to create a parts count prediction using the tenets and information of the handbook?

Or, do you ask if the result will serve the design or customer?

Three ways to spot Type III errors before they occur

• No one will use the solution.

If the work to create a solution is not going to be useful, they why would we work to create a solution? Be sure there is a connection between the solution and a need for that solution.

• What is the priority?

In every program we are limited by time. We should focus on solving the most important problems. If there are better things to focus on – then do so. The perfect solution of some problems will have negligible impact.

• It’s been solved before.

This may be harder to detect, especially is you would like to work on solving the problem. I did this once, and spent two weeks solving a technical problem, only to find when presenting my work, that someone else had already found and implemented a solution. I hadn’t even asked if anyone else was working on the issue.

There may be other ways to find you’ve committed a Type III error. Comment on how you avoid them and let’s help others identify and avoid this basic error.