Getting Consensus on Business Requirements: Tips and Traps - Slide 5

Traps that Get in the Way of Consensus Building

The focus of requirements definition must be 100 percent on what is the business objective of the system. Don’t make these common mistakes:

While the requirements may include non-functional specifications such as responsiveness, they should be technology-agnostic.

Arguing the merits of one technology over another, too early in the process distracts from the need to have absolute clarity on what the technology needs to do.

Getting too technical muddies the water on the ownership of requirements since it forces ownership away from the business stakeholder.

Selecting a particular application package too early in the process will tend to disengage consensus building.

Out of every 100 IT projects started, 94 will start over again at least once. Before your company launches its next package selection, implementation, or upgrade, make sure you don’t cripple the project from the start by failing to identify your requirements — the number one reason that projects spin out of control. Make sure that your company has a clear understanding of how important the requirements definition stage is, has a proven way to carry it out properly, and doesn’t skip this critical phase in the rush to get an RFP out the door.

The toughest job in the requirements definition stage is to get stakeholder agreement as a systematic, expected deliverable in the project cycle. It is absolutely essential (even on the most agile of projects) for a team to have consensus on the requirements. IAG Consulting shares what they’ve learned after over 1,000 engagements.