May  2006     Edition 13
The Infamous Requirements Document

A Requirements Document is a crucial element

of communication between the people who want something and those who build it.  Why infamous?  Ever hear “That’s not what I asked for!”   Technology Projects, whether coordinated between IT and the rest of the company, or between product development and marketing, sales and customers, often have numerous misses between what people thought they were getting and what was delivered.  A HeadScratcher to solve.

The Post Mortem of a miss will often reveal

that the requirements were ambiguous, or how people thought it would work is different then the way it was implemented.

Wouldn’t a really good requirements document help avoid these issues?

True, so how do you get there?

The flaw that exists in requirements document creation is the initial assumption

; “Since users know what they want, they should document it”.   What if the initial assumption was changed to: “Users know what problem they would like solved, but for the details of the variety of possible solutions, most are not as versed”.

Turn it around.   What if the builders wrote the requirements?

  They would have to sit with the users, understand what the users were trying to accomplish, and put it into the language that a builder understands.  They could suggest things that the user would have never thought of that might simplify the whole problem.   Iterations could be real time, not with umpteen versions of the requirements document. 

An Analyst

.  Some companies solve this “communication” challenge with a person known as an analyst.  These folks have a deep understanding of the application as well as a variety of technologies.  The successful analyst needs to fully understand both worlds … a difficult challenge in a fast changing technology and user environment.  If you’re in high tech a good analyst will be hard to find.  

Two Heads are better than one

.  When was the last time your IT developers sat with your customer care people and “watched them work”.  A 4 hour investment could result in that IT person coming up with a variety of productivity saving ideas that the customer rep may have never even imagined could be done.   Together they could write requirements for modifications that would have normally never existed and are exactly what is needed to solve a hard to describe problem and even harder to describe solution.   By doing this, you’re creating that “analyst” with the combined skills of two people.

“I’m waiting for the requirements”

, a common statement from a builder to explain why they haven’t started a project, and a clear indicator that you’re going down the road that will produce a sub-optimal requirements document.  The next time you hear this, it will do you well by responding “go out and get them”.

The Takeaway:
Technology people know what’s possible. Users are dealing with now problems.  Putting these heads together with the job responsibility of defining AND writing the requirements will result in a much higher quality “requirements document”, and even more important,  solutions that neither would have suggested independently.

If you like this edition,

click here to get a Free Subscription to The Headscratcher Post.

  A monthly post with tips and techniques about problem solving, creativity, innovation and critical thinking.

Think Smarter Book Image

Check out our Workshops

• Critical Thinking for Problem Solving and Decision Making (Core, Core+Advanced)
• Advanced Critical Thinking and Innovation
• Advanced Critical Thinking and Decision Making
• Critical Thinking for Supervisors, Managers and Leaders

Visit us at

If you're not already a subscriber to The HeadScratcher Post,
Signup Here

Previous versions of The HeadScratcher Post

Critical Thinking Techniques for Problem Solving, Decision Making, Innovation and Leadership.
Our Mission;

To help people become better HeadScratchers! We teach critical thinking techniques to managers, leaders and individuals resulting in the improved performance of an individual and organization.