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?”


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 [email protected]

For Tim’s columns, see:


Copyright © 2011 by Tim Bryce. All rights reserved.

Like this article:
  15 members liked this article


Adriana Beal posted on Sunday, July 17, 2011 9:32 AM
Tim, I always liked the doctor/patient analogy, which I actually used during my exit interview in one of my last projects.

As the lead business analyst in the project, I was extremely frustrated with the "artificial walls" created by project sponsors that prevented me from directly speaking with end-users -- the people who actually performed the tasks supported by our system. The culture was indeed "give them what they want" (or ask for) without further investigation, which only created budget and schedule overruns when what they wanted turned out not to be what they needed. Without being able to talk to the people performing the tasks (we weren't collocated), there wasn't much that could be done to change the constant need for rework and change requests.

After several unsuccessful attempts to change the situation, I told them that I felt like a doctor who has been asked to diagnose a patient sitting in the next room whom I could not see or talk to--only write a prescription based on what illness they told me they had.

I've noticed that the "give them what they want" mentality is often used as a misguided protection mechanism by IT teams. As if you could then say "why are you complaining? I gave you what you asked for". Until this mentality changes, we will continue to see many unhappy business stakeholders complaining about the high costs and low returns of IT projects.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC