I was recently asked a question that raised some good design issues. The question went “why should changing *this *cause a change in *that *characteristic?”

The immediate and obvious answer was that it wouldn’t and couldn’t. Theoretically, a large decrease in *this *(*X*) might cause an *increase* of a few percent in *that *(*Y*); nothing more. Only someone was claiming that decreasing *X decreased* *Y*, too.

They were right. No, the theoretical relationship isn’t wrong. It’s right.

The theoretical calculation is fairly straightforward. You put so much of *X *in, and, after some calculation, you get so much of *Y *out. The less *X *you have, the more *Y *you get. The hard part is figuring out just how much of *X *you’re putting in.

The *measurement *of *Y *introduces a bunch of variation based on other factors. You measure by changing certain conditions *A*, *B *and *C*. These, in turn, affect some other factors, *M *and *N*. *X*, *A*, *M *and *N *together determine what value you measure for *Y*.

So decreasing *X *affects the other factors in such a way that the net effect is a decrease in the measured value of *Y*.

“Oh, sure,” you respond. “But the theoretical calculation should account for that.”

Not really. The theoretical calculation should tell us what the best case is…what our target should be. The actual measurement is going to produce different results based on various factors, some of which we control and some we can’t. A calculation based on the measurement process would require uncertainty ranges and return a probability distribution; not a singular value. Messy.

Engineers and researchers need to consider both of these as definitions. If you’re designing for some characteristic, as a researcher or engineer you’re usually going to be concerned with the theoretical calculations. This is how you were taught in school, and you’ll naturally be interested in getting as close to the best case as possible. However, not everyone is going to be interested in the theoretical calculation. The folks in Quality who are checking the product for conformance will be more interested in how it’s measured, the *operational definition*, than in the theoretical definition. The manufacturing plant only want to hear about the operational definition; for them, the world would be a better place without the theoretical definition.

As a design engineer, you need to be more concerned about the operational definition. You’ll be arguing that you designed a part for *Y *performance (or to “do *Y*“). The next question that management and your customers should (and probably will) ask is, how do you know you designed it to do that? The answer is always *by data analysis*. How do you get the data? Via the operational definition. What you know is determined by how you measure, and that’s the operational definition.

This has applicability well outside of engineering design. Physicists have been arguing this very point ever since Bohm and Heisenberg developed the *Copenhagen interpretation* of quantum physics. Management by objective depends on the ability to close the loop by measuring outcomes. This means that management by objectives requires operational definitions of every objective (though few organizations actually get this far, and *management by objectives *becomes *management by manager gut feeling*). Even more enlightened management techniques, such as those advocated by Deming and Scholtes, require operational definitions to enable an organization’s performance improvement (e.g. through the use of control charts, which are only possible with operational definitions).

Use the theoretical definition to tell you the best possible case, but be sure to design according to the operational definition.