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.

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

For a listing of Tim’s Pet Peeves, click HERE.

Copyright © 2009 by Tim Bryce. All rights reserved.