25-Seven logo

 
 
Home
 
Program Delay Manager
 
Audio Time Manager
 
About 25-Seven
 
Dealers
 
Contact
 
 

 
25-Seven Systems
It's about time.

The Psychology of Technical Quality

By Barry Blesser

Modern technology, be it hardware, software or any complex system, is often riddled with bugs and defects. Why is it so difficult to install, design and manufacture equipment without such problems?

The answer is simply that, when creating technology, human beings have in intrinsic limitations. While the principles of engineering often are articulated as a rational set of rules, professional engineers, managers and operators are still people. People have inadequate memory, incomplete rules of inference, emotional baggage, and private agendas. Evolution optimized our species for survival as a social animal operating in a hostile world, not as a logical creature operating in a rational world.

Understanding human psychology as applied to engineering can greatly improve quality and reliability. This is a fundamental premise of industrial psychology, which I constantly use at 25-Seven Systems. While my experience has been that few people in the radio and audio industries have been exposed to such academic disciplines, some of the basic ideas are so simple and self-evident that they can be put into practice without special knowledge or training.

I begin with two premises: (a) everyone takes pride in and benefits from a well-engineered result, and (b) achieving such a result follows from asking the right questions during the engineering process.

Herein lies the challenge. How do we spot flawed questions that undermine our ability to achieve desired results?

I discovered the principle of carefully framing the question while directing large engineering projects for such companies as AKG, EMT, Orban, Studer and Lexicon, but the ideas have broad applicability.

Consider: it is easy to ask obvious questions of a development team: “Have you checked the design carefully? Have you tested the system? Have you followed accepted methods for writing software? Are we ready to ship?”

Everyone in the team will answer “yes” because they want to demonstrate that they are dedicated, serious professionals who have made every effort to produce a good product. The manager can ask focused questions about particular issues, and he will get logical, coherent answers that are believable, and usually true. At a psychological level, the team wants to please the manager and be rewarded for providing answers consistent with a positive outcome.

But in this example, our questions failed to probe the unknown risks where bugs and defects remain hidden and ready to bite.

Now consider an alternative line of questions with a different set of assumptions.

The manager asks the group to speculate on “hypothetical” points of failure, regardless of how likely or unlikely they are to occur: “If the design were to fail, imagine ways in which that might happen.”

Someone might suggest that dirty contacts could produce a sequence of very rapid closures, or that somebody might lean on the front panel and simultaneously press an illegal and unexpected key combination, or that a configuration file might have a character that was not visible, and so on.

The team still wants to please the manager, but the manager has refocused the goal on creating failure scenarios, rather than on listing what already works.

Once a list of hypothetical failure mechanisms has been compiled, the manager and the team can consider the likelihood and the effort to test for such mechanisms. In my experience, from a list of 100 such mechanisms, 60 are not worth considering and 20 have already been handled carefully, but the final 20 definitely need to be explored. When those cases are carefully analyzed, the quality of the product is very much improved.

Managers should not confuse speculating about failure with negativism or professional incompetence. One cannot simultaneously ask that failure scenarios be explored, and then castigate a colleague for discovering a flaw through this process. “Why didn’t you think of that before” reactions are guaranteed to reinforce “tell me what I want to hear” responses, thereby undermining the entire process.

The fact that a certain flaw may not be discovered until a proper stimulus is provided is a reflection of human limitation. An effective manager provides such stimulus by framing the questions properly, and rewarding responses that expose flaws and risks.

Consider an application of this method in a radio station where the question is to articulate all the mechanisms that might result in being knocked off the air.

While everyone has considered backup power generation, nobody might have considered testing the fuel tank, which gets modestly drained on each monthly test. Somebody might come up with the observation that a critical telephone hybrid was not part of the auxiliary power system. Somebody else might observe that a cable with a vacuum leak would still work under a short test, but would fail after 20 minutes of use. Scenarios can be very complex and not the least obvious until creative people focus on inventing them.

I have use this approach with great success in a variety of situations, often unrelated to technology. A marketing plan, a proposed new studio, or a change in the structure of an organization can all benefit from this approach.

Frame the right questions, and the probability of success will increase dramatically. In simple terms, allow the staff to be rewarded for exploring human limitations and frailties without fear of being demoralized or degraded. The idea is common sense, but it is also counter-intuitive because so many people mistakenly equate a focus on what could go wrong with “glass half empty” negativism. In reality, those managers who are eager to discover risks are, in fact, the greatest optimists because they really want to achieve perfection.

This article was originally published on October 27, 2004 in the Radio World Engineering Extra column "The Last Word." It is reproduced here with the author's permission.

Copyright ©2005 by Barry Blesser.