Year after year, the two most frequent questions I get from business analysts who turn to me for advice when things are not going well at work are:
- How do I get my stakeholders to come to my meetings?
- How do I get my decision-makers to read my documents?
The first step to solve a problem is to frame it correctly. These aren’t the right questions to ask. The real question these BAs should be asking is, “how do I get my stakeholders to stay involved throughout the requirements process, so I can have their input at the right times during requirements discovery, analysis, and validation?”.
The reason you know this is the right question is because it focus on the desired outcome. What if your stakeholders never showed up to any of your meetings, and you still got everything you needed from them to create high-quality requirements for your projects? And what if you got sign-off for your requirements without your decision-makers ever reading a single page of your specification, with the team still being able to move forward and deliver a solution that the stakeholders told you they were 100% satisfied with? Would you still care whether they came to meetings or read anything you wrote? Of course not.
So, the first step here is to recognize that what you're really after is your stakeholders' attention and follow-through. Most business stakeholders who have to provide input for software projects are extremely busy, and talking to you or reading your documents is obviously not at the top of their priority list. Don't make the same mistake companies make in sales and marketing, positioning themselves as the hero of the story. Good marketers know that if you want customers to buy, you must tell a story where the customer is the hero--not you.
Geoffrey James explains:
What is a hero? In stories, the hero (or heroine) is the star, the person who takes action to overcome obstacles in order to win the prize. Along the way, the hero typically meets enemies and helpers, but the story is about the hero, not about the other characters.
If you are trying to get your stakeholders to give you answers or agree with a solution, you can't make your requirements workshop or software requirements specification the star of the show. Instead, tell a story in which your stakeholder is the main character, and your project plays a supporting role.
Here are some examples:
Wrong: Generic message sent to all stakeholders.
"We are kicking off the project for the new scheduling system. Please come to this requirements workshop."
Right: Customized message delivered in person, whenever possible, or via email if the recipient is remote.
To the VP of Sales: "We are about to get started on the new internal collaboration system, which will help your salespeople spend less time getting information from the product team, and more time in revenue-generating activities. I'm putting together a requirements workshop with people from different backgrounds so the solution can benefit from multiple perspectives. Having you or a subject matter expert from your team participate will ensure we don't forget any capability that would be critical to reduce the time it takes for your salespeople to receive the information they need from the product team and other departments to win their next deal."
To the Director of Customer Success: "We are about to get started on the new internal collaboration system, which will help the support team spend less time getting information from the product or development folks, and more time helping customers who are experiencing problems. I'm putting together a requirements workshop with people from different backgrounds so the solution can benefit from multiple perspectives. Having you or a subject matter expert from your team participate will ensure we don't forget any capability that would be critical to reduce the time it takes for each customer support agent to close tickets faster."
See the difference? Instead of focusing on your need for them to come to your workshop, you're making the whole thing about them getting better results that matter to them. Clearly closing more deals is important for the VP of Sales, and closing tickets faster is important for the Director of Customer Success. Because you demonstrated "what's in it for them", you're much more likely to get their attention and support.
The exact same approach can be used to get people to sign off on your specifications. By putting yourself in the shoes of your stakeholders, you'll first realize that's not realistic to ask them to read pages and pages of a document. Divide the content into smaller chunks, so that the business stakeholders can ignore sections like "User Roles & Permissions" (which perhaps only the head of IT Security will care about) and focus on aspects that matter to each decision-maker. Be creative on how you'll get the attention of busy people to review your final requirements and again, customize your message for each stakeholder.
For example, for the VP of Sales who is always traveling, you could create a short video walking her through the solution's main features using a clickable prototype that could even be made in PowerPoint, describing the capabilities that are in and out of scope that she'd care about:
"Here you can see how the members of the sales team will have access to a list of product managers by industry, customer type, and product component, making it easier to send a request for information to the right person, as opposed to sending a message to the whole team, which only causes delays because every PM is getting all questions. However, as discussed in our workshop, in this first release the reply will only go to the salesperson who asked the question, so in order for the whole team to be informed, the recipient will have to click this "Share" button. In future releases we'll be adding the option for the reply to be automatically shared."
And for the Director of Customer Success, who is always in the office and heavily relies on a couple of senior subordinates to confirm the team's needs, you could schedule a meeting to go over the final requirements in person and highlight gaps in functionality that the senior subordinates may have concerns about.
In order to make your stakeholder the hero, you have to spend time figuring out what's important for each group you need buy in from, and tailor your message accordingly. It's definitely more work than using a "one size fits all" approach to asking for input, but also a much more effective method for validating requirements and avoiding bad surprises after the software is released. Follow this approach and I guarantee that you'll find it much easier to convince people to come to your requirements sessions and provide sign-off for your final specifications. You’ll avoid unnecessary project delays caused by unresponsive stakeholders, and more importantly, deliver software that's fit for purpose and produces business value.
Author: Adriana Beal has developed a successful career in business analysis and product management, having lead the investigation of business problems, defined winning solutions, and written requirements documents for a large number complex software projects. She is also the coach of
Crafting Better Requirements, a program that has helped hundreds of business analysts improve their requirements documentation and communication skills, and the author of the ebook
Measuring the Performance of Business Analysts, which has been adopted by dozens of BA managers interested in improving the performance measurement systems in their organizations. Her next ebook, designed to help BAs struggling with getting the right information to analyze and use to specify their solutions, will be called
Tested Stakeholder Interviewing Methods for Business Analysts.