Do this one thing, and you’ll become a much better stakeholder interviewer

Author: Adriana Beal

I have an ambitious goal for my new e-book, Tested Stakeholder Interviewing Methods for Business Analysts: change forever how business analysts conduct interviews and requirements workshops, and drastically improve the results BAs get from these interactions with their stakeholders.

But I also realize that many members of the Bridging the Gap community may be at a point in their careers where they have performance improvement goals that focus on aspects other than becoming an excellent stakeholder interviewer. Still, being able to ask the right questions to the right people remains a critical competency for any business analyst. The right question asked at the right time can surface an important scenario the project team was unaware of, or a potential issue that if left unchecked would create a project roadblock. A well-formulated question in many cases can represent the difference between project success and failure.

For that reason, I wanted to share with you a simple trick that can drastically improve the type of results you get when you’re trying to elicit information from stakeholders for a software project:

Separate what you need to learn from the questions you ask.

Here’s how it works. Imagine you’re documenting the process for employees of a company to submit requests for IT purchases (printers, laptops, monitors, etc.). Let’s say you’re trying to figure out what needs to happen before an employee is notified that one of their requests has been denied. In many books teaching people how to document a business process, you’ll find advice to ask something like, “what should already have been produced before an employee is notified that his request has been denied?”. That’s a perfectly valid way of stating your question for the purpose of understanding what you need to learn. But it’s a poor way to phrase the question for your stakeholders, who most likely aren’t trained to think in terms of process models that transform inputs into outputs.

Here’s how to reword the question to make it easier for your stakeholders to answer it accurately:

“We talked about how an employee request for new equipment can be denied for various reasons: the company is changing providers and want employees to only use a different brand, the department the employee belongs to has exhausted their budget for the quarter, etc. Can you tell me when, exactly, would the employee be notified that their request was denied?”

Notice how, by avoiding process modeling jargon and providing more context around your question, you make it easier for the stakeholder to connect the dots from what you’re asking to what they know happens in real life. Instead of having to think in terms of what is the output produced prior to the output “employee notification”, he can think in terms of a real situation in which a request got denied in each of the given examples, and recall what happened before the employee was notified.

The interviewee could then answer with something like, “Sure, in the first scenario, the employee would be automatically notified as soon as the product had been removed from the catalog, and the ‘request denied’ notification would include instructions on how to resubmit the request after choosing a different brand or model of equipment that’s still in the catalog. In your second scenario, before we notify the employee, we forward the request to the manager in charge of the exhausted budget first. It’s possible that the manager is able to ask for additional budget, in which case the request may still go through, so we only notify the employee after the manager has confirmed that there will be no budget to fulfill the request.”

Here are a couple of other examples of questions that authors suggest you ask stakeholders or “explore through facilitated session”, and are framed from the perspective of what makes sense for a business analyst, but rarely for your stakeholders:

  • Should performance of the business task “Notify Claimant” begin within a certain maximum amount of time after completion of the prior business task “Verify Basic Claim Information”?  (from the book, Building Business Solutions).
  • Which of the fact types used in current systems should be in the future Decision Model? (from the book, The Decision Model: A Business Logic Framework Linking Business and Technology).

Again, while these kinds of questions can be very valid from the perspective of an analyst listing all the information that must be elicited to document a business process or finalize a decision model for their project, they are definitely not good questions to ask most business stakeholders, who wouldn’t be familiar with or interested in learning business modeling jargon.

When you need to ask a question to clarify a business process or system requirement, remember to make things easier for your subject matter expert, not for yourself. That means never asking lazy questions like, “What are all the steps an item must go through to achieve the outcome of the workflow?”. This may very well be what you need to learn, but taking the time to rewrite and decompose your questions in a way that reflects your stakeholder’s terminology and mindset will make it much easier to extract from them the business logic you need to specify a winning solution.

>>Learn More

If you’re interested in learning more about this topic 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.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.