The purpose in asking the right questions
The more practice you get with asking questions, the more skilful you are at delivering those questions without sounding like a robot. It takes practice.
By now you might have read my eBook on how to start a business analysis project.
The purpose of the book is to give you a structured approach to getting yourself into the right headspace with a new business analysis effort.
Of course, no project is predictable. Especially when there are people involved! And sometimes you will find yourself spinning your wheels in spite of your best-laid plans.
But this book will give some practical steps to work with. And help you understand that the best approach to starting a new BA project is to be organised and proactive. The way I do this is by planning my questions and the opportunities to ask those questions.
It’s a core skill for a business analyst to know what questions to ask. Here’s 3 reasons why asking questions is important.
1. You learn by asking questions
It is the simplest and most effective way of learning. Children are masters at asking questions. If you keep asking questions you find deeper answers. This means that you come up with more accurate ways to solve a problem. And you innovate better. The right kinds of questions drive creativity. Questions generate more questions and help us bring to light truly innovative thought. And they drive us to answers we never thought to consider until we asked the question.
2. You eliminate assumptions
The more you ask, the more you understand the real reasons behind a problem or a recognised need, and the more you eliminate the wrong possibilities. It’s important to find the courage to ask questions and communicate with others as clearly as you can to avoid misunderstandings. Making assumptions about a statement a person has made can be problematic and may lead to misinterpretation of business requirements. Instead of assuming, ask questions to solve a problem and state what you need to progress your project. Asking questions will bring clarity and help you get to the root cause of an issue.
3. It keeps the information flowing and the people that matter talking
If your key stakeholders are doing all of the talking, you’re a winner! This is because you’re gathering the information from the source. And with a good questioning technique you can keep your stakeholders delivering the information you need in a way that is helpful for your analysis.
So like I said, it’s a core skill for a business analyst to know what questions to ask. And the more practice you get, the more skilful you are at delivering those questions without sounding like a robot. It takes practice. So keep asking!
The best kinds of elicitation questions to ask
Well-planned questions will assist your stakeholders in delivering the information in a way that is helpful for your analysis.
During elicitation activities, well-planned questions will assist your stakeholders in delivering the information in a way that is helpful for your analysis.
Not only can you elicit everything you need, you can do it in a way that is easy for your stakeholders to provide. This is because they are talking about what’s important to them. Their business.
It’s all about them and not about, for instance, the technical ins and outs of implementing a system and other stuff they don’t understand and don’t need to know about.
Before proceeding with more detailed questions, these are the types things you need to structure your initial questioning around.
- Who they are (roles and responsibilities)
- What they do (their business or service)
- How they do it (processes and procedures)
- When they do it (events and schedules)
- Where they do it (location)
- Why they do it (their policies, constraints, values, goals and drivers)
You also need to know about the challenges or issues your stakeholders have. Issues may become apparent when you ask the above “who, what, how, when, where and why” questions. However, it’s good practice to ask directly about your stakeholders’ challenges, e.g., “What are your current pain points with the annual leave application process?” And “Why?”
“Why?” is the most common question I ask and it is no doubt the most important. I ask why to almost everything. I’m not talking about the “judgy” and confrontational why, e.g., “Why do you do that?!” But the inquisitive, explorative and results-driven why, e.g., “Why does it take 5 days to get a leave application approved by the manager?”
So ask the good “why” questions and just keep asking until you’re satisfied you’ve reached the root cause of the issue or a complete understanding of the situation or business requirement. You’ll find that the better the quality of your questions, the more aligned your results will be to your stakeholders’ needs.
Finally, by asking questions you become more a part of your stakeholders’ world. And you’ll be able to understand, reflect and converse with them in their lingo. Then you’ll really know their business and be well on your way to winning their hearts and minds.
And you’ll deliver great results!
How to get better results from your elicitation efforts
Out of the correct approach to elicitation you will collect data that provides you with an understanding of your stakeholders’ business.
Asking questions that focus on your stakeholders business could deliver you better results. This is because it will accurately inform you about how their problems might be solved through process or technology changes.
I can best explain this using an example. Say you’re gathering requirements to implement a new analytics and reporting platform. Consider the following two scenarios.
Business Analyst: Do you want Business Objects or Cognos BI? What do you think of Oracle Reports?
Stakeholder: Huh? I just want a system that gives me my report.
Business Analyst: OK. What do you want on your report? Do you actually want a report or do you prefer a dashboard?
Stakeholder: I don’t know. Show me what it looks like.
Business Analyst: What is your role in the organisation?
Stakeholder: Manager of mining operations. I oversee all mining operations for the Acme Mine. This includes safety, environment and regulatory reporting.
Business Analyst: Where do you work most of the time?
Stakeholder: I divide my time between the head office and the mine. Some overseas travel is required.
Business Analyst: What types of decisions do you make on a daily basis?
Stakeholder: [The mine manager explains a wide range of decisions]
Business Analyst: What type of information do you need to make each of these decisions?
Stakeholder: [The mine manager explains the types of information needed to support his or her decisions]
Business Analyst: How do you get that information?
Stakeholder: From data kept in Acme’s process control system, environmental reporting system, other management systems, various spreadsheets, reports, emails and hand written logs. The data is collated and sent to me in reports containing production statistics, scorecards, graphs and written analysis.
Business Analyst: Why do you need this information?
Stakeholder: So I can ensure the profitable, safe and sustainable operation of the mine. To make sure that this is done in line with government regulations and the mining company’s strategic plan.
Business Analyst: What is your main pain point with the current process?
Stakeholder: It takes 2 days to produce a report when I need the information almost immediately.
Business Analyst: Why does it take two days to receive your reports?
And so on…
The first scenario is an exaggerated demonstration of how not to conduct your questioning process. This is because it focuses on a solution without trying to understand the real need of the business. The solution matters later when assessing various technology options against your stakeholders’ requirements. But first, you need those requirements.
The second scenario demonstrates the correct approach to eliciting requirements by focusing your attention on the stakeholders’ business. From the above scenario you may be able to derive that “as a mine manager, he or she needs to access (from anywhere) scorecards that allows him or her to make instant decisions about the operation of the mine in real time.” This requirement would be expanded to support each decision and information requirement of the mine manager.
Further, from this questioning technique much can be gained from the type of reporting system that needs to be implemented. Here are 2 basic examples of system requirements that could be further validated and prioritised by your stakeholders:
“The system must provide real-time operational scorecards.”
“System reports and scorecards must be accessible via mobile devices.”
This is an example of how you can produce good results in eliciting requirements.
A requirements discovery checklist… over 700 questions
Get the guidance you need to make the most out of your elicitation efforts and produce clear and complete requirements.
I’ve focused on the importance of asking questions for a very good reason. Effective stakeholder engagement and elicitation is the business analyst’s bread and butter. It’s so important that Laura Brandenburg (CBAP) came up with over 700 questions in her Requirements Discovery Checklist Pack.
In fact, if you were to ask me what I think are the most important skills of a business analyst, my answer would include:
“The ability to apply the correct approach to elicitation in any given situation.”
This includes planning your communication activities and your questions in formal settings such as workshops and interviews.
To do this, it’s important to understand the “scope” of your audience so you know what level to pitch your questions. For instance, in a meeting with senior managers and key decision makers, asking detailed questions about how a certain procedure is performed is not good use of time. It’s a wasted opportunity to understand the important drivers and risks that provide context and direction for your work. And your audience will likely lose interest very quickly.
The reverse applies to stakeholders that spend their working day carrying out operational tasks. The line of questioning would involve the “what, how, when, who, where and why” of the tasks, activities, processes and procedures that they perform. I would not, for instance, ask them questions about the organisation’s broader strategic initiatives. It is also not good use of your stakeholders’ time.
Regardless of methodology, elicitation is just a conversation. The more you relate to the mind set and main preoccupation of your stakeholders, the more successful that conversation is. And as a result, you’ll write requirements that translate into a solution that’s solidly aligned to their needs.
Then you’re a winner!
So if you want to get outstanding results from your stakeholder engagement activities, I strongly urge you to check out the Requirements Discovery Checklist Pack. This is a resource of 700 questions categorised and cross-referenced into 18 checklists that covers core business process areas and software features.
It’s not just a list of questions. It gives you the guidance you need to get the most out of your elicitation efforts so you can produce clear and complete requirements.