Tips & Traps in Getting Consensus on Requirements
Since it is essential for a team to have consensus if it is to lock a requirements specification at a point in time and after that to manage change control against this specification.
Below are some tips and traps on how to do this.
Tips:
Stakeholders must OWN the requirements
It’s right to say that stakeholders must feel a sense of ownership of the requirements, but we see all too often a process for requirements elicitation that diminishes this sense of ownership. A sound process for requirements elicitation includes:
• Holding facilitated sessions where all stakeholders are present
• Using techniques and templates that engage the non-technical participant
• Only focus on business needs — not technologies.
• Setting the expectation that the stakeholder representatives will sign off on the detailed requirements specification.
Speed and efficiency are the essences of the process
Stakeholders will not participate if they feel their time is being wasted. Companies need to drastically cut the amount of time they demand from users to define their requirements as well as the time to produce and approve documentation of these requirements. The essence of getting speed is to use a highly disciplined approach to managing the elicitation sessions. Companies may be employed to facilitate these sessions or to teach techniques for ensuring that the right questions are asked at the right times, and to prevent a group from going backward to rehash decisions that have already been made. If done correctly, these sessions should be productive, comprehensive, and exciting for participants. The benchmark speed should be to document a process flow, data flow, and business rules between 40 and 50 functionalities (i.e., use cases or events) per week.
Defined beginning and end in the requirements gathering stage
Stakeholders will participate in a process in which there is a clear beginning, clear momentum during the process, and a valuable product at the end. If the requirements definition process starts to wander, stakeholders lose interest, and then it is extremely difficult to rebuild their motivation and energize the project.
It is often helpful to use event-based techniques for managing the process, and techniques like object-relationship tables for conducting definitive tests on the completeness of the requirements. Participants can then more easily keep track of progress toward completion, and understand precisely the degree of completeness for the content already extracted.
Traps:
Getting too focused on technology too early in the process
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.
Insufficient detail in how the data flow needs to be handled
It is relatively easy to get consensus on capabilities statements, high-level functions that a system needs to contain, and general scenarios on what you would like to accomplish that show how this is different from the current state. But this level of detail is insufficient to compare application vendors reliably, and it is a trap to think that consensus built at this level is adequate.
The issue is that the application may not manage the data flow in the same way that your people currently perform the work or the data may not support your reporting requirements. This won’t be apparent from a high-level view of the requirements and the proposed solution. The idea is to use the data flow to eliminate vendors that either cannot comply with your specification, or where customization to get compliance would be too expensive. Likely this group is 3 out of 5 otherwise compliant vendors.
“Best Practices” Trap
One of the claimed advantages of a package is that it embodies industry best practices. Obviously, a company wants to make a decisive leap forward in process efficiency through the implementation of a new package, so it is easy to get distracted by this prospect.
However, without knowing the degree of change or the acceptability of the new process to the people doing the work, these best practices become points of resistance. Second, it is difficult to precisely control the scope and ensure that essential aspects of functionality are not lost in shooting for an often vaguely understood “uber-function.”
When looking at best practices, keep le Chatelier’s Principle in mind: the greater the stress you put on a system, the more the system fights back to return to its state of comfortable equilibrium.
