What IT departments can learn from Sherlock Holmes

Stories about fictional character Sherlock Holmes have fascinated and entertained several generations for over 100 years. This self-proclaimed, consulting detective has solved a wide range of complicated cases by using logical and rational methods. The same approach is surprisingly useful in working life, especially in IT roles.

“When you have eliminated everything else, whatever remains, however improbable, is the truth!” stated Holmes.

This is, more or less, just as Holmes describes the basic principle for his methods. In order for this principle to function, one must be supported by technology, which can be used to eliminate theories and conclusions that are wrong, and strengthen those that are correct.

Do not theorise before you have data

One of the most important tools Holmes uses is observation. “You see, but you do not observe,” he says. What is he suggesting? One example might be your smartphone, if you have one. Do you recall the icon that is located in the lower right-hand corner on your main screen? You probably see it every day. Those who remember the icon are said to observe; the rest of us only see.

The ability to observe is used to gather facts, the foundation upon which Holmes relies in order to construct his theories. “Data, Data, Data! I cannot make bricks without clay!” he exclaims impatiently, in a case in which raw data is missing. He is also careful, gathering as much relevant data as possible without getting bogged down in details. “There is nothing more deceptive than an obvious fact,” he says.

When all available facts are on the table, Holmes first presents his theory. “It is a huge mistake to theorise before one has data. Imperceptibly, one begins to twist the facts in order to suit the theory, rather than to twist the theory in order to suit the facts.”

The solution he presents is not only based on facts, but also on experience from other cases—and not only his own cases. Holmes has memorised a wide range of European-wide criminal cases and often draws on details from these experiences that are different from those he has solved.

The extraordinary thing about Sherlock Holmes is his well-developed ability to use and combine all these techniques and methods, and then come forward with extremely detailed and, for the most part, correct conclusions so quickly that it appears as guesswork. Those of us who are not so dedicated and experienced as Holmes can, nonetheless, use methods that are based on the same principles—albeit not as quickly.

The Kepner-Tregoe approach

Kepner-Tregoe uses a method for problem solving that is confusingly similar to the methods of the famous detective and it shows impressive results. This method, called “Problem Analysis,” was developed by Charles Kepner and Benjamin Tregoe in the 1950s.

These two men observed that some officers in the American Air Force stood out from others in making successful decisions. A common trait in these officers was their use of rational and logical processes in order to gather, organise and analyse information before they did anything else. Based on this, the Kepner-Tregoe researchers developed a process with pre-determined steps for effective problem solving.

Describe the problem

The first step is to define the problem that needs to be solved. An unambiguous statement that addresses a specific problem linked to a defined object tends to hold focus, so that one does not confuse several issues. The definition of the problem should contain an object and an anomaly. For example, “Laptop 123 cannot access the network.”

The next step is to get the facts, typically by observation. Similar to Sherlock Holmes, Kepner-Tregoe instructs us to describe the facts based on what we see, hear, feel, smell and, perhaps, taste if relevant. In addition to what we observe, in this step, we should also write down what we didn’t observe—to include the facts we realistically could have observed but did not see. For example, “Laptop 123 is affected, but laptop 124 is not affected.” This will help us specify the problem and eliminate theories that are not in keeping with all the facts. The process also includes consolidating the facts into these categories: “what”, “where”, “when” and “scope.”

Identify the possible causes

When we have all the available facts on the table, it is time to develop some theories, some suggestions, as to why the problem arose. Kepner-Tregoe suggests we do as Holmes would do, namely to draw upon the knowledge, expertise and experiences you and others have. What is special about the observations we see as opposed to those we do not see? What kinds of changes have contributed to the differences?

Evaluate the causes

A master detective will, naturally, end up with only one explanation—the correct one. In practice, it is favourable to make a small list with possible explanations and then test each one against the facts we have observed.

An important step is to test the explanation against both that which we observe and that which we do not observe. For example, “If a mistake in the network card is the reason that laptop 123 cannot connect to the network, how does one explain that laptop 123 is affected but laptop 124 is not affected?” The answer to the test can be: 1) that the theory fully explains the observation, 2) that the theory only explains the observation if it is supported by an assumption, or 3) that the theory does not explain the observation and, thus, the theory also eliminates (as possible) the explanation of the situation. The theory that explains all the observations and has the least number of assumptions is probably the correct one.

Verify the right reason

The last step in the Kepner-Tregoe Problem Analysis process is to verify that the most probable explanation is, in fact, the right one. This can be done by checking that the assumptions do, in fact, stand up by observation, by experimentation, or by actually trying to solve the problem.

Kepner-Tregoe and IT

The Kepner-Tregoe method is not limited to IT problems, but because IT problems are often complex and unclear, the method is well suited for IT. An interesting observation is that IT staff who solve problems for one or two support lines most often receive training on the systems they will support, but seldom receive training on problem solving in general.

By checking that assumptions, in fact, stand up by observation, by experimentation or by trying to actually solve the problem—IT departments can find an explanation.

“Elementary, my dear Watson!”

The following two tabs change content below.

Kristian Spilhaug

Latest posts by Kristian Spilhaug (see all)

Leave a Reply

Your email address will not be published. Required fields are marked *