Fred Alsup has provided this best practice material on requirements definition. This reference page complements the project delivery best practices for other aspects of delivery.
Requirements Definition: 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.
By bringing everyone together in a structured and facilitated session, connections are made, misunderstandings addressed and synergies achieved that just would not happen otherwise. Full and engaged customer and supplier representation is a common sense that does not commonly occur with traditional methods. With this rapid requirements approach you will get higher quality requirements in far less time with greater participation and better solutions. And you will start your project off with high quality requirements that are much more likely to lead to project success. For more information on Rapid Requirements, don’t hesitate to visit the site.
Failure in the design or definition areas is often due to what I would call ‘beating around the bush’. In many projects, getting the real work done — well-defined requirements, the core engineering work, thorough testing is hard and takes real talent. Many teams just work on the edges and don’t tackle the tough stuff. I recommend ensuring that your project managers and design leads are up for tackling the tough stuff in a project and doing it as early as possible (not late in the cycle). And when it is done, it should be done fully. So, some examples:
- if requirements are complex and ambiguous at the start, a good project manager will schedule rigorous project definition sessions. The PM will ensure broad participation, and good attendance and engagement at the meetings. Leverage the material above for Rapid Requirements to quickly elicit the definitions needed. Or, the project team will use an agile or highly iterative incremental approach to take back to the user interfaces and outputs for early clarification and verification.
- if new technology is being used, or there is a critical component or algorithm that must be engineered and implemented, then work begins early on these core sections. A good PM knows you do not leave the tough stuff to be done last. In particular, these means you do not wait for the final weeks of the project to do complex integration. Instead you develop and test the integration early with stubbed out pieces. Pilot and test, if necessary in parallel, the tough stuff. And if there are major hurdles not anticipated, then you will find them out early and you can kill or alter the project much earlier with far less sunk costs.
- as CIO, make sure that major IT initiatives that your company is investing in make a difference where the rubber meets the road. The system must be easier to do the most common tasks, not just lots of features and cool. You want to make sure the front line staff will want to use the new system (not be forced to convert).
- in sum, the approach for the design and implementation work should be incremental, parallelized and iterative rather than serial, waterfall, or as I like to call it, ‘ big bang theory’. Waterfall can be used for well known domains, well understood engineering, and short or mid-range timelines. Otherwise, it should be avoided.
Best, Jim Ditmore and Fred Alsup