Tell Them What You Need not What You Want
Submit Articles Back to Articles
When a person visits a doctor to complain about an ailment, it is not
uncommon for the patient to try and diagnose the problem himself and prescribe a
cure. The doctor listens politely but then asks a series of questions aimed at
analyzing the patient's symptoms, for example, "When and where did you first
notice this?" "How often does this happen?" "What medication are you currently
taking?," etc. By analyzing the symptoms, the physician is trying to diagnose
the problem. If he cannot ascertain the problem through questioning or a basic
examination, he may order additional tests, such as an MRI, X-rays, a CAT scan,
blood tests, urine samples, etc. The point is, the doctor is more interested in
attacking the root cause, not just the symptoms.
We see this same type of phenomenon in Information Technology (I.T.) related
projects where the end-user approaches the I.T. manager with a request for
service whereby he sincerely believes he knows the right technical solution to
solve his business problems. Two things may result from this request: either the
I.T. department will treat the users symptoms, and give him what he wants,
thereby not really solving his business problem correctly, or; the I.T.
department will study the user's problem more closely, possibly order some
tests, and prescribe a solution that properly addresses his problems.
Regrettably, this latter approach is rarely performed in companies anymore.
There is still a huge frustration factor between users and I.T. developers.
On the one hand, users claim, "They (the I.T. people) don't understand me," and
on the other hand, the I.T. people contend the users "don't know what they
want." This void between the two groups is unhealthy and not conducive for
solving the company's problems. Frustrated, I.T. management tells developers not
to ask questions, "Just give them what they want." This scenario is obviously
counterproductive, yet commonplace in the corporate world today.
When I am asked how to deal with this situation, I emphasize the
doctor-patient analogy as mentioned above. First, the I.T. people have to learn
to ask more questions and differentiate symptoms from problems. In other words,
let's not be in such a hurry to program a solution before we truly understand
the problem. I.T. has a horrible track record in this regard. The idea of
specifying user information requirements is the Achilles' Heel of every
development project. If it is performed superficially, the wrong solution will
inevitably be delivered. Second, the user should play the role of a patient,
meaning don't try to prescribe a solution but concentrate on what you truly need
and let the doctor (the I.T. department) prescribe a suitable solution. After
all, who has more training in this regard, the doctor or the patient? Let the
I.T. people do what they're trained to do (and are paid for).
As long as we know our roles and do not try to do the other person's job,
we'll get along just fine. Now turn your head and cough.
Keep the Faith!
Copyright © 2010 Tim Bryce. All rights reserved.
About the Author
Tim Bryce is 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 firstname.lastname@example.org
Follow us @Scopulus_News
Article Published/Sorted/Amended on Scopulus 2010-02-25 10:15:45 in Computer Articles