How and why to do requirements walk-throughs

All too often I’ve seen this important step in the requirements process skipped, often to the detriment of the project as a whole and especially to the detriment of aligning the business and IT.  A requirements walk-through is just that, a meeting where you gather all of your stakeholders together and walk-through the requirements documentation, page-by-page, line-by-line, to ensure that the document represents everyone’s complete understanding of what is to be accomplished in this particular project. Simple enough. Boring enough.  But valuable enough that it just simply has to be done.

Why is the requirements review valuable?

1. Your stakeholders will actually read the document and ask questions about what they don’t understand.
2. Your stakeholders will hear the comments that others have, and this often creates new thoughts on the requirements.
3. Your stakeholders will have to look you in the eye and say that everything they need is there.

Answers to the most common criticisms:

1. But I email the document out for review, that way everyone can do this when it works for them and I get better input. Be honest with yourself. In today’s workplace, people have competing priorities and are constantly multi-tasking.  Opening up and reviewing that document is not the most exciting or probably the most pressing the most pressing task on their list. Few stakeholders will provide their best input in this manner.  Those that will are probably conscientious enough to read the document before your meeting and come prepared.
2. I want an email sign-off because it’s traceable. Nothing about the requirements walk-through precludes an email sign-off.  But if your reason for using email is to get a passive sign-off and cover your you-know-what, not to actually create the alignment that the sign-off actually entails, then you are doing your technology team a disservice.
3. My stakeholders don’t have time. Then one of two things is wrong–either you’ve identified the wrong stakeholders or you’re working on the wrong project.  Either of these issues might not be your fault.  But if the people benefiting from and contributing to the project can’t spend 2 hours in a room finalizing what exactly that project is supposed to do, there are larger issues at play.

How to run a requirements review session:

1. Set the stage.  Send out an email/calendar requirements with the document and a description of how the meeting will go.  Let everyone know that their role is to provide any feedback on the requirements and ultimately sign-off on the document.  Re-iterate this message at the beginning of the meeting.
2. Be prepared.  Have a few extra hard copies.  If possible, project the document onto the wall using an LCD unit.
3. Lead the walk-through section by section. Give everyone an appropriate amount of time to read and consider the requirements in that section.  Ask for comments, clarifications, and questions.  Ensure the discussion focuses on the requirements, not how to build them or what tasks need to be done or the marketing plan.  As the review group agrees to updates, note these on your hard-copy or make them electronically where everyone can see them.
4. Ask for sign-off.  Say “I’ll make these edits and distribute an updated copy.  Provided I get all these notes incorporated, is everyone prepared to sign-off?  Are there any lingering issues or concerns?”  Look at everyone in the room for a visual cue.

Some common pit-falls in execution:

1. Doing the requirements walk-through too early. As BA, do your homework first or you will be wasting everyone’s time. Vet out the big issues in small teams. Meet individually with the stakeholders to make sure you understand their needs.  Recognize and elevate conflicts in requirements so these are resolved.  By the time you do the walk-though, requirements should be almost ready to sign-off and the purpose is really to make sure everyone is aligned and to trigger any last gotchas.
2. Reading every requirement aloud. I’ve done this and it worked, but it was inefficient and I wouldn’t suggest it. Instead, review the requirements in meaningful sections that people can review in the meeting.
3. Not including the right people. Ideally, your review should include one person from every area of the business impacted by the requirements, good examples include marketing, operations, product management, customer service, and IT.  Often times you’ll need more than one person from a group because of the decision matrix within that group.
4. No one says a word.  Be prepared with some questions/comments to get discussion going. Often people don’t have something to say but don’t want to appear to be critical of your work. Even throw a few mistakes in to make sure people are paying attention. If they aren’t you can point them out yourself and that can often trigger similar responses from others.
5. Feedback is centered around typos, not meaningful content. Politely say you’ll take editorial feedback in an email or by hard-copy, unless, of course, the feedback impacts the meaning of the requirement.
6. It turns into a design meeting.  Stop it from happening.  This can be a great time to start your issues list.
7. The business uncovers a fundamental flaw in the project.  No matter how diligent you are in ensuring your stakeholders are ready for this meeting, someone can have a middle-of-the-night insight the day before your meeting and blow it to pieces.  Take a deep breath.  Ask the group if they feel this issue has to be dealt with in order to finalize this project.  If they say yes and you don’t think they are just stalling, you have two choices: you can refocus the meeting to deal with the new issue or disband the meeting and work out a plan to deal with it ASAP.

I’d love to hear your thoughts on the requirements walk-through and especially tips for keeping these meetings interesting and engaging.

By Laura Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura Brandenburg

Related posts:

1. How to align stakeholders around project scope without a requirements review and sign-off process
2. Best practice: Involving Quality Assurance professionals in requirements reviews
3. The myth of the “requirements contract”

Tagged as: entry-level