A foolproof way of gaining your stakeholders’ attention

Author: Adriana Beal

If you are like many BAs I know, you often worry about two things:

  • How do I get my stakeholders to come to my meetings?
  • How do I get my decision-makers to read my documents?

But see, these are not the right questions to ask. What if, without ever being in a meeting with your stakeholders, or having them read a single line of your specifications, you were able to get the information you need, complete your specification, and have the project team deliver a solution that users were 100% satisfied with? Would you still care whether they came to meetings or read anything you wrote? Of course not.

Clearly, what BAs who ask those questions are after is their 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. However, getting what you need to succeed as a business analyst in charge of the requirements or a project is simple if you’re willing to do the groundwork. Just follow the same rule good marketing specialists use: 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.

How does this “make the customer the hero” rule applies to your work as a BA? When you are trying to get your stakeholders to give you answers or agree with a solution, don’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. Follow this approach and I guarantee that you’ll find it much easier to convince people to accept your invitations for interviews or requirements sessions, avoiding project delays caused by unresponsive stakeholders.

Of course, getting people to show up is only the first step.  When your end goal is to deliver software that’s fit for purpose and produces business value, you also need to make sure you are asking the right questions during the requirements discovery process. Otherwise you may end up with the all-too-common situation of a signed-off software specification that is successfully coded and tested, but triggers a large number of costly change requests from users who can’t complete their tasks because critical requirements were missed.

>>Learn More About Interviewing Stakeholders

If you have had the unpleasant and costly experience of having key requirements discovered too late in the process, or want to avoid running into this problem in your career as a BA, check out the e-book, Tested Stakeholder Interviewing Methods for Business Analysts.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.