Information Requirements

Computer/Internet/Software Articles
Submit Articles Back to Articles
As many of you know, I have been active
in the
Information Technology (IT) industry for a long time now. It's a
strange business and, frankly, sometimes I wish I had never gotten
involved with it. Nonetheless, there are a lot of problems associated
with IT, such as computer performance, capacity planning, security,
networking, disaster recovery, but probably the biggest problem is
requirements definition. In other words, accurately defining the
information needs of the end-user. The industry is actually quite good
at designing and writing software, developing data bases, and acquiring
hardware, but after all these years they still have trouble
understanding what the user needs to run his or her part of the
business. Consequently, the wrong solution is inevitably delivered to
the user, thereby causing a lot of wasted time and money reworking the
solution to fit the need.
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 IT Director sent over one of his programmers to meet with
the Sales Manager and 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 IT 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 IT 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. Remarkably, both the Sales
Manager and programmer were delighted with the results. The IT Director
simply shook his head in disbelief.
This is a
typical scenario played out every day in the corporate world. Both
sides feel frustration, the user and the systems people. The end user
typically asks, "Why can't they give me what I want?"
And the systems people claim, "The user doesn't know what he
wants."
I contend the user does know what he or she wants from a business
point-of-view, but stumbles through technical jargon. Then again, the
user shouldn't have to learn the jargon of the systems world. This
would be analogous to forcing the user to learn construction
engineering concepts when specifying a skyscraper, something that takes
architects years to learn.
Instead, the
systems people have to listen to the user (as architects do) and
carefully interpret what he needs. A review of the information
requirements should be performed with the user, in common terms the
user understands, for if the requirements are wrong, then everything
that follows will be wrong.
To properly interpret information
requirements, the systems people should say something to the effect, "Assuming
I give you the information you want, in the form you want it, what will
you do with it? What actions and/or decisions will you make with it?"
Only when the systems people can truly walk in the moccasins of the
user, do they have the right to build a system for them.
Years ago, the Monty Python comedy
troupe did a skit where the Pope was
arguing with the Renaissance artist Michelangelo over the development
of his famous painting, "The Last Supper." In the skit, the artist
misinterpreted the Pope's requirements and originally produced a
painting which included a scene featuring Jello, a kangaroo, a Mariachi
Band, 28 disciples, and three Christs. The Pope, of course, was not
satisfied with this and forced Michelangelo to change the painting,
over the artist's protests. The Pope closes by saying, "I may
not know much about art, but I know what I like."
This same expression can be
paraphrased by the end user to describe the problem in requirements
definition, "I may not know much about Information
Technology, but I know what I need to run the business."
Defining information requirements is
the single most difficult task for
systems people to perform and, even after all these years, it remains
the weakest link in the chain.
"An elegant solution to the
wrong problem solves nothing." - Bryce's Law
Such is my Pet Peeve of the Week.
Note: All trademarks both marked and
unmarked belong to their respective companies.
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 timb001@phmainstreet.com
Copyright © 2009 by Tim Bryce. All rights reserved.
Follow us @Scopulus_News
Article Published/Sorted/Amended on Scopulus 2009-04-10 23:31:46 in Computer Articles