December 24, 2024 • 16 mins
Great analysis starts with great questions. In this episode, I explore 10 essential questions that often go unasked—questions that can unlock hidden insights, align stakeholders, and save your project from disaster.
You’ll learn:
- Why asking “What’s the real problem?” can save millions.
- How to define success before you start.
- The power of questioning whether action is even necessary.
🎧 Tune in now and discover how asking the right questions can transform your business analysis game.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
The Better Business Analysis Institute presence, the Better
Business Analysis podcast with Kingsman Walsh.
Hi everybody, and welcome back to the Better Business Analysis
podcast with your host, BenjaminWalsh from the Better Business
Analysis Institute. If you haven't done your
(00:22):
training yet, 199 US and you canget certified as a BA, do it
today. Today we're covering the top ten
questions business analysts should ask, but really do you're
going to learn something today. Let's dive in now.
Some of these questions can be abit awkward, so we're going to
(00:46):
run through the questions, ten of them, and we're going to talk
about why they're significant, maybe cover a scenario, and then
how to ask it. So let's dive in #1 is the most
important. It's what's the real problem
we're solving here? Projects often address symptoms,
(01:07):
not root causes. This question helps ensure that
the work aligns with the actual business needs.
There are many times where you're working on a solution or
someone has come up with a solution, or you're working on a
kind of a generalized problem statement and it's your job to
(01:28):
ask the five wives, do a problemdefinition and try and pull back
and figure out what the root cause.
Here's a typical scenario. A stakeholder wants to implement
a new CRM system but actually hasn't identified the current
system's shortcomings. So what do we do?
This is how we do it. We might ask the question.
(01:50):
It sounds like you're improving customer relationship
management. That's the goal, right?
Can we just take a step back anddiscuss the underlying
challenges this system will solve?
That way I can make sure that myanalysis targets the right
issues and the requirements of focus on solving the problem you
(02:12):
want. Do you notice that I turned it
into a question more around myself and what I needed out of
the situation? And of course, that reduces
friction or the conflict or I don't come across threatening or
challenging. I just come across as someone
who needs help. And so that's a great way of
doing it. So remember that as we go
(02:33):
throughout the other nine questions.
The second one shouldn't be threatening.
It's #2 and it's what does success look like?
Stakeholders often have a vague or even conflicting idea of
success. So that's why it's important to
have one product owner. It's really important to clarify
(02:54):
what success looks like for them.
It prevents misalignment over investment under investment.
So let's take a scenario where your team's rolling out a new
feature. Maybe it's, you know, team
driven and you haven't agreed how to measure success.
You can be in all sorts of trouble.
So what you should do is ask upfront, once this project is
(03:16):
complete, how will we know it's been successful?
Are we focusing on any importantmetrics like revenue or user
adoption or attention or something else?
So that way, for example, if there was an expectation, and of
course you don't know this without asking, that this new
feature was going to increase customer signups or revenue,
(03:40):
then you might be in trouble if the feature was actually about
customer retention. So you got to get that up, sort
it upfront #3 it's who are the stakeholders, who are the key
stakeholders, and what are theirpriorities?
And yeah, you can have a rescue model with a matrix, but
primarily it should be like a pyramid model.
(04:01):
You should ideally have one product owner or sponsor, maybe
a couple of key stakeholders around them and it gets bigger
and bigger as you go down, but you should draw the line at the
top in terms of decision making.So this is very, very common.
There is missing or unconsulted stakeholders.
Just had that happen on one of my pieces of work with some
(04:24):
people who weren't engaged. And that can just derog
projects, right? Especially get to the end and
then UAT, suddenly you've got some new stakeholders who are
then checking to see if the solution met the requirements
and they were involved in the requirements phase.
Happens all the time. You need to understand of
priorities like misaligned and you need to align them and you
(04:46):
need to get decisions upfront. If you don't do this, some
engagements done badly, it's it's you're just fighting fires
all over the place. When you want to go live.
The scenario is that the IT teamis driving a project but end
users and sales haven't been consulted, for example, or the
person responsible for doing website content hasn't hasn't
(05:07):
been involved, or the person whochecks privacy hasn't been
involved. So how do you ask that?
When you start, you should say who else will be impacted by
this change. You should do a change impact
workshop is what a change manager would do, but you can do
it yourself and you need to bring them into the conversation
to get a bigger picture of theirneeds.
(05:29):
So if you're doing with a product owner and that product
owner consistently asked for feedback from a couple of their
team members, for example, you should bring those team members
on Top tip, top tip to you, top tip to me.
OK #4 what assumptions are we making?
Projects often fail because of unexamined kind of unrealized
(05:56):
assumptions. So like underestimating cost,
overestimating user behaviour, maybe thinking that your users
are going to adopt A new change faster than they will.
I have make an assumption about how long it's going to take to
science, a piece of work off before you go live.
So the scenarios here is that companies, organizations might
(06:21):
assume that a customer want a mobile app without actually
verifying demand. So that actually happens.
Everyone went mobile app, mobileapp and mobile apps do one
thing, but maybe they don't wantthat.
Maybe they're happy using the website experience and they're
not going to use it on the go. It's not a kind of an amplified
idea. So to ask that question, we can
(06:43):
say to the team project, projectowner, product owner, project
manager, and your architects anddevelopers as a team meeting,
ask the question, what assumptions are we making about
user behaviour or system capabilities or the ability for
the organization to absorb this change?
(07:03):
Do we need to validate any of these before we move forward?
OK, that's really important. Be bold, ask these questions.
BAS are perfect for doing this #5 this one's awkward, but I
think you should ask this question.
If we don't do this, what happens?
(07:24):
This question challenges whethera project is truly necessary,
and it helps prioritize resources.
It's very awkward if you're on the project contractor
consultant, for example, your reason for your existence, your
income is reliant on the projectcontinuing.
But it takes a brave person to answer this question.
I, I, I have done this in many times and I consistently do it.
(07:47):
So the scenario is that a stakeholder proposes maybe
automating a really used projectprocess, for example.
So they say, let's automate thisso we'll make it better.
And actually no one uses it. So how do we ask this?
We say, let's imagine if we didn't pursue this project, what
would the impact be? Could those resources be better
(08:09):
used on the other piece of work that needs to be done?
So I think the the critical thing here is to say, let's
imagine we didn't pursue this project.
So it's non threatening and allows people to think about
what the alternatives are #6 is what are the risks and how do we
(08:30):
handle risk management done really badly.
Usually risks are identified midproject, not beforehand, not at
the startup, what you should do.And then you just have all these
issues because risks turn into issues when they realize or not
mitigated. So risks are inevitable, they're
going to happen. But identifying them early
allows for mitigation strategies.
(08:52):
So, for example, if a project has tight deadlines, you go to
risk quality output. You got to kill your staff to
try and get done on time and something's going to slip.
Quality of life or quality of product.
So you ask this by saying what risks could impact this
project's timelines, outcome, team morale, culture, user
(09:17):
experience? How should we plan to address
them if they arise? What's our risk mitigation
process? Do we have a risk meeting?
Do we do it in stand up? Do we have a specific risk
workshop upfront? I I would suggest you do.
How are we going to monitor them?
How are we going to escalate them and how are we going to
mitigate them? And who's responsible for doing
that #7 so important. Definitely an area I plan, and
(09:41):
it's asking the question, how does this align with
organizational goals? You need to ensure that the
project you're working on contributes to broader business
outcomes rather than operating in isolation.
Maybe your marketing department wants to develop a new bespoke
tool, but the organization is standardizing software somewhere
(10:04):
else. It happens all the time.
You know, the marketing department's brought in
Salesforce, but you're a Microsoft shop and you've just,
you know, rolled out Power Apps and dynamics in another area.
So you asked the question, how does this project or this piece
of work fit within the organization's strategic goals
and are there any specific initiatives we should alone
(10:27):
with? So for me, if you listen to this
podcast and you do some trainingat the bit of Business Analysis
Institute, very cheap to do so, then you will work out that you
start at the top, you start withyour strategic objectives.
So you ideally, if you're involved up front, you won't end
up in this position. But we sometimes get brought
into this number 8 is, are thereany constraints we should
(10:51):
consider? And people get confused between
issues and risks, constraints and assumptions.
But constraints are things that will, you just can't move.
So projects often get derailed by overlook constraints like
budgets, timelines or legal requirements.
They're things that just can't move.
So they're like roadblocks if you like.
(11:12):
And a scenario as a team can discover late in the process
that the new system doesn't comply with privacy laws.
This happens often when you go overseas to look for a product
and you realise, oh, it's not combined in New Zealand, it's
not complying in the States, or doesn't cater for GST or VAT or
whatever the US equivalent is, or you know, we need Social
(11:34):
Security numbers and it doesn't,it doesn't capture that in a
secure way. So you ask this question by
saying, are there any constraints, budgetary, give
examples, technical, regulatory process, privacy that we need to
factor into our plan? Because that's stuff work that
this project might delve into #9is again, one of my favourites.
(11:57):
It's what does the user journey look like?
What does the customer journey look like?
A user centric of your internal or customer centric of your
external customer eccentric approach ensures that the
project delivers value to end users and customers, not just
stakeholders who may not have skin in the game apart from
(12:17):
their, I don't know, getting a promotion.
When you do a system upgrade focus.
We focus sometimes on backing efficiency reducing waste, but
we neglect the user interface. Literally just had that today.
OK, I'm working for a client. They've changed their financial
system. I got a random e-mail from an an
(12:40):
offshore e-mail address. Nothing to do with the company I
work for, which said click here to reset your password.
It had one tiny clipped brandingof the company, nothing else.
Nothing else about the e-mail. The help link didn't work on the
e-mail. It looked like a phishing
attack, but I happened to know that this was an upgrade
(13:02):
happening and so I clicked on the link.
I know, but I I was educated guess that this was something
that the finance team had done. And of course, it asked me to
enter a couple of new passwords the and it was I did had nothing
to do with the name of the project that was rolling this
out. But then I was asked to enter a
(13:24):
username. And so I entered the username
that we're asked to select a fewweeks ago.
And of course it didn't work. So I used the chatbot that was
built, integrated, reset everything and got in.
But it was a terrible experience.
There will be so many people, hundreds of them, who will not
be able to get into the system or understand what's going on.
Luckily I'm, you know IT savvy, but it was so dodgy.
(13:49):
And so this is an example of user interface.
Emails are an example. Any channel that the user sees.
So what do we do about that? So we ask the question, have we
mapped out the user journey, thecontact points?
Have we worked out how this change will impact their
experience or their onboarding to the new tool?
In my example, should we bring in some end users or some
(14:13):
customers for feedback? Should we try it first?
And #10 which we don't do. We're so isolated in the way we
work in IT and it's what have welearned from similar projects or
has anyone else in their lifetime been involved in this?
Should we bring them on board and, and, and learn something
(14:33):
from their lessons of the past? Leveraging lessons from the past
initiatives reduces repeated mistakes, improves customer
outcomes or internal outcomes. And it's just good practice.
If people have done something like this before, then leverage
those knowledge and insights that will help you.
(14:57):
It's an example where, for example, if a company has rolled
out a file project, right, or they've done it, they've tried
something from a change management point of view and it
didn't work last time, then we should learn why.
It may not have nothing to do with the technical make up of
your projects or even the peoplein your project.
It could just be the way in which you engage with that
(15:18):
certain team. So how do we ask that?
We say, have we undertaken a project like this before, an
initiative with that team before?
If so, what went well and what would we do differently this
time? So there you go.
There are 10 questions that we should ask as BAS that will help
(15:39):
you in the real world. Be diplomatic, use data and be
precise and clear and provide clarity.
The piece of work you're on. They are great questions,
they're game changing. You should ask them every time
as a BA, especially if you've just landed on the project.
(15:59):
I hope you learned something andI'll speak to you next week.
The Better Business Analysis Institute presence, the Better
Business Analysis podcast with Kingsman Walsh.
Hi everybody, and welcome back to the Better Business Analysis
podcast with your host, BenjaminWalsh from the Better Business
Analysis Institute. If you haven't done your
(00:22):
training yet, 199 US and you canget certified as a BA, do it
today. Today we're covering the top ten
questions business analysts should ask, but really do you're
going to learn something today. Let's dive in now.
Some of these questions can be abit awkward, so we're going to
(00:46):
run through the questions, ten of them, and we're going to talk
about why they're significant, maybe cover a scenario, and then
how to ask it. So let's dive in #1 is the most
important. It's what's the real problem
we're solving here? Projects often address symptoms,
(01:07):
not root causes. This question helps ensure that
the work aligns with the actual business needs.
There are many times where you're working on a solution or
someone has come up with a solution, or you're working on a
kind of a generalized problem statement and it's your job to
(01:28):
ask the five wives, do a problemdefinition and try and pull back
and figure out what the root cause.
Here's a typical scenario. A stakeholder wants to implement
a new CRM system but actually hasn't identified the current
system's shortcomings. So what do we do?
This is how we do it. We might ask the question.
(01:50):
It sounds like you're improving customer relationship
management. That's the goal, right?
Can we just take a step back anddiscuss the underlying
challenges this system will solve?
That way I can make sure that myanalysis targets the right
issues and the requirements of focus on solving the problem you
(02:12):
want. Do you notice that I turned it
into a question more around myself and what I needed out of
the situation? And of course, that reduces
friction or the conflict or I don't come across threatening or
challenging. I just come across as someone
who needs help. And so that's a great way of
doing it. So remember that as we go
(02:33):
throughout the other nine questions.
The second one shouldn't be threatening.
It's #2 and it's what does success look like?
Stakeholders often have a vague or even conflicting idea of
success. So that's why it's important to
have one product owner. It's really important to clarify
(02:54):
what success looks like for them.
It prevents misalignment over investment under investment.
So let's take a scenario where your team's rolling out a new
feature. Maybe it's, you know, team
driven and you haven't agreed how to measure success.
You can be in all sorts of trouble.
So what you should do is ask upfront, once this project is
(03:16):
complete, how will we know it's been successful?
Are we focusing on any importantmetrics like revenue or user
adoption or attention or something else?
So that way, for example, if there was an expectation, and of
course you don't know this without asking, that this new
feature was going to increase customer signups or revenue,
(03:40):
then you might be in trouble if the feature was actually about
customer retention. So you got to get that up, sort
it upfront #3 it's who are the stakeholders, who are the key
stakeholders, and what are theirpriorities?
And yeah, you can have a rescue model with a matrix, but
primarily it should be like a pyramid model.
(04:01):
You should ideally have one product owner or sponsor, maybe
a couple of key stakeholders around them and it gets bigger
and bigger as you go down, but you should draw the line at the
top in terms of decision making.So this is very, very common.
There is missing or unconsulted stakeholders.
Just had that happen on one of my pieces of work with some
(04:24):
people who weren't engaged. And that can just derog
projects, right? Especially get to the end and
then UAT, suddenly you've got some new stakeholders who are
then checking to see if the solution met the requirements
and they were involved in the requirements phase.
Happens all the time. You need to understand of
priorities like misaligned and you need to align them and you
(04:46):
need to get decisions upfront. If you don't do this, some
engagements done badly, it's it's you're just fighting fires
all over the place. When you want to go live.
The scenario is that the IT teamis driving a project but end
users and sales haven't been consulted, for example, or the
person responsible for doing website content hasn't hasn't
(05:07):
been involved, or the person whochecks privacy hasn't been
involved. So how do you ask that?
When you start, you should say who else will be impacted by
this change. You should do a change impact
workshop is what a change manager would do, but you can do
it yourself and you need to bring them into the conversation
to get a bigger picture of theirneeds.
(05:29):
So if you're doing with a product owner and that product
owner consistently asked for feedback from a couple of their
team members, for example, you should bring those team members
on Top tip, top tip to you, top tip to me.
OK #4 what assumptions are we making?
Projects often fail because of unexamined kind of unrealized
(05:56):
assumptions. So like underestimating cost,
overestimating user behaviour, maybe thinking that your users
are going to adopt A new change faster than they will.
I have make an assumption about how long it's going to take to
science, a piece of work off before you go live.
So the scenarios here is that companies, organizations might
(06:21):
assume that a customer want a mobile app without actually
verifying demand. So that actually happens.
Everyone went mobile app, mobileapp and mobile apps do one
thing, but maybe they don't wantthat.
Maybe they're happy using the website experience and they're
not going to use it on the go. It's not a kind of an amplified
idea. So to ask that question, we can
(06:43):
say to the team project, projectowner, product owner, project
manager, and your architects anddevelopers as a team meeting,
ask the question, what assumptions are we making about
user behaviour or system capabilities or the ability for
the organization to absorb this change?
(07:03):
Do we need to validate any of these before we move forward?
OK, that's really important. Be bold, ask these questions.
BAS are perfect for doing this #5 this one's awkward, but I
think you should ask this question.
If we don't do this, what happens?
(07:24):
This question challenges whethera project is truly necessary,
and it helps prioritize resources.
It's very awkward if you're on the project contractor
consultant, for example, your reason for your existence, your
income is reliant on the projectcontinuing.
But it takes a brave person to answer this question.
I, I, I have done this in many times and I consistently do it.
(07:47):
So the scenario is that a stakeholder proposes maybe
automating a really used projectprocess, for example.
So they say, let's automate thisso we'll make it better.
And actually no one uses it. So how do we ask this?
We say, let's imagine if we didn't pursue this project, what
would the impact be? Could those resources be better
(08:09):
used on the other piece of work that needs to be done?
So I think the the critical thing here is to say, let's
imagine we didn't pursue this project.
So it's non threatening and allows people to think about
what the alternatives are #6 is what are the risks and how do we
(08:30):
handle risk management done really badly.
Usually risks are identified midproject, not beforehand, not at
the startup, what you should do.And then you just have all these
issues because risks turn into issues when they realize or not
mitigated. So risks are inevitable, they're
going to happen. But identifying them early
allows for mitigation strategies.
(08:52):
So, for example, if a project has tight deadlines, you go to
risk quality output. You got to kill your staff to
try and get done on time and something's going to slip.
Quality of life or quality of product.
So you ask this by saying what risks could impact this
project's timelines, outcome, team morale, culture, user
(09:17):
experience? How should we plan to address
them if they arise? What's our risk mitigation
process? Do we have a risk meeting?
Do we do it in stand up? Do we have a specific risk
workshop upfront? I I would suggest you do.
How are we going to monitor them?
How are we going to escalate them and how are we going to
mitigate them? And who's responsible for doing
that #7 so important. Definitely an area I plan, and
(09:41):
it's asking the question, how does this align with
organizational goals? You need to ensure that the
project you're working on contributes to broader business
outcomes rather than operating in isolation.
Maybe your marketing department wants to develop a new bespoke
tool, but the organization is standardizing software somewhere
(10:04):
else. It happens all the time.
You know, the marketing department's brought in
Salesforce, but you're a Microsoft shop and you've just,
you know, rolled out Power Apps and dynamics in another area.
So you asked the question, how does this project or this piece
of work fit within the organization's strategic goals
and are there any specific initiatives we should alone
(10:27):
with? So for me, if you listen to this
podcast and you do some trainingat the bit of Business Analysis
Institute, very cheap to do so, then you will work out that you
start at the top, you start withyour strategic objectives.
So you ideally, if you're involved up front, you won't end
up in this position. But we sometimes get brought
into this number 8 is, are thereany constraints we should
(10:51):
consider? And people get confused between
issues and risks, constraints and assumptions.
But constraints are things that will, you just can't move.
So projects often get derailed by overlook constraints like
budgets, timelines or legal requirements.
They're things that just can't move.
So they're like roadblocks if you like.
(11:12):
And a scenario as a team can discover late in the process
that the new system doesn't comply with privacy laws.
This happens often when you go overseas to look for a product
and you realise, oh, it's not combined in New Zealand, it's
not complying in the States, or doesn't cater for GST or VAT or
whatever the US equivalent is, or you know, we need Social
(11:34):
Security numbers and it doesn't,it doesn't capture that in a
secure way. So you ask this question by
saying, are there any constraints, budgetary, give
examples, technical, regulatory process, privacy that we need to
factor into our plan? Because that's stuff work that
this project might delve into #9is again, one of my favourites.
(11:57):
It's what does the user journey look like?
What does the customer journey look like?
A user centric of your internal or customer centric of your
external customer eccentric approach ensures that the
project delivers value to end users and customers, not just
stakeholders who may not have skin in the game apart from
(12:17):
their, I don't know, getting a promotion.
When you do a system upgrade focus.
We focus sometimes on backing efficiency reducing waste, but
we neglect the user interface. Literally just had that today.
OK, I'm working for a client. They've changed their financial
system. I got a random e-mail from an an
(12:40):
offshore e-mail address. Nothing to do with the company I
work for, which said click here to reset your password.
It had one tiny clipped brandingof the company, nothing else.
Nothing else about the e-mail. The help link didn't work on the
e-mail. It looked like a phishing
attack, but I happened to know that this was an upgrade
(13:02):
happening and so I clicked on the link.
I know, but I I was educated guess that this was something
that the finance team had done. And of course, it asked me to
enter a couple of new passwords the and it was I did had nothing
to do with the name of the project that was rolling this
out. But then I was asked to enter a
(13:24):
username. And so I entered the username
that we're asked to select a fewweeks ago.
And of course it didn't work. So I used the chatbot that was
built, integrated, reset everything and got in.
But it was a terrible experience.
There will be so many people, hundreds of them, who will not
be able to get into the system or understand what's going on.
Luckily I'm, you know IT savvy, but it was so dodgy.
(13:49):
And so this is an example of user interface.
Emails are an example. Any channel that the user sees.
So what do we do about that? So we ask the question, have we
mapped out the user journey, thecontact points?
Have we worked out how this change will impact their
experience or their onboarding to the new tool?
In my example, should we bring in some end users or some
(14:13):
customers for feedback? Should we try it first?
And #10 which we don't do. We're so isolated in the way we
work in IT and it's what have welearned from similar projects or
has anyone else in their lifetime been involved in this?
Should we bring them on board and, and, and learn something
(14:33):
from their lessons of the past? Leveraging lessons from the past
initiatives reduces repeated mistakes, improves customer
outcomes or internal outcomes. And it's just good practice.
If people have done something like this before, then leverage
those knowledge and insights that will help you.
(14:57):
It's an example where, for example, if a company has rolled
out a file project, right, or they've done it, they've tried
something from a change management point of view and it
didn't work last time, then we should learn why.
It may not have nothing to do with the technical make up of
your projects or even the peoplein your project.
It could just be the way in which you engage with that
(15:18):
certain team. So how do we ask that?
We say, have we undertaken a project like this before, an
initiative with that team before?
If so, what went well and what would we do differently this
time? So there you go.
There are 10 questions that we should ask as BAS that will help
(15:39):
you in the real world. Be diplomatic, use data and be
precise and clear and provide clarity.
The piece of work you're on. They are great questions,
they're game changing. You should ask them every time
as a BA, especially if you've just landed on the project.
(15:59):
I hope you learned something andI'll speak to you next week.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.