Software for the finest computer – The Mind

Posts Tagged ‘Requirements’


Posted by Tim Bryce on February 17, 2010

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!

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

For Tim’s columns, see:

Copyright © 2010 by Tim Bryce. All rights reserved.


Posted in Business, Computers, Management, Software, Systems | Tagged: , , , , , , | 1 Comment »


Posted by Tim Bryce on March 10, 2009

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


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

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

Copyright © 2009 by Tim Bryce. All rights reserved.

Posted in Computers, Management | Tagged: , , , , , | Leave a Comment »

%d bloggers like this: