A requirements review or walk-through is a meeting where you bring all your stakeholders together and provide the necessary documentation, page-by-page, line-by-line, to ensure that the document represents a complete understanding of what it is. Get this special project done.
Easy enough.
Annoying enough.
But valuable enough that it just has to be done.
Often I find this important step of the necessary process to be avoided, often for the loss of the whole project and especially for the loss of getting all the stakeholders on the same page about the scope or details of a project.
General objection to reviewing a requirement
But I email the document for review, so everyone can do it when it works for them and I get better input. Let’s get honest here for a minute. In today’s workplace, people have competitive priorities and they are constantly doing multi-tasking. Opening and reviewing that document is not the most exciting or perhaps the most stressful task on their list. Some stakeholders will provide their best input in this manner. Those will probably be prudent enough to read and prepare the document before your meeting.
I want an email sign-off because it can be detected. Nothing about walk-through requirements excludes email sign-off. But if the reason you use email is to get a passive sign-off and your-know-what is covered, the sign-off doesn’t actually create that alignment, you’re doing your technology team a disservice.
I don’t have time for stakeholders. Then one of the two things goes wrong – either you have identified the wrong stakeholders or you are working on the wrong project. None of these problems can be your fault. But if the people who have benefited and contributed from the project cannot spend 2 hours in a house to finalize exactly what the project should do, then there is a bigger problem.
When you sit in a meeting to review the requirements specification, you know that people are actually reading it. You’ll also find that one comment leads to another and can help you discover new requirements before it’s too late. Also, a review meeting creates a certain accountability – if you ask your stakeholders to look you in the eye and make sure they are ready to take the next step with the project.
We are agile. Then it’s even more important to review the requirements with your business stakeholders before planning a sprint! Instead of reviewing large documents for the entire project, you’ll often focus on reviewing lists, such as a list of ranked product backlog items for the next few months, or details of user stories for an upcoming sprint.
How to facilitate a requirements review session
- Stage set. Send an email / calendar with documents and a description of what the meeting will be like. Let everyone know that their role is to provide feedback on the requirements and finally sign-off the document. Repeat this message at the beginning of the meeting.
- Get ready. There are some extra hard copies. If possible, project the document to the wall using an LCD unit.
- Lead the walk-through section by category. Give everyone a fair amount of time to read and consider the requirements of that section. Ask for comments, clarifications, and questions. Make sure the discussion focuses on the needs, how they can be created or what needs to be done or not on the marketing plan. Since the review group agrees to update, note them down on your hard-copy or create them electronically where everyone can see them.
- Ask for sign-off. Say “I will edit this and distribute an updated copy. If I include all these notes, is everyone ready to sign-off? Any chronic issues or concerns?” Look at everyone in the room for a visual signal.
Some more general requirements review issues
Requirements are doing walk-through very quickly. As a BA, do your homework first or you will waste everyone’s time. Find out the big problems in small groups. Meet with stakeholders individually to make sure you understand their needs. Identify and improve conflicts as needed to resolve them. When you walk in, you should be almost ready to sign-off requirements and the purpose is to really make sure everyone is lined up and trigger any endpoints.
Read every need aloud. I did it and it worked, but it was inefficient and I wouldn’t recommend it. Instead, review the requirements in the meaningful section that people may read at the meeting.
The right people are not included. Ideally, your review should include one person from each area of the business affected by the requirements, good examples include marketing, operations, product management, customer service and IT. Often you will need more than one person from a group because of the decision matrix within that group.
No one says a word. Be prepared with some questions to discuss. (And if you need help bringing up your questions, download the example of our free need checklist to get the idea. Often people have nothing to say but they don’t want to criticize your work. You can point out your own mistakes, a habit that can often trigger similar reactions from others.
The business exposes a fundamental flaw in the project. No matter how hard you try to make sure your stakeholders are ready for this meeting, someone can get a midnight insight the day before your meeting and tear it apart. Take a deep breath. Ask the group if they think this issue needs to be addressed in order to finalize the requirements for this project. If they say yes, you have two choices: you can refocus the meeting or break up the meeting to deal with the new problem and make a plan to deal with it as soon as possible.
Download a free required checklist
Part of the preparation for a requirements review is knowing which questions to ask. Learn exactly how to view a Sample Requirements checklist with a sample from our Requirements Discovery Checklist pack, which contains over 700 questions, categorized and cross-referenced so you can prepare for your next elite session with ease and confidence.
Click here to download a free sample checklist
