8 Requirements Gathering Anti-patternsposted by Anna Mar, April 14, 2011
When projects go wrong no one ever blames the requirements. However, seasoned PMs and architects will agree — bad requirements are often responsible for project failure (garbage in garbage out).
Watch out for these 8 common requirements gathering pitfalls.
1. Now or NeverProject methodologies such as waterfall discourage changes to requirements after they have been finalized. (Big Requirements Up Front ~ BRUF)
This now or never approach encourages the business to ask for more than they need (requirements bloat).
2. Jobs for JuniorsRequirements gathering is not particularly stimulating. Busy business teams may relegate junior staff to the task. The outcome is predicable — bad requirements out of touch with business realities.
3. Legacy RequirementsRequirements that replicate the functionality of a legacy system — ignoring the power and out of the box functionality of the new system.
Example: A project to replace a legacy Excel spreadsheet with a web system — users may request web pages that look like Excel.
4. Political GridlockRequirements turn out badly when political infighting dominates requirements discussions.
Requirements become a scorecard of political battles.
5. Too Many CooksRequirements that are developed by separate business silos and then meshed together often do not make sense.
In some cases, no one person understands the end-to-end requirements — resulting in a completely dysfunctional system.
6. Lost ConsultantsOutside business analysts that have little understanding of the business or organization often produce low quality requirements.
High powered consultants have no problem learning a new business and connecting with the right people in the organization to develop requirements. The problem is that very few consulting business analysts are high powered.
7. Exception BloatUsers often feel compelled to systematize the handling of business exceptions. In many cases, the exceptions are so rare that manual processes would suffice.
In some cases project costs and risks are dramatically increased to handle business scenarios that rarely occur.
8. Design by CommitteeThe social dynamics of collaboration often lead to bad requirements. Requirements generated by committees will reflect the social interactions of the group — not business needs.
Collaborative sessions need to be lead by a skilled individual who has final say on all decisions.
Quality planning, control, assurance and improvement.|
Every project creates knowledge. Every project depends on knowledge. The following knowledge management best practices are critical for projects.|
How to win at management.|
How to measure the quality of knowledge.|