I can remember at times being frustrated at the lack of involvement in requirements validation on the part of some of my business stakeholders. It bothered me that we were doing this work for them, and they didn’t seem to want to take the time to give us the feedback we needed.

Then it struck me. One of the things I liked least about my job was doing peer reviews on my teammates’ big, thick, documents of declarative requirements. I didn’t like how long it took me to actually read and then piece the information together to the point where 1] I actually had some notion of the “big picture”, and 2] I could actually give meaningful feedback. And I’m a business analyst!

How about a little empathy?

When forced to “eat some of my own dog food”, I realized that the problem is usually not that the stakeholders didn’t want to engage as much as that we were making communication way too hard for them. Think about it – if we’re asking these business stakeholders to take a few hours of their time to digest and try to understand a long, detailed document, then another couple hours to sit in a meeting to talk about it, only to have to repeat the process 2 or 3 times until we’d beaten them into submission and extracted that signature, then they’re not going to be the most willing participants in the process.

In many cases, some of these business stakeholders were involved in more than 1 IT initiative, so multiply that time and effort by 2 and sometimes 3, and now you can understand why we were having such a difficult time getting stakeholders to willfully engage.

I think the golden rule can be effectively applied here. We BA’s would be well served to not to ask our audience to review something that we would dread reviewing ourselves. Perhaps the easiest way to get customers to engage in the requirements process is to make it easy (or easier) for them to do so.

With that in mind, here are a couple pointers that have served me well in preparing deliverables for stakeholder review:

1. Use visual models to facilitate understanding

Visual models minimize prep time required and present the material in a format that is easy for stakeholders to understand. One thing that has worked well with my team is to distill the functional requirements/user stories/whatever into a few slides of visuals with process flows and mock-ups with callouts showing conceptually how the requirements would be met in the system.

This gives the stakeholders a chance to see the requirements in a context they understand without having to go through the jigsaw-like exercise of piecing together a cohesive view of what we’re trying to accomplish from tens or hundreds of hierarchical requirements.

2. Work from the summary, but keep the details handy

Despite the ease of using the visual summary, some stakeholders will want access to the “fine print”. Sometimes questions will arise that aren’t covered in the summary slides. In this case, I would make sure to have the detailed documentation handy for reference and to add depth to the discussion as necessary. If stakeholders want to review the full documentation, I am always glad to provide it.

We’re not trying to hide the details, just trying to ensure that we focus on the most important items instead of getting hung up on the nuances “shall” vs. “must” and other insignificant semantic or technical issues around verbiage and document organization.

Reviews can be a positive experience, and one that stakeholders look forward to participating in. It requires more work on our part, but as facilitators of knowledge transfer, it is incumbent on us as BAs to make it as easy and productive as can be for our stakeholders to engage in the requirements process and provide meaningful feedback.

What are some ways that you or your team have made it easier for your user and business stakeholders to engage in the requirements process?