With all the hype around Agile, I feel compelled to state the obvious: not all IT projects are Agile. (And not all should be—although it’s easy to get that impression from Agile champions!) A waterfall approach is still a viable option for many IT projects.
Nonetheless, whether you’re working within an Agile framework or not, teams must be aware of as many project requirements as are knowable. If you miss a key requirement, you are bound to make a poor choice around project feasibility, platforms, applications, use cases, partnerships, or other fundamental components. Agile doesn’t give you a pass for not producing comprehensive requirements. It is always a prudent practice to define as much as you can about the solution you are building.
But gathering requirements can be one of the most challenging aspects of an IT project. It’s easy to fall into the trap of thinking that requirements are more complete than they are.
Producing “complete” requirements is like traveling at the speed of light. You may get close, but you never really achieve completeness.
Plus, if you trick yourself into thinking completeness is within reach, you’re bound to get sucked into the black hole of despair once you realize that you’re farther away from the finish line than you thought.
Let’s shoot for “comprehensiveness,” and characterize an ideal set of requirements as everything that we know today about the desired solution.
The following 6-step requirements gathering process is my tried-and-true way to develop comprehensive requirements that will guide the team along the project lifecycle. Keep in mind that you are only beginning to approach comprehensiveness when you are in the final stages of this process.
1. PERFORM INTERVIEWS
Capture the vision for the project. Especially on long-term initiatives, the project vision will be crucial to remind people why successful execution is worthwhile. Meet with senior management and ask questions about the purpose of the project: Why is it being done in the first place? Who will benefit? Who will own it? How will we know we’re successful?
2. GATHER USE CASES
Meet with a cross-functional representation of stakeholders to understand if and how the project will impact how work gets done. Who will be affected? How will the system be integrated into a process? What information is necessary to complete a given step? What are the variations? Most importantly: What are we forgetting to ask?
3. RUN CURRENT- AND FUTURE-STATE WORKSHOPS
Examine current business processes carefully to reduce the chance that functionality will be overlooked in an implementation, and also to identify opportunities to eliminate waste. In implementing a new solution, organizations have a unique opportunity to optimize activities. It’s much easier to streamline processes during an implementation period than during business-as-usual. Map out the current-state to find inefficiencies and lag times. It makes sense to use an external consultant to run a Value Stream Mapping workshop.
4. IDENTIFY TRAINING AND ACCESS NEEDS
Ask questions to understand what, if any, external help will be necessary throughout the project, where there are competency gaps, and when peaks and troughs can be expected. In addition, document all necessary interfaces (inbound and outbound), required licenses, and anticipated customizations.
5. DIAGRAM NEW PROCESSES
Create a visual representation of the desired state. In this stage, create diagrams of the complete end-to-end processes for each scenario as imagined in the new system. Ensure that the diagrams that you create cover the processes already captured. Throughout the implementation, this type of diagram is useful as a checklist – once a function is created, tested, and deployed, it can be marked complete.
6. VALIDATE WITH STAKEHOLDERS
Review documentation with stakeholders and project team. Gather decision-makers, users, and other stakeholders, and present the gathered requirements. Welcome questions and feedback. During this step, there may be further research assigned to the project team to ensure that all bases are covered. Reviewing the requirements with stakeholders early and often highly reduces the likelihood of surprises later on.
By the end of the 6th step in this process, you will have confidence that your requirements are as close to complete as possible, without being overly confident in their totality. A healthy dose of skepticism about what requirements are (and are not) will keep you on the look out for opportunities to improve upon them along the way. These complete-as-far-as-we-know-it requirements are applicable to any type of IT project: waterfall, Agile, or whatever comes next!
