Ever delivered the exact requirements… and still watched the solution fall flat?
In this episode, I break down the top 10 reasons BAs miss the mark – even when everything looks “right” on paper. From unspoken stakeholder expectations to the trap of treating Agile ceremonies as substitutes for real analysis, this is a no-fluff guide to what separates average BAs from truly impactful ones.
✅ Why requirements ≠ expectations
✅ The hidden cost of skipping personas
✅ Why “in Jira” doesn’t mean “understood”
✅ How to link every requirement to real business value
Whether you're a junior BA or a senior working on strategic initiatives, this episode will challenge how you approach your next piece of work.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:01):
Even now the requirements only to have the business say this is
not what I wanted. Today we dive into the top ten
ways business analysts, Mr. Mark, even when they've ticked
every box. The Better Business Analysis
(00:21):
Institute presence, the Better Business Analysis podcast with
Kingsman Walsh. To the Better Business Analysis
podcast with your host, BenjaminBosch.
If you haven't added me on LinkedIn, feel free to do so.
It's always great to connect to my listeners and some of you go
(00:42):
out of your way to send me a message about how much value you
get from the podcast. I love it.
Keep doing it. This week we're talking about
the top ten ways. BAS miss the mark even when the
requirements are done right #10 mistake that we make as BAS is
(01:03):
thinking that the requirements are the same as expectations.
And this is something that I guess the agile revolution was
trying to address. But expectations change all the
time and they have lots of multifaceted reasons for doing so,
mainly political, sometimes in in an organization.
(01:26):
So just to be really clear, requirements are what
stakeholders say and you elicitate out of them.
So you apply logic to what they're asking for and you
elicitate those requirements. You find out what you think they
need, right? The expectations of what they
believe goes deeper. When a client might say we need
(01:53):
to report on student attendance,the expectation in their mind,
and this is a real life example here in New Zealand, might be
real time visibility. Oh well, it's mobile friendly.
They haven't asked for any of that.
That's not part of the requirements that they said to
us. Requirements.
Even if you stoke them for the shopping list, some of those
(02:15):
things might not come out and you might deliver a Power BI
report in our case, or a status static spreadsheet that's
uploaded onto a website. And technically it's right.
I mean, literally it meets the need and you've done all the
right things by not, you know, delivering too much, you've just
invested enough value. But maybe that's not their
(02:39):
expectation, even though it practically meets the needs.
So you've just got to be really clear that you get to the root
cause of the problem and, and bring them along.
So the expectations are very well informed and brought down
to reality before you start #9 is that it's the not surfacing
(02:59):
of the unspoken need, right? And this is where elicitation,
where a junior moves on to a medium BA, when they can start
poking the fire and getting out the really good stuff.
Stakeholders won't always tell you what they really want.
They expect you to dig. So yes, there's expectations,
(03:20):
which are the beliefs. And now beginning to the
practical, this is elicitation. This is exactly what this point
is. And the user asked for a drop
down field. What they really need is a look
up that's maintained centrally to avoid human error.
So again, recently we've sort ofsaid we need a list, we need a
(03:41):
list of codes, and this is what they're going to be.
The solution is enforced. What you really need to
understand is what are you goingto be using it for?
What do you want it and what is the user's purpose of that step
in the user's journey? And you might find that actually
a drop down field is not quite right.
What about multi select of thosewho are are technically minded?
(04:03):
Maybe you want to choose more than one thing.
I was on a project years ago when I had the idea of a kind of
a drop down or a selection type box.
I gave that in to a designer as part of the requirements
process. And you know, I didn't think it
was necessarily the only requirement.
You know, maybe there were otherthings that the user needed
(04:25):
along their journey and actuallythe interface that was designed
which did meet the overall expectations of earning
customers. It wasn't a drop down box at
all. It was kind of filled in as you
typed. And yes, it was fundamentally a
controller of some description, but it was actually limited in a
drop down box would have been really boring.
(04:46):
And the target demographic that we're going after were people
were looking to study at university.
And what we actually created wassomething that was almost a
sentence that they were creatingon the fly.
And if you think about the next leap, now you know, maybe A is
better to generate a sentence structure.
So for example, a chat prompt may be better than just limit
(05:10):
sending people to some options. It really depends on what you're
trying to achieve #8 is ignoringthe emotional drivers.
You need to have really high EQ to be a great BA.
OK, a better BA business decisions are emotional.
(05:31):
They are, you can have them, thesmartest people in the room,
they're emotional. Some of the best people out
there, they make emotional decisions.
And yes, we try and say that we want to cut that out.
That's of business. And you know, it should all be
fact driven. There is always emotion.
It's either power or fear, legacy, reputation, fear from
(05:53):
stakeholders. You know there's emotion behind
it. Caring, not caring.
Selfishness. If you don't know who feels what
you'll deliver features no one uses.
You need to understand their emotional cues, and an empathy
(06:15):
map is great for that. Let's look at an example here.
An OPS manager may block the rollout of an auto scheduling
tool because it threatens their role, not because it won't work,
not because it won't make thingsmore effective.
So you're, there is an emotionalelement here and, and this steps
(06:37):
into, you know, emotions and politics, but just want to start
with emotions. And then we'll look at some of
the other challenges we have #7 is again, just assuming that
stakeholders know what they want, They don't.
That's actually your job. If you talk to a stakeholder and
(06:59):
this happens often, it's just and they might say, hey, look,
just copy what the other system does.
We just want something that works that way.
Instead, ask why did that work? What didn't work?
You need to create from need, not past a nostalgia or an idea
(07:25):
about how something else went inthe past.
The OK, so people especially this happens quite a lot in
executive teams and I've spoken about before is that they really
remember the things go really well or not so well.
And IT projects are sometimes lumped into the not so well
category. And they'll remember that.
And then if things do go well, they'll say, oh, look, we did
(07:45):
this thing at this company and we just want to have a copy of
that. You're like, Are you sure you
do? So that's what they remember.
And it is, we are solution market mode.
A lot of times in business we dothink about solutions.
So you need to accept that and work backwards with them and use
the five whys and find out what they're trying to achieve.
(08:08):
The problem statement. The other one that I stress on
about, you'll hear me talk aboutthis often is that if there is
no persona, there's no context. If you haven't defined the the
personas you're going after, thecustomer personas, the user
personas, you don't really have true context.
(08:30):
You don't really know who you'retrying to help or support or
what their needs are. On some of those other elements
we talked about. What are they generally want in
life? What is their emotional state?
You know, what's their past decision making apparatus?
How are they? What's their political play in
(08:52):
the organization and what's their lived experience?
And then that will help you if you deliver a workflow that
works perfectly on a desktop. It could be the fact that the
field staff are mobile only. Game over, you know, or they
need fast Internet. It's not going to work over, for
(09:14):
example, I don't know, some bad Internet connection in the
middle of nowhere, right? This happens a lot.
That particular problem happens a lot.
I think a lot of people have been bitten by the old field
services problem where they've developed something that works
great internally in the office. They roll it out and there's too
(09:34):
grunty or heavy for a mobile device or the mobile device
doesn't support it, not mobile friendly or they can't data
entry all the stuff you wanted them to enter from the field
because it's just too much information to enter on a, you
know, on a screen on a mobile phone and but central office
wants it. This is a common problem #5 is
(09:59):
forgetting that the B as job is translation OK?
The simplest way to describe ABA, if you ask anyone, is that
we translate the needs of the business into technical talk.
I still use that definition thatpeople ask me what ABA do does
and it's we need to make it really clear that we're not the
(10:20):
note taker but we are the translator between business need
and solution reality. It's even a better way of saying
it's business need and what's the reality and the logic behind
it. Processes is another word that
comes up. There gets a requirement around
showing student risk indicators on a report, but what are the
(10:42):
indicators? What are they for?
Are they delivery colour coded? Drill down?
The BA may have left it vague and I guess the fix here is to
translate the outcome and the usage context clearly right?
So you're not over prescribing this.
I do feel like sometimes developers get to a point where
(11:03):
they don't get enough information so they just want a
lot. But it's actually better to work
with them, bringing them on board and say this is the
outcome, this is the usage context and you show it and you
don't just say it. And then they can have a, a
piece of pie that can be part ofthe solution.
And if you're true prescriptive,then as I said before with the
(11:27):
drop down box example, the designer was the person who made
it a reality. And they know more than I do
because I'm not a designer. There's a funny example in my
life at the moment where I literally drew on a via Teams
meeting. There's a whiteboard app you can
plug in and I drew very badly with my mouse a a graph, a graph
(11:52):
that I thought would add value for a project.
And it was really bad looking graph, right.
Literally drew a line down left,you know, with the L shape of
the curve. Put some badly written labels on
the right and just showed this trend line I wanted in the
stacks and I named them. And I was in a, a call with the
(12:13):
supplier with one of the architects there and we were
talking about the report, the report that we wanted.
And that mock up, not even a mock up, that napkin drawn idea
that I had months before was in the requirements and it was and
(12:35):
now we're talking about it. And it's really funny because I
hadn't over engineered it, but they got it because of the great
engagement by architect, by the conversations that Tickley was
having with them, the content, additional context we gave.
That's all they needed, right? And and they didn't want me to,
you know, as dictate what the report should look like.
(12:57):
They're the experts. OK, so you just got to remember
that as ABA, sometimes I'm I'm guilty of it.
Sometimes just expect, you know,you feel like you have to
micromanage the delivery of it, right?
And sometimes BS had to do that to salvage a project if things
are going badly. But on a, on a highly productive
team, we've got trust and everyone knows their role.
(13:21):
It's that may be enough. The napkin approach may be
enough. And and you know, it makes me
smile. I laughed and I smiled.
I'm a little bit embarrassed, but you know, it worked.
OK #4 is the over reliance on agile ceremonies and and you
know, this is this is a problem.This is one of the things that
(13:41):
you know, people keep saying Agile's dead and it probably is
the capital A is probably dead. Just because you're in Jira
doesn't mean it's understood. Agile rituals don't replace BA
thinking product donor is not ABA.
OK. The different role, it's within
(14:02):
the agile realm now. Yes, the product owner defined
it. Your organization may well be
called a product owner and may well require all the BA skills
that ABA has, but that's not theagile version of it, OK, Because
Agile talks about the delivery, Scrum talks about the delivery
side of things, not necessarily the upfront analysis.
(14:23):
That step starts before delivery.
So if there's an example of, youknow, as a user, I want to log
on whatever so that I can. There's no mention of the fact
that it needs to be two FA session expiry password, you
know, reset flows. It's a lazy story and it's a bad
(14:47):
result because the BA logic is missing.
And in addition, the business rules which make which those are
under the requirement. And there are various ways we
can do this, which we've discussed through descriptions,
through acceptance criteria, through additional
documentation, you know, not documentation with a capital D
small documentation, business rule spreadsheet.
(15:08):
These are great ways we do it. And of course then then what
connecting flow. You don't get flow in sequence.
You get that from process diagrams and then you get
context from context diagrams and drawings and you get ideas
from mock ups. I am more kind of, I guess,
(15:28):
conceptual reality, you know, visuals.
And in addition to that, you getthe upfront enterprise and
strategic analysis, which is thewhy we're doing this, the pistol
analysis, the why's the problem statement.
So that all the additional things, I've just blighted them
(15:50):
all out there for you that BOS do that are not part of the edge
of delivery. That's not part of it.
That's edge of deliveries later #3 is not managing stakeholder
alignment. And this is a problem.
And this is where the capital P politics comes into play.
(16:12):
You can't just document the requirements and do all those
great things we just talked about.
You actually have to align people and say marketing wants
speed and finance wants compliance and you document
both. The dev team may be stuck in the
middle if you've been lazy and you haven't worked it out before
The edge of delivery. You need to facilitate
(16:34):
decisions, highlight when there needs to be a decision made to
governance groups, and don't just capture opinions.
OK, this is what finance said, this is what marketing wants.
And let the developer do that. It's a waste of time for them.
The well oiled delivery machine,you don't want those guys to be
focused on that. You're asking them to do your
(16:55):
job or the governance team's job#2 is that you need to trace all
your requirements, all the things you do to true business
value. I'm hot on this.
Doesn't happen often. So it's no traceability of
business value is number 2. Building features or things
(17:19):
without mapping value is where BAS die quiet paths.
They really do. So you, you, the example is you
build 20 custom fields. No one knows what they're used
for. They're not labeled well.
They clutter the UI and they just deliver no insight because
someone asked you to collect that information.
(17:40):
They wanted more data because itwas the data team.
This happens often. Now you need to link every
requirement to the business objective.
OK, you need to do that via the Epic in my mind.
And if you've got features, thenthey may be grouped into
features as well. And you need to do that
ruthlessly. If there isn't the business
(18:01):
value and there may be a productowner you're working with or a
business owner depending on flavours, they need to
understand the value too so theycan grade and prioritize.
Not just about how much. If it's going to be involved.
It's not a scrum thing. What's the value to the business
and #1 is not testing for meaningful use validation isn't
(18:25):
just UAT passed? Does this help someone do their
job better? Can job to be done?
Can they do better? BA might sign off a dashboard.
Users never open it. The inside might be the fact
that it takes 5 clicks to get towhere I want it to be because
(18:48):
you had to negotiate requirements and this is the
mess you got in BA. Being ABA is not easy.
Being a better BA is even harder.
You need to ask someone, show mehow do you you would use this?
And that's why mock ups are useful, so you can actually show
(19:08):
the flow all the way through andshow them and and I guess play
back to them is even more importantly, this is what you're
asking for. Is this what you meant?
Right. And then if you know, if there
is negotiations, because there are with developers, they might
go, well, it's hard to do that. This is how we've done it
previously. This is where it's going to be.
You're like, wow, you know, they're going to pay you to do a
(19:30):
little bit more to do it this way.
Is that OK? Or that might not.
If that's the only way we can doit, I'm going to go back and
tell the product owner, businessowner that this is what they're
going to get and just make sure that it's going to meet their
expectations, which we started with here today.
And if it isn't and that's the only way, maybe they don't want
it that way. Maybe they don't want to stop
(19:51):
it. Maybe they don't want to invest.
Don't be afraid of closing something down and saying no,
OK? I'm not saying no to the
business owner. You're just saying no, we just,
we shouldn't do it. That's my recommendation.
Being ABA isn't about documenting what's said, it's
about uncovering what matters, testing for meaning, and
(20:11):
connecting people, problems, andpossibilities.
If you've ever built the right thing and still got it wrong,
then this episode in these 10 points are for you.
I'll see you next week.
Even now the requirements only to have the business say this is
not what I wanted. Today we dive into the top ten
ways business analysts, Mr. Mark, even when they've ticked
every box. The Better Business Analysis
(00:21):
Institute presence, the Better Business Analysis podcast with
Kingsman Walsh. To the Better Business Analysis
podcast with your host, BenjaminBosch.
If you haven't added me on LinkedIn, feel free to do so.
It's always great to connect to my listeners and some of you go
(00:42):
out of your way to send me a message about how much value you
get from the podcast. I love it.
Keep doing it. This week we're talking about
the top ten ways. BAS miss the mark even when the
requirements are done right #10 mistake that we make as BAS is
(01:03):
thinking that the requirements are the same as expectations.
And this is something that I guess the agile revolution was
trying to address. But expectations change all the
time and they have lots of multifaceted reasons for doing so,
mainly political, sometimes in in an organization.
(01:26):
So just to be really clear, requirements are what
stakeholders say and you elicitate out of them.
So you apply logic to what they're asking for and you
elicitate those requirements. You find out what you think they
need, right? The expectations of what they
believe goes deeper. When a client might say we need
(01:53):
to report on student attendance,the expectation in their mind,
and this is a real life example here in New Zealand, might be
real time visibility. Oh well, it's mobile friendly.
They haven't asked for any of that.
That's not part of the requirements that they said to
us. Requirements.
Even if you stoke them for the shopping list, some of those
(02:15):
things might not come out and you might deliver a Power BI
report in our case, or a status static spreadsheet that's
uploaded onto a website. And technically it's right.
I mean, literally it meets the need and you've done all the
right things by not, you know, delivering too much, you've just
invested enough value. But maybe that's not their
(02:39):
expectation, even though it practically meets the needs.
So you've just got to be really clear that you get to the root
cause of the problem and, and bring them along.
So the expectations are very well informed and brought down
to reality before you start #9 is that it's the not surfacing
(02:59):
of the unspoken need, right? And this is where elicitation,
where a junior moves on to a medium BA, when they can start
poking the fire and getting out the really good stuff.
Stakeholders won't always tell you what they really want.
They expect you to dig. So yes, there's expectations,
(03:20):
which are the beliefs. And now beginning to the
practical, this is elicitation. This is exactly what this point
is. And the user asked for a drop
down field. What they really need is a look
up that's maintained centrally to avoid human error.
So again, recently we've sort ofsaid we need a list, we need a
(03:41):
list of codes, and this is what they're going to be.
The solution is enforced. What you really need to
understand is what are you goingto be using it for?
What do you want it and what is the user's purpose of that step
in the user's journey? And you might find that actually
a drop down field is not quite right.
What about multi select of thosewho are are technically minded?
(04:03):
Maybe you want to choose more than one thing.
I was on a project years ago when I had the idea of a kind of
a drop down or a selection type box.
I gave that in to a designer as part of the requirements
process. And you know, I didn't think it
was necessarily the only requirement.
You know, maybe there were otherthings that the user needed
(04:25):
along their journey and actuallythe interface that was designed
which did meet the overall expectations of earning
customers. It wasn't a drop down box at
all. It was kind of filled in as you
typed. And yes, it was fundamentally a
controller of some description, but it was actually limited in a
drop down box would have been really boring.
(04:46):
And the target demographic that we're going after were people
were looking to study at university.
And what we actually created wassomething that was almost a
sentence that they were creatingon the fly.
And if you think about the next leap, now you know, maybe A is
better to generate a sentence structure.
So for example, a chat prompt may be better than just limit
(05:10):
sending people to some options. It really depends on what you're
trying to achieve #8 is ignoringthe emotional drivers.
You need to have really high EQ to be a great BA.
OK, a better BA business decisions are emotional.
(05:31):
They are, you can have them, thesmartest people in the room,
they're emotional. Some of the best people out
there, they make emotional decisions.
And yes, we try and say that we want to cut that out.
That's of business. And you know, it should all be
fact driven. There is always emotion.
It's either power or fear, legacy, reputation, fear from
(05:53):
stakeholders. You know there's emotion behind
it. Caring, not caring.
Selfishness. If you don't know who feels what
you'll deliver features no one uses.
You need to understand their emotional cues, and an empathy
(06:15):
map is great for that. Let's look at an example here.
An OPS manager may block the rollout of an auto scheduling
tool because it threatens their role, not because it won't work,
not because it won't make thingsmore effective.
So you're, there is an emotionalelement here and, and this steps
(06:37):
into, you know, emotions and politics, but just want to start
with emotions. And then we'll look at some of
the other challenges we have #7 is again, just assuming that
stakeholders know what they want, They don't.
That's actually your job. If you talk to a stakeholder and
(06:59):
this happens often, it's just and they might say, hey, look,
just copy what the other system does.
We just want something that works that way.
Instead, ask why did that work? What didn't work?
You need to create from need, not past a nostalgia or an idea
(07:25):
about how something else went inthe past.
The OK, so people especially this happens quite a lot in
executive teams and I've spoken about before is that they really
remember the things go really well or not so well.
And IT projects are sometimes lumped into the not so well
category. And they'll remember that.
And then if things do go well, they'll say, oh, look, we did
(07:45):
this thing at this company and we just want to have a copy of
that. You're like, Are you sure you
do? So that's what they remember.
And it is, we are solution market mode.
A lot of times in business we dothink about solutions.
So you need to accept that and work backwards with them and use
the five whys and find out what they're trying to achieve.
(08:08):
The problem statement. The other one that I stress on
about, you'll hear me talk aboutthis often is that if there is
no persona, there's no context. If you haven't defined the the
personas you're going after, thecustomer personas, the user
personas, you don't really have true context.
(08:30):
You don't really know who you'retrying to help or support or
what their needs are. On some of those other elements
we talked about. What are they generally want in
life? What is their emotional state?
You know, what's their past decision making apparatus?
How are they? What's their political play in
(08:52):
the organization and what's their lived experience?
And then that will help you if you deliver a workflow that
works perfectly on a desktop. It could be the fact that the
field staff are mobile only. Game over, you know, or they
need fast Internet. It's not going to work over, for
(09:14):
example, I don't know, some bad Internet connection in the
middle of nowhere, right? This happens a lot.
That particular problem happens a lot.
I think a lot of people have been bitten by the old field
services problem where they've developed something that works
great internally in the office. They roll it out and there's too
(09:34):
grunty or heavy for a mobile device or the mobile device
doesn't support it, not mobile friendly or they can't data
entry all the stuff you wanted them to enter from the field
because it's just too much information to enter on a, you
know, on a screen on a mobile phone and but central office
wants it. This is a common problem #5 is
(09:59):
forgetting that the B as job is translation OK?
The simplest way to describe ABA, if you ask anyone, is that
we translate the needs of the business into technical talk.
I still use that definition thatpeople ask me what ABA do does
and it's we need to make it really clear that we're not the
(10:20):
note taker but we are the translator between business need
and solution reality. It's even a better way of saying
it's business need and what's the reality and the logic behind
it. Processes is another word that
comes up. There gets a requirement around
showing student risk indicators on a report, but what are the
(10:42):
indicators? What are they for?
Are they delivery colour coded? Drill down?
The BA may have left it vague and I guess the fix here is to
translate the outcome and the usage context clearly right?
So you're not over prescribing this.
I do feel like sometimes developers get to a point where
(11:03):
they don't get enough information so they just want a
lot. But it's actually better to work
with them, bringing them on board and say this is the
outcome, this is the usage context and you show it and you
don't just say it. And then they can have a, a
piece of pie that can be part ofthe solution.
And if you're true prescriptive,then as I said before with the
(11:27):
drop down box example, the designer was the person who made
it a reality. And they know more than I do
because I'm not a designer. There's a funny example in my
life at the moment where I literally drew on a via Teams
meeting. There's a whiteboard app you can
plug in and I drew very badly with my mouse a a graph, a graph
(11:52):
that I thought would add value for a project.
And it was really bad looking graph, right.
Literally drew a line down left,you know, with the L shape of
the curve. Put some badly written labels on
the right and just showed this trend line I wanted in the
stacks and I named them. And I was in a, a call with the
(12:13):
supplier with one of the architects there and we were
talking about the report, the report that we wanted.
And that mock up, not even a mock up, that napkin drawn idea
that I had months before was in the requirements and it was and
(12:35):
now we're talking about it. And it's really funny because I
hadn't over engineered it, but they got it because of the great
engagement by architect, by the conversations that Tickley was
having with them, the content, additional context we gave.
That's all they needed, right? And and they didn't want me to,
you know, as dictate what the report should look like.
(12:57):
They're the experts. OK, so you just got to remember
that as ABA, sometimes I'm I'm guilty of it.
Sometimes just expect, you know,you feel like you have to
micromanage the delivery of it, right?
And sometimes BS had to do that to salvage a project if things
are going badly. But on a, on a highly productive
team, we've got trust and everyone knows their role.
(13:21):
It's that may be enough. The napkin approach may be
enough. And and you know, it makes me
smile. I laughed and I smiled.
I'm a little bit embarrassed, but you know, it worked.
OK #4 is the over reliance on agile ceremonies and and you
know, this is this is a problem.This is one of the things that
(13:41):
you know, people keep saying Agile's dead and it probably is
the capital A is probably dead. Just because you're in Jira
doesn't mean it's understood. Agile rituals don't replace BA
thinking product donor is not ABA.
OK. The different role, it's within
(14:02):
the agile realm now. Yes, the product owner defined
it. Your organization may well be
called a product owner and may well require all the BA skills
that ABA has, but that's not theagile version of it, OK, Because
Agile talks about the delivery, Scrum talks about the delivery
side of things, not necessarily the upfront analysis.
(14:23):
That step starts before delivery.
So if there's an example of, youknow, as a user, I want to log
on whatever so that I can. There's no mention of the fact
that it needs to be two FA session expiry password, you
know, reset flows. It's a lazy story and it's a bad
(14:47):
result because the BA logic is missing.
And in addition, the business rules which make which those are
under the requirement. And there are various ways we
can do this, which we've discussed through descriptions,
through acceptance criteria, through additional
documentation, you know, not documentation with a capital D
small documentation, business rule spreadsheet.
(15:08):
These are great ways we do it. And of course then then what
connecting flow. You don't get flow in sequence.
You get that from process diagrams and then you get
context from context diagrams and drawings and you get ideas
from mock ups. I am more kind of, I guess,
(15:28):
conceptual reality, you know, visuals.
And in addition to that, you getthe upfront enterprise and
strategic analysis, which is thewhy we're doing this, the pistol
analysis, the why's the problem statement.
So that all the additional things, I've just blighted them
(15:50):
all out there for you that BOS do that are not part of the edge
of delivery. That's not part of it.
That's edge of deliveries later #3 is not managing stakeholder
alignment. And this is a problem.
And this is where the capital P politics comes into play.
(16:12):
You can't just document the requirements and do all those
great things we just talked about.
You actually have to align people and say marketing wants
speed and finance wants compliance and you document
both. The dev team may be stuck in the
middle if you've been lazy and you haven't worked it out before
The edge of delivery. You need to facilitate
(16:34):
decisions, highlight when there needs to be a decision made to
governance groups, and don't just capture opinions.
OK, this is what finance said, this is what marketing wants.
And let the developer do that. It's a waste of time for them.
The well oiled delivery machine,you don't want those guys to be
focused on that. You're asking them to do your
(16:55):
job or the governance team's job#2 is that you need to trace all
your requirements, all the things you do to true business
value. I'm hot on this.
Doesn't happen often. So it's no traceability of
business value is number 2. Building features or things
(17:19):
without mapping value is where BAS die quiet paths.
They really do. So you, you, the example is you
build 20 custom fields. No one knows what they're used
for. They're not labeled well.
They clutter the UI and they just deliver no insight because
someone asked you to collect that information.
(17:40):
They wanted more data because itwas the data team.
This happens often. Now you need to link every
requirement to the business objective.
OK, you need to do that via the Epic in my mind.
And if you've got features, thenthey may be grouped into
features as well. And you need to do that
ruthlessly. If there isn't the business
(18:01):
value and there may be a productowner you're working with or a
business owner depending on flavours, they need to
understand the value too so theycan grade and prioritize.
Not just about how much. If it's going to be involved.
It's not a scrum thing. What's the value to the business
and #1 is not testing for meaningful use validation isn't
(18:25):
just UAT passed? Does this help someone do their
job better? Can job to be done?
Can they do better? BA might sign off a dashboard.
Users never open it. The inside might be the fact
that it takes 5 clicks to get towhere I want it to be because
(18:48):
you had to negotiate requirements and this is the
mess you got in BA. Being ABA is not easy.
Being a better BA is even harder.
You need to ask someone, show mehow do you you would use this?
And that's why mock ups are useful, so you can actually show
(19:08):
the flow all the way through andshow them and and I guess play
back to them is even more importantly, this is what you're
asking for. Is this what you meant?
Right. And then if you know, if there
is negotiations, because there are with developers, they might
go, well, it's hard to do that. This is how we've done it
previously. This is where it's going to be.
You're like, wow, you know, they're going to pay you to do a
(19:30):
little bit more to do it this way.
Is that OK? Or that might not.
If that's the only way we can doit, I'm going to go back and
tell the product owner, businessowner that this is what they're
going to get and just make sure that it's going to meet their
expectations, which we started with here today.
And if it isn't and that's the only way, maybe they don't want
it that way. Maybe they don't want to stop
(19:51):
it. Maybe they don't want to invest.
Don't be afraid of closing something down and saying no,
OK? I'm not saying no to the
business owner. You're just saying no, we just,
we shouldn't do it. That's my recommendation.
Being ABA isn't about documenting what's said, it's
about uncovering what matters, testing for meaning, and
(20:11):
connecting people, problems, andpossibilities.
If you've ever built the right thing and still got it wrong,
then this episode in these 10 points are for you.
I'll see you next week.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.