3 ideas to kill your next requirements review session

I often tell my students that although I’m in IT, I don’t work that much in front of my computer. Actually, almost 75% of my job is communication, oral or written. I need to talk with stakeholders to elicit requirements; I need to document & validate those requirements; I need to present those requirements to clients, technical teams, training teams, etc. In fact, communication is a key Business Analyst skill; not surprisingly, it’s one of the underlying competencies of the BABoK.

When thinking about requirements, people often think about endless documents listing business needs, business rules, system requirements and strange diagrams, that they need to approve sooner than later. However, in many situations, requirements will also need to be presented in a non-written way. I found out over time that my stakeholders prefer to be introduced to the requirements documents before actually reading them. It makes their approval and/or review of the documents easier and more productive, and it ensures that I get useful feedback.

Sadly, I have seen too many requirements review sessions where the Business Analyst would just send a Lotus Notes invite with an attached document, show up in the conference room at the scheduled time, and read out loud their requirements document to the poor meeting attendants (yes, we still work with Lotus Notes). Over time, I’ve built my own list of things to do to kill your next requirements review session.

Idea 1: attack your stakeholhers with a useless PowerPoint presentation

Microsoft PowerPoint is a great tool when you use it properly.  However, too many people seem to confuse it with Microsoft Word, and try to stuff as much content as possible in every slide, to be sure that everything is in there. The results are often horrible: while you lead the review session, your stakeholders will try to read everything on your presentation, forgetting that you are talking at the same time. Or they will interrupt you because they can’t read your slides. Or their brain will just stop processing the information and they will start playing on their phones. Bad PowerPoint usage is so common that there is a Wikipedia page about it!

How to fix it: your PowerPoint slides should be a summary that guide your requirements presentation, and not the requirements themselves.  Think of your slides as a table of content to help your audience follow your presentation. There are lots of tips to create effective presentations on the web, but the following guidelines and Mitch Joel’s tips are worth the read.

Idea 2: invite all your stakeholders in the same requirements review session

Usually, the business requirements for a project will come from various stakeholders (customer service, finances, engineering, point of sales, etc.). When eliciting the requirements, a good Business Analyst will hold different worksessions with different stakeholders; this helps to keep the focus on the points that matter to them.  Following those worksessions, the Business Analyst will create a nice business requirements document (or whatever you call it) grouping all the elicited requirements, and will present it for approval.  What’s wrong with that?

The problem is that even if it makes sense to group the requirements in one document describing an unified solution, not everything in that document will be interesting for every stakeholders. Most of them will focus on specific requirements, and will have a tendency to ignore the other ones. If you have a lot of stakeholders involved, the less impacted ones might find the review exercise useless, or might just don’t even bother to show up!

How to fix it: instead of having a big, unique requirements review session, plan many of them. In each of them, you should present the solution big picture first, and then review the requirements that are important for the group of stakeholders you invited to the session. This will allow you to keep them interested to what you actually say, and gather useful feedback from the session.

Idea 3: forget that people can read on their own

The idea behind a requirements review session is to provide some context to your stakeholders, so that they have a better understanding of your requirements document when reading it. However, many Business Analysts see the session as a good time to simply read aloud their document, forgetting that people can read on their own (the only time I usually read aloud documents is for my twins, before bed).

How to fix it: a requirements review session is the best time to provide some context to your stakeholders, and to show your artistic talents at the same time. Do not hesitate to use diagrams and pictures to explain your requirements instead of reading a plain Word document or Excel table (you can even prepare a nice PowerPoint presentation, as long as it’s a good one!).

Don’t forget: it’s all about communication!

A good Business Analyst must be able to communicate and explain clearly the business requirements, especially during a review session. Using many specific sessions for stakeholders sharing the same interests instead of a big one, with a nice PowerPoint presentation supporting your explanations, will allow you to get the feedback you need from your stakeholders and ensure that your requirements documents really reflect their business needs.

Have you noticed other behaviors that killed one of your requirements review session? Share your experience with us in the comments below!

credit: michelleho @ freeimages.com