During a requirements review, oftentimes no one wants to be the first to challenge something or point out a mistake. When reviews are passing along with a false sense of “wow, this is perfect!” I like to mix things up by pointing out an error in my own work or raising an issue with something I’m not 100% certain about.
People tend to go into document reviews with faith in the document owner and not wanting to hurt his or her feelings. Pointing out your own mistakes and uncertainties tends to encourage discussion by giving others real permission to find something wrong or to be uncertain.
I once pointed out an uncertainty I had during a use case review and initiated a 30 minute discussion about a design issue. All I had to do was ask a certain individual in the room, “you know, I’ve been thinking about this data piece, and something doesn’t seem to quite fit together to me. What are your thoughts on it?” In minutes everyone voiced contrary opinions about how that would work and by the end of the discussion we were more aligned as a team than we had been previously.
This technique is most valuable in contexts where you are not getting a lot of input or sense people are not really reading the document. You need to trust the team and you need to be self-confident enough to point out your own mistakes.
>>Learn More About Facilitating Review Sessions
Explore the following articles for more information about how to facilitate meaningful reviews:
How to Conduct a Requirements Review
How to Use a Process Walk-Through to Validate Requirements for a New System
Being a BA is Not for the Faint of Heart
And, to learn more about requirements discovery, check out Adriana Beal’s ebook Tested Stakeholder Interviewing Methods for Business Analysts.
Comment