One of the most frustrating challenges on a project is when the developers build a solution that everyone thought the business signed off on only to have significant changes surface during testing or even after deployment.
As a business analyst, you can provide tremendous value by not only getting sign off on the requirements, but also getting buy in from stakeholders about what the solution needs to do and how it fits into their workflow before development even begins.
So how do you get buy in and meaningful sign off on your requirements to avoid unnecessarily changes and costs? In this video, Laura shares 3 tips for getting meaningful sign offs that you can use on your next project!
Engaging stakeholders is a critical piece to streamlining your sign off process. Our free guide, 10 Tips for Engaging Stakeholders, is a great place to start so you can supercharge your stakeholder management skills.
One of the most frustrating challenges on a project is when the developers build a solution that everyone thought the business had signed off on, only to have significant changes surface during testing or even after deployment. Business analysts can provide tremendous value by getting not just the sign-off on the requirements, but buy-in from the business stakeholders about what the solution needs to do and how it fits into their workflow before the development even begins.
Gaining buy-in saves a tremendous amount of time and effort and reduces the need for expensive rework late in the development cycle. Keep watching, and I’m going to share how to gain buy-in in a meaningful way on your requirements.
Hi, I’m Laura Brandenburg with Bridging the Gap, where we help you start, succeed, and excel in your business analyst career with weekly videos and business analysis tips and techniques.
Let’s start off with tip number one, which is to focus on sign-off as a tool for obtaining buy-in.
The BA’s job is to get meaningful feedback on the requirements so that they represent what the business actually wants from the solution. In my very first role, we used to walk through the requirements line by line as part of getting sign-off. These meetings would take hours and would require dozens of people to be there, and then I need to get an email confirmation from each and every person about that same long document.
I know in other organizations, sometimes an actual signature, either physically or electronically, is required and sometimes this can be necessary for regulatory reasons. It’s more important, though, to focus on what that signoff actually represents, and that is buy-in. Buy-in means that the business agrees with what’s documented. It actually wants to move forward with having that solution built based on the specifications.
As I matured as a business analyst, I started to shorten my reviews and really hone my approach to make it more efficient.
That leads me to sign-off tip number two, which is to be clear on what input you are even looking for. Most projects have different phases of sign-off. You might sign-off or approve the scope or the business case. You might sign-off on specific requirements, deliverables, such as a business process or a use case, or even a data mapping document. You might have sign-off on the implementation and transition plans.
Gaining sign-off at each stage is significant, and using your business analysis framework to guide that is crucial. It provides a valuable opportunity to engage your stakeholders, to seek their input and ensure their buy-in at each stage of the life cycle so that you don’t get off track doing something that’s irrelevant because you are getting that buy-in incrementally and iteratively throughout the project.
By obtaining sign-off in those major phases, you establish a solid foundation for success, and you also foster a shared sense of ownership from your business team.
Oh, and that business analysis framework I just mentioned, if you don’t have one yet, you certainly need one. You can start by learning about our eight step business analysis process framework that I outlined in another video I did a while ago, which you can watch after finishing this video by clicking below.
The mindset here that you want to bring into your work as a business analyst is, what is the next decision that needs to be made to move my project forward? Always be driving towards that as a business analyst and moving from ambiguity to clarity in the context of that decision. This will keep you moving forward in a proactive and efficient way and not getting bogged out in making decisions about details too early in the project, which often leads to analysis paralysis.
Requirements tip number three is to customize your approach to sign-off based on who your stakeholders are.
Let’s really be honest here. Most of our stakeholders are not all that great at reading requirements. As business analysts, we bring a lot of expertise in writing and organizing requirements and analyzing requirements, and there are times when a requirements review or a walkthrough is the best way to get sign-off. But I found that the easiest way to get buy-in is when I customize my approach specifically to a group of stakeholders.
If you have a hard time engaging stakeholders in sign-off or a hard time engaging them in general, we recently created a new free guide that aims to help boost stakeholder engagement. If you want a copy, you can click below to get a download of it.
Let me just share a few examples of how I’ve customized my approach.
For those who need to buy into the project vision and approach, but not necessarily all of the minute little details, consider who your audience is. Consider what feedback you need from those stakeholders and then look at how to get that specific kind of feedback and buy-in. That is always what you want to be doing as a business analyst to make your process efficient and effective. I really do believe it’s your job to find ways of communicating the requirements and keeping them in sync, and it’s their job to meet you halfway and provide some meaningful feedback.
One question I often get about this is whether requirements sign-off is still relevant in agile.
While agile practices might not require an official “sign-off,” there is definitely an assumption of buy-in built into the user stories that are brought forward for implementation in a sprint. If you want to save unnecessary rework, it’s essential that either a product owner or supporting business analyst gains buy-in from all the necessary business stakeholders on the solution approach and the details before that user story is brought to a sprint for implementation.
To ensure successful signoff and to obtain meaningful buy-in, remember these key steps.
Join me in the next video below where I’ll share practical best practices for efficient and effective requirements reviews. I’ll see you there.
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.
Akarsh MG @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.
Akarsh MG@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!!
Akarsh MG@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.
Akarsh MG@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.
Akarsh MG@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.
AkarshGreat 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.
Michelle Swoboda 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/)
Michelle SwobodaI 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 hereThanks 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.)
MaureenThanks 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.
