While requirements walk-throughs can be a useful technique to get sign-off on requirements, they are not always appropriate.
Before exploring some alternative approaches, let’s take a step back and think about what problem we’re trying to solve with requirements reviews.
- Reviews seek to align stakeholders around scope, either of an entire project or a subset of a project that directly impacts them.
- We want stakeholders to understand what is changing and how this change will impact them.
- We want to reduce (or even eliminate) unnecessary rework by validating our assumptions, getting meaningful feedback, and working through options before we invest valuable development time in building the solution.
And I’d contend these objectives can be met using multiple different business analyst techniques. Walk-throughs are sometimes the best technique. But there are other ways to consider too.
Factor these into your approach to requirements reviews.
Who Are Your Stakeholders?
Do your stakeholders know how to read requirements? Seriously. Do they? Many of your most important stakeholders won’t give a lick about your beloved requirements and it’s self-centered of us to think they can and should. It’s easy to lay blame when these individuals don’t provide the feedback we’re looking for.
It’s our job to get meaningful feedback despite whatever short-comings our stakeholders might have.
- If they need pictures, draw pictures.
- If they are good at reading lists, create them.
- If they want a story, tell it.
It’s our job to keep all the various ways of communicating requirements in sync. It’s their job to meet you half way and provide meaningful feedback.
Here are just a few ideas for communicating scope across your organization:
- Create high-level documents, even slide decks for engaging presentations, for executive-level stakeholders.
- Consider one-on-one meetings for your most important stakeholders, such as the CEO, who hold the funds but probably don’t want the details.
- Compartmentalize the details that are important to each individual or functional group. Schedule separate meetings, unless their concerns overlap and you need to facilitate collaboration.
- Visuals speak louder than words, especially words that encompass requirements lists. Use diagrams to talk through complex processes and wireframes to simulate new software experiences.
- Save the details for the people who care and have something to say about them.
What Input Are You Looking For?
Before scheduling a requirements review meeting, take some time to consider your desired outcome.
- What do you want to achieve?
- What do you want to learn?
- What input do you need make the project more successful?
Here are some useful tips for getting the feedback you are looking for in requirements discussions:
- If your purpose is discovery, list out your unknowns in a list of discussion points for the meeting aka a meeting agenda). Organize them in a logical manner than aligns with a visual you can talk through.
- If your purpose is to validate and flesh out hidden assumptions, have a list of talking points to ensure the attendees are “thinking through” the process in the same level of detail you are. Maybe this can be accomplished through a use case review, but maybe you are just as well off talking through a diagram and keeping the use case to yourself.
- If your purpose is to facilitate collaboration where there is conflict, have a preliminary understanding of each individual’s point of view and some ideas for resolving the issue.
- What are the uncertain parts of the process you want to validate? Would a process walk-through be appropriate?
- What pieces do you know you know and can be skirted over or avoided in a review altogether?
None of this above should be read to say that requirements don’t matter or that the deliverables are unnecessary. I’ve analyzed many a problem by writing a use case that no one ever saw except the developer–the content of the use case was fully validated while the “use case” itself was not.
So yes, requirements matter for many, many reasons…but when it comes to reviews, consider separating how you document your requirements and how you communicate your requirements for the sake of getting meaningful, targeted feedback that will make your software projects more successful.
Get Better Input from Your Stakeholders
In Tested Stakeholder Interviewing Methods for Business Analysts, Adriana Beal walks you through how to conduct more effective stakeholder interviews so you don’t overlook critical requirements.
I stumbled upon your great thoughts almost by accident…but what insight! This comment is years down the road and so i hope its not too late.
Why i like the “WIFY” idea allot is my belief that even walk throughs aren’t necessarily the problem. Its just that we have to sell each component…to pitch so to speak means the product is the review-able product augmented by “WIFY”, buy-in/comprehension the pro-quo side, sale pay-out would be alignment outcome and dividend the benefit of a repeat customer(for future engagements based on trust).
Social science augments the core product and i’ll end by saying perhaps we need a marketer inside us-all the time as well as other.
@Adriana – I know its a great result; i will update you more on this as it progresses.
It’s great to know, Akarsh! 80% is a great result — goes to show that you were very effective communicating the “local benefits” to your audience. Feel free to write any time you have other questions and comments.
@Adriana – Your idea on creating “local-benefits” works great; even though i was not able to get 100% attention of all the SME’s currently it has worked at least to grab the attention of 80% of them.
During this week i will be having couple of more discussions with some more SME’s i should be able to get there attention also on this; more over a visual presentation which show cases “current” & “future” benefits which covers both “local-benefits” and “high-level” benefits has also worked well.
I will contact you if need any more information.
Thanks a lot!!
@Adriana – I will be presenting the benefits to SME’s in a week/two weeks time; i will let you know how it goes; i agree little “social science” is required ;).
@Tola – I started my career as a developer too i understand what you mean; i have always focused on the “high-level benefits” but as Adriana was pointing out now i have started working on “local-benefits”. I am making sure the presentation covers every aspects also working on a presenation which show cases “current” & “future” benefits.
@Adriana: you are 100% right about the fact that the top managers are not doing a good job communicating the benefits and importance of the project down the hierarchy, and that “WIIFY” is what @Akarsh needs.
In my former job, i was on a team working on a internet banking project to be developed in-house. The project was going to replace the existing software in use, and the while the top managers saw the benefits of the cost savings, as there wouldn’t be any need to pay thousands of dollars for annual support fees, the mid-level SMEs felt the old system was fine and developing a new one was just another “stress”.
Not until we began to let them see the what was in it for them (nobody called it WIIFY at the time, 🙂 ), did they start showing interest and commitment to the project. The important point here is that, in that case the mid-level SMEs started seeing what was in it for them at the Testing Phase (when they saw the new features the system offered vís-a-vís the existing one), and that led to alot of change requests which really affected the project scope.
So @Akarsh, i think it’s crucial you focus on WIIFY at the early stage of the project. I was more of a developer than a BA on that project, and so know i crazy it was having to write more codes and tweak existing designs.
Thanks @Adriana and @Laura. You guys are doing a great job. I hope to know as much you guys someday.
You are welcome! Tells us later what happened. A little “social science” sometimes is the best solution for this type of problem ;-).
People are much more motivated when they can see how their local efforts are contributing to organizational results, but when this connection is too distant (like in the case of the “high level” benefits you mentioned) , it becomes too blurred to encourage participation. If you can make them see more clearly the link between the solution, their local contribution, and the overall results, I’m sure the interest in participating will increase.
@Adriana: Excellent suggestions; i will keep mind on “WIIFY” and “local benefits” 🙂
We had discussed and created a presentation on pointing out “high-level” project benefits once its completed to every users but looks like that presentation did not cover the “local benefit” as you pointed out.
Now i have started working on visual presentation pointing out benefits realted to SME’s; i think this should work me.
Thanks a lot!!
@Akarsh: I have had a similar experience. Typically this means that the top managers are not doing a good job communicating the importance of the project down the hierarchy, and how it relates to the organizational goals. Not seeing it as a priority, mid-level SMEs won’t feel compelled to participate as much as you would hope for.
What has worked for me is to find a way to convey to these SMEs the “WIIFY” (what’s in it for you). Will the project make their lives easier somehow? Generate any palpable gain for them specifically, as opposed to just to the overall system? Similar to the empathy for one person in need vs. a large number of victims of a disaster, people find it much easier to relate to something for which they can see palpable impact, rather than just theoretical gains. So, one idea is for you to try to find one aspect of the system you are building that will provide this type of “local benefit” and highlight it to the SMEs. Even this local benefit is small compared to the value to the business in general, it may be much more convincing because that’s just how we humans react to things.
@Laura and @Adriana:
Excellent points and suggestions;thanks a lot.
In the current scenario for me high-level stakeholders are highly active and they are more involved but the problem i am facing is handling mid-level SME’s who do the work each day and also as you suggested i have used the right strategies to keep all the stakeholders engaged in the process of determining the optimal solution for a business problem but still not able to keep the SME’s engaged.
Indeed, excellent point, Laura. I was assuming in my answer that the BA has conducted a stakeholder analysis and is keeping stakeholders involved in the appropriate level (i.e., top level executives are involved when a crucial decision is needed; subject matter experts to clarify a certain aspect of a business process, and so on). Different types of stakeholders will have different levels of involvement, and require different levels of detail about the requirements, project metrics, etc.
Akarsh, Adriana provides you with some great advice for keeping stakeholders engaged. I’d only like to add that if certain stakeholders are consistently not engaged at a detailed-level, it may be that they are the wrong stakeholders to have involved in that discussion. Especially if they are operating at a high-level of the organization, you may need to involve them in validation of the scope and goals of the project and then work through those details with the subject matter experts who do the work each day. This is just something to watch out for.
Laura
@Akarsh:
Engaging presentations are useful to “make stakeholders care”. Chapter 9 of “The Upside of Irrationality”, from Dan Ariely, titled “On Empathy and Emotion: Why We Respond to One Person Who Needs Help but Not to Many” explains how much easier it is for humans to relate when you are talking about a specific situation (in the case of charity, one suffering person, instead of the number of victims of a huge earthquake). In my experience, the same applies to business situation. Comics have helped me single out a situation that demonstrates why a problem needs to be solved, and “tell a story” (e.g., instead of using statistics of inconsistencies and duplicate data to convince stakeholders of the importance of centralizing employee data, I illustrate the problem with comics showing a manager wasting a lot of time trying to set up a cross-functional meeting with people in the organization because they have different names in different systems (such as Rebecca O’Neal and Becky O Neal).
After that, it becomes much easier to keep stakeholders engaged — now they have a concrete example in their minds of why the current situation needs changing, and will be more willing to answer questions and make decisions needed to move the project forward.
Another suggestion is to use a wiki to keep project information, and encourage stakeholders to check it out frequently. This makes progress much more palpable for stakeholders, and give them more visibility into what it takes to go from a business need to a completely defined, optimal solution (https://www.bridging-the-gap.com/wiki-requirements-management-benefits/).
Sure, stakeholders will never care about our “beloved requirements” (as Laura rightly put it in one of her articles) the same way we do, but with the right strategies, business analysts can definitely keep stakeholders engaged in the process of determining the optimal solution for a business problem. I hope you will try these strategies I mentioned to see what happens.
Great post Laura and also nice comments from everyone.
@Adriana thank you for sharing the link on requirements review using comics.
I would like to know is how you do handle to those stakeholders even after providing engaging presentations/Visuals its very hard to keep them occupied to check on whether the requirements gathered are covered or not; all they want is the end results but there requirements changes when you show them end result after implementation.
How can we keep these kind of stakeholder occupied in the project?
Well this has been the case with few stakeholders for me.
Regards,
Akarsh
HI Tola, Good for you! It can be difficult to break what seems like a fool proof process and focus on what your stakeholders really need. Your situation is not uncommon. Just this week I was speaking to BAs in Denver about how stakeholders often just want to see the results (i.e. implementation) and the BA process can feel to them like a lot of busy-work put between them and their end goal. This is probably your stakeholder’s perception in this case.
As the BA, you need to both ensure the results of formal documentation are achieved — i.e. you have analyzed the problem and gained the appropriate buy-in before implementation. How you get there will depend a lot on your audience. It’s good that he is committed to the idea that the needs of the clinic are understood. The more you can communicate how the activities you are doing (i.e. the documentation) will help ensure that the needs of the clinic are understood and communicated, the more he’ll be likely to buy-in to the necessary documentation to make this happen.
Good luck.
Best,
Laura
Great post Laura, and great comments everyone.
I think a “formal” work through is best with the right motivation and the right audience, as stated by Laura. In my case, ‘am working as a BA on a software project for an Eye Clinic. My audience are not used to any form of “formal” documentation – use cases, requirment specification etc. So I just have to document the requirements and run it with them (seperately) in followup interviews to validate the requirements.
To make things worse, the project sponsor who owns the clinic isn’t so concerned about the “documents”, he just wants to be sure the need of the clinic is understood and the software can be developed. I got really confused (and i still am a little), but am following Laura’s advice to adapt my documentation to what suits my audience. So I think it’s really about the audience.
Laura, you know me, I am always up for writing about being a BA. So count me in!!
Hi Michelle,
I do think a walk-through can work with shorter documents, the right motivation, and the right audience. It all depends on your situation.
I like what you are sharing about the walking through the new process with the maps and documents. It sounds like something I learned about from EBG’s Roadmap to Success Course — selecting scenarios to use to guide the walk-through — this was suggested as a technique to drive up understanding and engagement. It’s something on my list to try…I just haven’t had the opportunity yet. It would be great to learn more about your first-hand experience with this technique sometime if you are up for another article. 🙂
(For more about the Roadmap to Success course, view this page: https://www.bridging-the-gap.com/business-analyst-career-resources/requirements-training-roadmap-to-success/)
I struggle with this as there are many time we do have to validate the requirements – and everyone views and learns and listens differently (show, read, tell etc.) In large groups, with many hundreds of stakeholders but more thank 25 business owners – I have found that a walk through works – but only if I can get them invested in the process. Do they see the benefits of the change? Do they understand the impact on their business unit? Can they see the cost reductions/reduced cycle time etc as a win for themselves and for the company?
One new way I have learned from my recent position is to walk through the new process with the maps and documents with a real order that has been closed off. This makes it more real for the business owners and SMEs and although it is new to me I do see real value in putting it into this context.
Michelle
Hi Chris,
Thanks for your comment. There are definitely times when it is helpful to have multiple stakeholders in a room together.
If your desired outcome is to generate a bunch of feedback, have everyone hear what everyone else has to say, and move relatively quickly toward alignment, this is probably a good way to move forward. But you have to realize that it might take more of each stakeholder’s time to go through all the requirements together and if too much of the meeting is irrelevant to particular people, you might loose their interest and fail to achieve your objectives anyway.
In general, it has seemed to work best to keep most of the stakeholders together at a high-level, then work through the more detailed requirements with specific groups. But you are right, you can lose some valuable cross-generation of ideas with this approach.
Laura
I’m a wee bit disturbed at loosing the ideas/things remembered-feed-off-others in the meeting.
We removing the stakeholders from each other in separate meetings aren’t you going to loose too much of this?
When dealing with large amounts of requirements and huge volumes of documentation, an alternative may be to check all the high priority requirments with them, and then a random subset of lower priority reqs as a sample set. Additionally, if a prototype is part of the requirements delivery, it can serve to visually congeal the delivery for the customers, if it was created from the same requirements documentation that the eventual end product was.
Hi Adriana and Alex….thanks for the great comments.
Adriana, I love the comic strip idea. I had not run across that one. I can definitely see where that would be a useful validation process!
Alex, if getting the contract signed “in blood”, so to speak, is the goal, then a formal requirements walk-through might just be necessary. But I’d venture to guess there are larger issues of distrust and missed commitments when that is indeed the goal and I wonder if there aren’t other ways of dealing with that issue head on.
Laura
Thanks for letting me know about the bad link.
My further comments are at Better Projects here
Thanks for the article Laura. I couldn’t agree more with your article and comments.
However, I would be interested in people’s opinions about when IT IS necessary to have a requirements walkthrough.
There is a point when you need commitment or signoff from stakeholders. This is necessary when estimates are provided and requirements need to be frozen (not talking Agile here, obviously!).
In this instance, the requirements document is more of a contract and the walkthrough of the requirements is necessary to flush out any more issues and achieve consensus and signoff across a group of stakeholders.
It doesn’t make for a ‘fun’ event but I haven’t found any better way of achieving this goal.
Does anyone have a different experience or alternative suggestions?
I couldn’t agree more. In over 10 projects I’ve participated in recently, all with formal requirements review, I would say only one benefited from the structured review (a very complex system with a cohesive team used to long walkthroughs to discuss the changes from multiple perspectives).
One method I find very useful to engage senior management in requirements review is using comics, in a way similar to this: http://www.boxesandarrows.com/view/comics-not-just-for
(Even for more serious audiences in the financial industry, in my experience it tends to be a highly effective technique.)
Thanks for the information on reviews. I have to agree that less is more and focusing in on what is important to the various audiences is a great way to align stateholders.
Cheers for sharing. I added a few techniques I have used Here.
Visuals do speak louder than words, so rather than just static use of diagrams make use of interactive *visualizations*
See article linked above, for more info…