Offering Less Gets You More When Interviewing


Sometimes, we simply say too much. We start with a perfectly fine, grammatically correct sentence that stands on its own - and then we decide to add more. Much like a man who tells his date, “You are attractive… for your age,” sometimes as Business Analysts we keep talking longer than we should.

The scenario is simple: You’ve been tasked to determine the requirements for a new project. You’ve done your homework by reviewing existing documentation. And, now, you’ve arranged to have a meeting with a Subject Matter Expert (SME).

So, where does one begin on this path to enlightenment? When you talk to the SME for the first time, do you start by outlining everything that you think you’ve learned already?

It is tempting to say too much in an attempt to sound knowledgeable when collaborating with a SME. We might be afraid that if we ask a question that is too vague or open-ended, that it might seem that we don't know anything about the subject at hand, or that we are unprepared. Unfortunately, many times in our effort to sound intelligent, we offer too much of what we suspect to be the answer.

According to the Merriam-Webster Dictionary, elicitation is, "to call forth or draw out (as information or a response)." So, how is the act of elicitation different than confirming your understanding of something or asking questions and receiving answers? Sometimes it is not. But, most of the time, in order to get the answers required to make a project successful, you need to be a bit more subtle.

Elicitation is a process of discovery. Asking detailed and pointed questions can actually work to your detriment in your quest for full understanding. Adding too much into the question can actually be limiting the avenues for discovery.

For example, you might ask a small child, “Do you want the red one or the orange one?” This is a great question for a toddler, giving tangible, limited options. Giving options to stakeholders does the same thing as it does to the child; it limits the possibilities of the responses. Only with stakeholders, sometimes you are limiting them unintentionally.

Consequently, when eliciting requirements, it is advisable to keep the sentences and questions as simple and as vague as possible in order to draw out some of the most important information.

"Objection! Leading the Witness!"

In a court of law, both legal teams and witnesses may assume to know the full story of what actually happened, but what is presented to the jury must be from the testimony of the witness, not indirectly through a lawyer. Suggestive Interrogation, as it is sometimes called, can be objectionable in a court of law. In much the same way, even when a Business Analyst thinks he or she understands some aspect of the system under investigation, the first question asked on a topic should be asked non-prejudicially and should not include suggestive interrogation when opening the discussion. In other words, “play dumb.”

It extremely important to avoid 'planting information' in the way we word our questions when eliciting requirements in order to solicit the most information possible. For instance, "When is the peak time with regards to system load?" is an opened-ended question. But, what if you add the clarifier, "Do you have a particular hour of the day that is busier than the others?" Would this change the direction of the conversation if added as part of the initial question?

In either case, the client may have intended to answer, "Mondays from 11AM to 4PM is when we experience our highest volume." But, before adding this secondary 'clarifying' question, the client could have legitimately answered, "Our peak time is May through September, with secondary peak around the holidays."

This alternate answer gives insight as to how the customer views the business. It also lets you know that getting the stats for the past month’s Mondays from 11AM to 4PM may not show the true peak load of the system if it is February.

Because a cooperative customer will answer what they are asked, it is vitally important to keep that first question as open ended as possible, to determine what is valued to the customer. Of course, you can always get more detailed questions answered during further examination, to use in subsequent analysis:

  • Does any one use the system on weekends?
  • What is your busiest hour during the week?
  • What is your slowest hour during the business hours?
  • Do you have any automated processes that run during off-hours?

But, that opening question needs to be as broadly open as possible, in order to know how best to follow up.

The Noble Quest

Asking open ended-questions from the onset also gives a better flow and a friendlier, collaborative experience than having a list of detailed questions. Elicitation done well feels more like a natural conversation rather than an inquisition or interrogation.

So, where should you begin? When initiating any kind of business analysis requirements elicitation there should be a few key items that you are always trying to determine:

  1. How are things done today?
  2. Are there any specific reasons / deficiencies that are driving a change? 
  3. What is it that you want to accomplish?

This doesn’t mean that you necessary ask these questions directly, but certainly, the first two are good open-ended candidates when beginning the process.

The first of these, the Current State, can generally be determined through interviewing, observations, review of documentation, etc. And, unlike the last two questions, there is one single, objective answer to this question. “It is what it is.”

The last two are more intertwined, but may or may not be the same. For instance, if a BA has been engaged to analyze the process and suggest efficiency improvements simply to save money, then the drivers and goal may be the same – to save money. But, in another scenario, you may find that regulatory changes may be the catalyst driving the change, but there may be a broader end goal, such as having a more flexible system to allow faster adoption of new regulations in the future.

And, while most of the time The Business has a stated goal, the Business Analyst may encounter a situation where each stakeholder may have a slightly different goal, or may even have goals that are in direct opposition to the stated goal. Using open-ended, simple questions during a collaborative, casual conversation allows the Subject Matter Expert to let his or her views be known more readily than asking pointed, direct questions, which can result in defensive answers.


Getting stakeholders to divulge the true requirements is a bit of an art. By practicing restraint during elicitation, you will be giving each stakeholder the opportunity to speak more freely. And, this will in turn, allow you to more quickly identify which direction to take the conversation.

By the end of an interview your goal is to understand how things are done today, why that won’t work for the future, as well as what the end-goal is from that particular stakeholder’s viewpoint. If these high-level items can be understood in detail for each group of stakeholders, the requirements tend to readily manifest themselves.

Author: Michelle R. Walter, CBAP®

Michelle R. Walter is a Certified Business Analysis Professional™ (CBAP®). She is a past board member of the Rochester, New York Chapter of International Institute of Business Analysis (IIBA), having served in the positions of VP Communications, Acting VP Programs, Executive Vice President and President. Ms. Walter is currently employed by Oracle Corporation as a Senior Technical Migration Manager.

Like this article:
  21 members liked this article


Duane Banks posted on Friday, November 13, 2015 8:36 AM
Good stuff, Michelle. I'm always on the lookout for how to ask right questions. Keeping that first question as open ended as possible is a wonderful elicitation technique (and a lesson learned today).
Adriana Beal posted on Friday, November 13, 2015 7:56 PM
I'm glad Dtbanks forwarded me the link to your article, Michelle! I've recently published an ebook called TESTED STAKEHOLDER INTERVIEWING METHODS in which I recommend exactly the same type of question you suggest here: how are things done today, what will you be able to do then that you can't do now, what are the key outcomes you expect this project to deliver, and so forth. I've coached many BAs over the years and gave them the same advice, always with very positive results, so I couldn't agree more.

One interesting aspect you mention in your article that I didn't address in my ebook, and was the reason for Dtbanks sharing the link with me, is the urge to "say too much in an attempt to sound knowledgeable". You are giving BAs a good reminder not to let their ego get in the way of eliciting critical information for their projects.

I just realized that it never crossed my mind before to give this kind of advice because both myself and my mentees are humble enough to realize that most of what we think we know about a business or system domain is based on hypotheses that need to be validated :-). But I can see it becoming a problem for analysts who fear they'll sound ignorant if they don't insert the research they've already done into the questions they're asking.

A suggestion I'd give to BAs reading this who identified with the "lead the witness" problem is to remember that your goal in an interview is to get your interviewee (the expert) to share as much information as possible. Start with an opening bit in which you explain how vital it is that she does most of the talking, ask the first "tell me about how you..." question, and just wait. If your interviewee offers a short answer, don't try to say something to break the silence -- stay quiet and wait, to show you really mean what you said; you are mostly going to listen. Now your interviewee knows that it's OK to give long, detailed descriptions, and you're much more likely to get all the information you need to make your project successful.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC