Business Analysis For Dummies
Book image
Explore Book Buy On Amazon

Forget everything your creative-writing teacher taught you in middle school; being predictable and repetitive when you’re eliciting information is good in business analysis!

When eliciting, use the clearest communication you can. Make your sentences concise and complete. Avoid long sentences that keep going on and on and on and don’t end and have multiple clauses that keep linking together and leading to a difficult way of interpreting the sentence (sort of like this sentence).

How to choose terms consistently in your business analysis

Stay away from using unnecessarily creative words and mixing up terms just for the sake of keeping your readers engaged. Pick a term and stick with it for maximum clarity in your communication.

For example, don’t mix terms such as customer, account, and client interchangeably to describe the same type of person. Instead, you may choose to use only customer; if you need to differentiate among different segments of the customer pool, you can describe them with different statuses such as current, potential, preferred, and so on.

To you, choosing one term among many that are similar may seem like mere (and innocent) semantics, but your job is to understand the company’s culture and respect what its words and definitions mean. Inconsistently using terminology can confuse your audience and lead to things like incorrect security access to the solution (that is, you may end up giving the wrong people access to features they weren’t supposed to access).

How to use language that’s consistent with the company’s language in your business analysis

Each company you work with has its own terminology. For instance, Disney calls all its customers “guests” and its employees “cast members,” and it uses this terminology in every communication and interaction. Adopting the company’s language is important; doing so not only lets you avoid confusion but also reiterates that you’re aware of and understand what makes this company unique, a key trait in someone targeted to devise solutions.

Here are some suggestions for making sure your language is consistent with a company’s:

  • When encountering new terms, ask for the definition. Understand what the company means when it uses a word like customer, client, or guest.

  • Each time you find a term you don’t understand, ask for clarification.

  • If you find a term very close to one already defined, ask your stakeholders if the new term is the same as the previously defined term. If so, ask them to select one to use as the preferred term.

  • Create a glossary for yourself and for the project team. Record all terms and company lingo so you can refer to them throughout the project.

Unless you’ve been working with a company for a long time, avoid making assumptions about terms (or anything in general, for that matter). Make sure you clearly define all language before using it. The clearer you are and the more you let stakeholders explain, the less chance you have for miscommunication. Don’t be afraid to ask a question that might seem to have an obvious answer. If unsure, just ask.

How to frame questions that clearly reveal core needs in your business analysis

Even if you already understand the people you need to interact with, their level within the company, and the elicitation techniques you plan to use to draw out the information, you’re still not quite ready to jump in.

To get the real truth out of your stakeholders, you have to properly frame the questions, or ask your questions in such a way as to drill down to the real business or stakeholder need rather than just the suggested solution. Frame your questions correctly, and you may even find a completely different problem than the one the stakeholders suggested.

So how do you frame a question properly? So glad you asked.

  • Ask open-ended questions. Open-ended questions are questions that stakeholders can’t answer with a simple yes or no. For example, ask “What are the problems you experience?” rather than “Do you experience slow response times?”

  • Figure out what the stakeholder is asking for. A great place to start is with asking “Why does this stakeholder need this solution?” or “What is driving this request?” Your goal here is to uncover the real problem rather than just put in a solution, because putting in the solution doesn’t get to the root cause.

    If you fix the wrong problem, the business may end up blaming you, the business analyst, for not fixing the problem even though you did exactly what the business asked you to do.

    For example, asking “Why are you looking to open the address field on screen 1.6?” helps you understand why the stakeholders are approaching a solution to a problem so you can understand the real problem. In this case, the original requirement presented to you — “Open the address field on screen 1.6.” — was really a solution to an underlying problem.

  • Think about answers that may elicit a follow-up response. Elicitation is not all about asking questions. It is about listening, too. Be careful not to jump ahead to other questions on the assumption that you know where the answer will take you. Listen to the answer to a question and ask clarifying questions to make sure you understand the answer fully.

  • Make your questions relevant to the business. Although you don’t have to be a domain expert to be an excellent business analysis professional, you do need to do your homework. Make sure your questions apply to the project and business area you are working with. “What business problem is the business attempting to solve?” “What would an ideal solution look like?”

About This Article

This article is from the book:

About the book authors:

Paul Mulvey, CBAP, Director, Client Solutions, B2T Training, has been involved in business analysis since 1995. Kate McGoey, Director, Client Solutions, B2T Training, has more than 20 years' experience in application development and life cycle processes business. Kupe Kupersmith, CBAP, President of B2T Training, possesses more than 14 years of experience in software systems development. He serves as a mentor for business analysis professionals.

This article can be found in the category: