Home
Management Guide




 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
management   »  project management   »  8 requirements gathering anti-patterns

8 Requirements Gathering Anti-patterns

        posted by , 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 Never

Project 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 Juniors

Requirements 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 Requirements

Requirements 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 Gridlock

Requirements turn out badly when political infighting dominates requirements discussions.

Requirements become a scorecard of political battles.

5. Too Many Cooks

Requirements 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 Consultants

Outside 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 Bloat

Users 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 Committee

The 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.

Summary

requirements gathering pitfalls

3 Shares Google Twitter Facebook




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.


Recently on Simplicable


Project Management Isn't the Problem: Resistance To Change Is The Problem

posted by Anna Mar
How organizational change management can help your project.

Project Management vs. Management

posted by Anna Mar
Project managers work with program, functional, risk, quality, knowledge and change managers. This is confusion prone.

20+ Project Questions That Reveal Everything

posted by Anna Mar
There's a fine line between being a quitter and recognizing reality.

Why Risk Management Is Important

posted by Anna Mar
Risk management isn't optional for any firm or system that hopes to sustain itself.

Sitemap




















about     contact     sitemap     privacy     terms of service     copyright