We have two features this week: the first and best is Fred Alsup has provided his perspective on best practices in requirements definition; and I have also added and slightly updated a post on Agility and Innovation in the ‘Asides’ page.  Enjoy and have a great week! Best, Jim Ditmore

To deliver cutting-edge, market-advantage systems for your company requires allying your company’s business and operations experts, as well as marketing and sales leaders with technology experts. For a large firm, you may have several if not dozens of projects with these multi-disciplinary teams. Complex projects with participants articulating requirements from different perspectives using terminology unique to their discipline without a rigorous approach is one of the primary reasons for poor requirements. Frequent issues include ambiguous or ill-defined requirements, missing requirements or poorly defined bridges between areas, or worse, a key expert is not focused on their area until late in the project (when it is far more difficult or expensive to correct). Further traditional approaches often result in team members feeling that “everyone’s speaking different languages” or “I’m not being heard”.

This happens both when little time is spent on requirements or, most disappointingly, when even when a great deal of time is spent. Such a result is often due to the requirements elicitation approach and results in negative consequences for the project. The project financial loss includes the extended cost of the system, all of the time spent in meetings trying to elicit the requirements or review documents. And, of course there is the lost opportunity of not having the system that would optimize the work or provide market advantage. And the relationship between the business and IT becomes or remains strained.

Traditional requirements elicitation or gathering methods are often the cause of these issues. Cycling over and over the requirements definition with individual users and experts or small groups in a document-based, waterfall approach results in many issues:

• A lengthy process where each contributor often only sees a part of the envisioned system (e.g., like the 4 blind men touching an elephant and coming up with 4 different conclusions as to what it is)
• Business and technology roles are not clearly defined and often have overlap resulting in user requirements and technical solutions mixed together
• The requirements definitions in a document based capture approach are often overly complex and miss the essence of of what should be done
• Key experts are often overloaded, thus frequently cannot spend adequate time on the area in a traditional process  resulting in either delays or gaps
• The spark of innovation due to bringing multiple different areas to solution for the business together never occurs

In essence, by gathering requirements in such a methodical but piecemeal and lengthy process causes these outcomes. In order to break out and develop far higher quality requirements and spark innovation and outstanding solutions, you should apply a rapid requirements process that brings the contributors together in a structured and intense manner. You will be able to define requirements in a far shorter time period with much greater quality. Very similar to Agile approaches where scrum sessions with a focused set of users drive a tight cycle time to define interfaces or small systems, rapid requirements enables requirements elicitation for large and complex systems with many disciplines to occur in a tight, joint set of cycles.

The essentials for executing a rapid requirements approach are as follows:

• Set aside two or more days for the requirements elicitation. If the system is to reengineer or deliver a business process, add one day for each additional business area the process impacts (e.g., if back office and middle office, then 3 days total, if front office as well, 4 days). Usually it is best if the sessions are 5 or 6 hours per day versus 8 as users can then handle regular priority work rather than interrupt the session.
• Utilize a facilitator and scribe in the sessions. For larger sessions, multiple scribes or assistants are needed. The scribes should be strong analysts, not just note keepers. The facilitator must be skilled at communications and elicitation as well as effective at driving for results.
• Bring together all the key users and providers for the session. Attendance is mandatory, delegation should be frowned upon. Having even one contributor missing can make a major difference, lead to a major omission. And individuals must operate in one role only (e.g., users cannot define how to implement, first this is a requirements session not a system design session and second, this overruns the provider role). Having individuals act in one and only one role during a session, in my experience is of critical importance, if not common practice.
• Facilitators have full control and responsibility for running the meeting, asking questions, and directing other role players in the question and answering. The facilitator should have the ability to build deep rapport, quickly with each participant in the session while balancing that with the need to be assertive and even commanding if necessary.  The facilitator should understand whether expansion or closure on a topic is appropriate and then formulate the right question to include suggesting user requirements (but not make decisions about user requirements).
• Scribes listen and document requirements using a defined grammar. A scribe may suggest user requirements but not make decisions about user requirements or user prioritization.
• Users define the user requirements and determine prioritization. It is best if the users (business experts) also seek to improve business process or synergize during the session. It can be helpful to have process experts (e.g., lean, etc) assist the users in defining their target process as part of the requirements session.
• Solution providers (e.g., technology or operations) ask clarifying questions concerning user requirements. A solution provider may suggest user requirements but not make decisions about user requirements or user prioritization.
• It can also be helpful to include risk or legal experts as part of the team.
• Ensure that your target process includes inherent measurement and quality management as part of each subprocess as appropriate.