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.
