Search This Blog

Sunday, June 26, 2011

THE DOCTOR/PATIENT ANALOGY FOR PROBLEM DEFINITION

Over the years I have noticed that we, as Americans, seem to possess a knack for attacking the wrong problems which I refer to as the "Rearranging the deck chairs on the Titanic" phenomenon. I see this not only in the corporate world, but in our private lives as well. Instead of addressing the correct problems, we tend to attack symptoms. This would be like taking an aspirin to alleviate a major head injury. Attacking symptoms is something we habitually do in this country.

If a problem is improperly defined from the outset, than everything that follows will be incorrect. In particular, this is the Achilles' Heel in most Information Technology (I.T.) related projects. Instead of taking the time to diagnose a problem, there is a tendency to give the users what they want, not necessarily what they need. When I discuss this subject with I.T. people, I tell them they need to think in terms of a doctor/patient relationship instead. How many times have you gone to visit the doctor thinking you have a specific problem, but after diagnosing it, the doctor defines it as something entirely different? If you had attacked the symptom yourself, you may very well have not addressed the proper problem and, in all likelihood, may have made it worse.

I am reminded of the story of an IT Director at a Midwest shoe manufacturing company who received a call from a Sales Manager asking for some help on a pressing problem. The I.T. Director sent over one of his programmers to meet with the Sales Manager to discuss the problem. Basically, the manager wanted a printout of all shoe sales sorted by model, volume, type, color, etc. The programmer immediately knew how to access the necessary data and sorted it accordingly thereby producing a voluminous printout (three feet high) which he dutifully delivered to the user.

The I.T. Director stopped by the Sales Manager's office a few days later to inquire if the programmer had adequately serviced the user. The sales manager afforded the programmer accolades on his performance and proudly pointed at the impressively thick printout sitting on his desk. The I.T. Director then asked how the manager used the printout. He explained he took it home over the weekend, slowly sifted through the data, and built a report from it showing sales trends.

"Did you explain to the programmer you were going to do this?" asked the IT Director.

"No," replied the Sales Manager.

"Are you aware we could have produced the report for you and saved you a lot of time and effort?"

"No."

This is a classic example of the blind leading the blind. The user did not know how to adequately describe the business problem, and the programmer asked the wrong questions. In other words, this is another instance where symptoms were attacked as opposed to the root problem. Instead, the programmer should have played the Doctor's role and asked the types of questions the I.T. Director did, e.g., "If I produce this report, what will you do with it? What would actions and business decisions will you make?" In other words, try to diagnose exactly what the user needed. Unfortunately, this didn't happen and the programmer gave the user what he wanted, right or wrong.

Unfortunately, "Give him what he wants" is the mantra in most I.T. organizations today which I consider a reckless form of behavior. Instead, it should be, "Give him what he needs." This will only happen if I.T. people start acting more professionally and appreciate the need to properly specify a problem. The old adage, "The problem well stated is half solved," is certainly true. Yet, diagnosing a problem is not considered the fun or glamorous part of most I.T. projects these days. Nonetheless, it is an essential part of any project, be it I.T. related or not. Again, if the problem is not properly defined, you will inevitably work on the wrong thing. And believe me, we have rearranged enough deck chairs, it's time to fix the damn hole in the side of the ship instead.

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim's columns, see:
http://www.phmainstreet.com/timbryce.htm

Like the article? TELL A FRIEND.

Tune into Tim's THE BRYCE IS RIGHT! podcast Mondays-Fridays, 7:30am (Eastern).

Copyright © 2011 by Tim Bryce. All rights reserved.