A reader asks:
I am awaiting feedback from a client on a Requirements document. It has been 3 weeks and I haven’t gotten any response. I have already sent an email reminding them. How do I request feedback or even sign-off without sounding too demanding?
Laura’s Response:
As business analysts it’s our job not just to craft requirements documentation, but also to ensure that they reflect the actual business needs. To do that, we require feedback and input from our business stakeholders. So, to start with, I’d worry less about sounding too demanding than about doing what it takes to get your job done.
But let’s look at the potential root causes of this situation and some ideas for circumventing each of them.
#1 – Not Setting Clear Expectations Upfront
Often this sort of problem creeps up because we do not set good expectations when starting a project. Consciously or not, we allow our stakeholders to mistakenly assume that once they meet with the BA once – poof! their wishes will be answered and sometime later the software will magically appear that is exactly what they need.
As BAs, we need to manage the requirements process – and this means setting specific expectations for the roles we need our stakeholders to fill for us to be effective. Otherwise, we run the risk of them assuming that requirements take too long. Every time I meet with a stakeholder, I let them know we’ll be meeting again or collaborating in some way. If I can, I let them know exactly what I’ll need them to do. If I’m not sure, I leave the window open so they know they’ll be on the hook for something.
If your stakeholder doesn’t understand that their delay in providing feedback is holding up the project, oftentimes clarifying why their feedback is important and how this task you’ve asked them to do fits into the overall project lifecycle will get things moving again.
#2 – Asking For Non-Specific Feedback
Another root cause might be that you’ve asked for “feedback” but have not been specific about the type of feedback you require. Requirements documents can be very intimidating for stakeholders (especially when they are longer than they need to be). They may not understand what information you need or how to review the document you’ve sent. They may be looking at this big “to do” in their inbox and making excuses for putting it off day by day.
You can help by determining exactly what kind of feedback you need from the stakeholder. Do they need to review the entire document? Do you need them to answer some follow-up questions? Reframe your request very specifically and it’s more likely to seem doable and therefore get done.
#3 – Project is Not a Priority
If you’ve addressed the first two causes, then it may be that this project simply isn’t important. It may be that your stakeholders don’t understand the importance of the project to the organization, in which case escalating to your management might get things moving. Or, it might be that the project isn’t important to the organization. Try to get assigned to more critical path work.
Your To Do List
Since it’s been three weeks and your request is hanging out there, here’s what I’d suggest as a series of next steps.
- Determine exactly what kind of feedback you need from the stakeholder. Reframe your request very specifically.
- Ascertain the impact that their lack of response is having on the project. What can’t happen until they provide feedback? When do you need this feedback by to keep the project moving as planned?
- Initiate a one-on-one conversation with the stakeholder. Yes, it’s important at this point that you have a conversation and not just send an email. Mention your previous request and ask if there is something specific that’s been holding them back from getting started. Clarify your request and how it fits into the project lifecycle. Gain a commitment from the stakeholder to provide the feedback you need by a specific day.
- If your stakeholder is not sure how to provide the feedback you require, schedule a meeting to do a requirements review. Often a conversation is much more productive than an offline review. Or, it may be that you need to engage additional stakeholders in your requirements process to finalize the specifications.
- Learn from the experience so you can improve next time!
>>Get the Feedback You Need
Here are a few articles from the archive that look at how to get the feedback you need to be successful as a business analyst.
- How to Get Sign-Off Without a Requirements Walk-Through
- 7 Questions that Will Get Even More Information Out of Your Stakeholders
- 8 Ways to Be Less Irritating and Minimize Follow-Up Questions After Requirements Meetings
>>Looking for More Support?
Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.
Click here to learn more about the Effective Conversations Template Collection
Great article Laura, as you have always done!
My preference is always to:
First start with a summary – a bullet points list in an email after the first one or two rounds of requirements discussion to give the confidence to stakeholders that I am on the right track and if I am not, it gets highlighted upfront and ASAP.
Then to circulate the same summary to the technical team to ensure the feasibility of a functional solution so we know upfront of architectural limitations that may or may not exist and so the requirements can also be prioritised properly (considering technical feasibility and complexity).
Then when I am ready with the full requirements document, I usually fix at least a 2 hour session with all the stakeholders, use a datashow and walk through the requirements document. At this session, I ensure that I am not focussed on wording corections but the actual requirements.
Implement the changes that may come out of the walkthrough and then circulate the document for review and approval. By this time, the stake holders will be by far familar with the vast majority (if not full) of the contents and will feel like reading it since it shoudl nto take too long.
Also, a functional detailed requirement has 2 sets of audiences – the business stakeholders and the technical team implementing the solution. If we ensure that the document first caters to the business stakeholders (after ensuring technical feasibility), other extra notes that may be required specifically for the technical team may be added when circulating to the technical team.
Well, my 2cents worth …..and again, it all depends on the organisation culture, the nature and priority of the project. If it is a large project, splitting the document to address specific parts will also reduce the size and ensure that everyone reads it. With agile methodologies, describing as you go will ensure that parts of the requirements are approved as we move forward.
I have always found that providing a clear DUE DATE of when the approval or requested changes are needed is an extremely effective way to get timely feedback. People work off of deadlines and due dates and plan their days accordingly. SO if they see a due date on their calendar they are more likely to focus on that task in a more timely fashion or dedicate the time to it that day if not before.
Laura – This article is a blessing in disguise for BA’s like me! How many times do we face this situation. Thanks.
So I’ve had a situation recently where:
– The project was important, and recognised as such by the stakeholder.
– The stakeholder had received a full walkthrough of the spec, and was fully happy with the content.
– The stakeholder knew exactly what was required – formal sign-off of the spec to allow us to proceed.
Even so, getting the sign-off was like getting blood from a stone, purely because the stakeholder was overloaded and didn’t have time to do that “last check through” before signing off.
My technique was to threaten ever-more serious effects of their lack of sign-off – project delays, project slipping to the following year, project being abandoned entirely, a plague of locusts o’er the land etc. None of this worked of course, and the stakeholder signed off in their own good time, as soon as they had completed all their other must-do tasks.
And it was OK in the end because we were secretly building the system behind the scenes anyway 🙂
Process, process…
OK, Tony, I have to ask. Was sign-off really important if you could proceed anyway?
We were proceeding at risk, much to the nervousness of the project manager, but he was pursuaded by me because I felt that the stakeholder relationship was good and the risk was therefore low.
As others have said, getting feedback on requirements off-line is, in my experience, really not the best way to proceed – much better to have a face-to-face and use the off-line review/sign-off as a double-check.
It is really important to set expectations up front, as you mentioned Laura. This could have a huge impact on the project schedule also if you are waiting on the requirements signoff to mobilize resources into the next phase. Hopefully this individual will plan better in the future and make sure there is some sort of authority involved to ensure signoff by the promised date.
Great article Laura. I believe that this problem creeps up more often than most analysts let on.
I’ve adopted an approach that is fairly similar to some of those mentioned above.
If I’m looking for feedback on ‘basic’ documentation, then I set up a follow up session with the stakeholder at the time of requesting feedback. This is normally partnered with a short message stating that, if the stakeholder is happy with the contents of the document, then the session will not be required (i.e. it’s optional).
I find that this often prompts the stakeholder to either a) provide feedback on the day that the follow-up session has been scheduled for, or more commonly b) provide constructive feedback in the follow-up session, off the back of which they are willing to sign off the document once changes have been made (if required).
If the document is slightly more complex, I don’t make the follow-up session optional, but rather create a ‘summary type’ document, outlining the salient points in the deliverable. These are then discussed during the follow up session and tied back to the final deliverable mentioned above.
I’ve found that these approaches work wonders and ensure that the stakeholder is clear on what they are signing off.
Once again, thank you for another inspiring post.
Nik, Like the idea of using a meeting as a driver. And, you are giving your stakeholders a “cookie” if they provide feedback ahead of time. Nice!
Interesting one Laura. I ran into some of these issues very recently. I love Joan’s approach of running a live review. I look at these as workshops with the team.
In your #3, the project is not a priority: It may actually not be a priority for anyone, even you! Change happens fast… so after 3 weeks, who knows if this project is even at the top of the overall company list. So understanding, and asking, “where does this project fit in your priorities” is important to assess earlier with a stakeholder analysis as well as confirm throughout the process.
Setting expectations is obviously important. I like to remind myself to ask them what I can expect. Turning the discussion from me telling them vs. them telling me what is possible. If they tell me they can dedicate a certain amount of time to a project-that is their commitment-not my “rule”. If they can’t dedicate time, that goes back to the question of if this is a priority project or not. If there is a disconnect, we need to setup a meeting with the stakeholders, sponsor, owner, etc… and discuss the reality of the situation.
Making sure they understand how and can actually digest what you are sharing with them is often the hardest part. It may be that because they can’t visualize what you sent, they do not want to sign off and lock themselves into a commitment. If you are working in long release cycles, this problem is very hard to overcome – since if it is wrong, they may not see you again for years in some cases. Having more frequent releases and embracing change is often the best way to assure customers it is okay to make a decision. The risk of being wrong or off by a bit is reduced!
Jake – Agreed. If it’s not a priority for the organization, it shouldn’t be a priority for you either!
And, even if you are working in long release cycles, you can still break things up so they are more consumable. But yes, sign-off is harder because there is so much at stake!
I find that people are lethargic / less motivated to read through lenghty specs. So I find it very useful to also have a prelim call to discuss the document organisations, allow the participants to pick out some key topics to discuss in the session and agree how they will close the remaining items in the document – so walk out with some agreements / comments on stuff they have prioritised and a plan for them to review the rest. This I feel creates engagement and also more accountability as you have spent that time in handholding with them.
I like the Virtual WINS method.
Great question and your advice really gets to the heart of the matter Laura. I wanted to share two approaches that helped me to get through my own document review challenges in the past.
The first is taking the key components out of the document format and moving it into a presentation. The Design Team who had been unwilling to read the material, but in live meetings they were engaged. I walked them through each key concept interactively, eliciting and evaluating solution ideas as we went. In the end I learned that they were willing to commit the necessary time to collaboration, but the solo effort of independent review was asking too much.
The second approach that worked well was with a group of distributed stakeholders that needed to sign off or refine a critical scope document. The complex concepts needed to be clearly understandable in print, and I was afraid that they might skim the material rather than really giving it a good read. For this review I moved the content into the decision support tool, Virtual WINS. The clipboard feature enabled me to copy my document into the tool, creating a line-by-line “accept/reject” check off. As participants moved through each item they also had the ability to add sub-comments below any item they thought needed further clarification. Each stakeholder was able to visit the tool on-line on his/her own schedule, and with some gentle nudging completed the task within the designated timeframe. When done we used the tool’s publish feature to share the results – what was settled and where there was more work needed.
Joan, These are some great practices! I’ve gone the presentation route, often using UI mock-ups. I’ve never heard of Virtual WINS but it sounds like a great alternative for must-read text-based requirements.
To follow up for those interested in the Virtual WINS approach, I’d be pleased to host a demonstration of how this tool can be used to facilitate requirements sign-off. Just drop me a note and suggest a schedule at http://www.thevirtualba.com/home/about-us/contact-us
Laura,
You touched the very basic element of a BA to the core. Infact a perfect article to all the seasoned and emerging BA’s.