The Better Business Analysis Institute presence the Better
Business Analysis Podcast with Hi everybody and welcome back to
the Better Business Analysis Podcast with Benjamin Walsh.
Now if you haven't checked out our website, The Better Business
Analysis Institute, then please do so.
Go to BB A dot Institute and check us out.
There's some courses and some materials on there.
If you stay to the end of the podcast and those of you who are
getting into business analysis, we've got a special deal for
you. So if you listen at the very end
of this podcast, then I'll talk to you about that.
Otherwise, let's get straight into this week's topic.
This week we're talking about a conundrum that a lot of us face.
It's very hard to even focus on this when you're in the middle
of a project and it's something that should really be brought up
just after you've done some high level scoping, so high level
requirements effectively. And it is something that a lot
of us don't even discuss, and it's avoided.
And you might be picked on this, you know, years later when
you're focusing on pieces of work you may have done at your
previous jobs. The topic I wanna talk about
today is whether or not you should continuously improve a
product or service you're working on, or whether or not
you should just start again and throw it away now.
There are a group of people, fundamental agilists, who do
believe that you can continuously improve your way
out of anything. They are very focused on
evolution and the fact that survival of the fittest and that
you can evolve a product to be the best it can be.
And you know there is some truth to that, but that takes a lot of
time and it involves a whole lot of waste.
I'm going to ignore that school of thought when we get onto this
topic. I'll start with an analogy.
It's a story about two men who live in a village in India who
are asked by their elder, the elder of the village, to collect
more water. They need more water in their
village. And these two gentlemen, they
these two men, they say that they both have different ideas
for how to make that happen. And so there is the first man,
And the first man says, hey, look, what I'm going to do is
keep it simple. I'm just going to, I just need
more people. So, you know, men, women,
children are going more, more of them are going to use the
buckets we use today and they're going to go and they just, you
just have more people walking to the lake and bringing back fresh
water. And the secret man says that is
that's, you know, that's not changing the world.
All you're doing there is, you know, adding more people to what
he believed for the problems. So the second gentleman was
innovative. He was, you know, if you like an
agilist. He found and sourced a whole lot
of buckets that had been put in the back of the story.
And these buckets were near perfect.
However, they just that that's one slight problem with them
which was they had a little tiny hole in the bucket.
However, he didn't see that as a problem because his idea was
about taking that bucket and he not only took that bucket, he
managed to attach handles to it so that the people that were
carrying the water, the same people that were carrying the
water from the lake back to the village could carry it easier.
So it was easier for them to carry.
And then he thought, hey look, I want these people to have pride
in the in this job that they've got.
And so instead of the traditional buckets, they were
just a a clay brown. I'm going to paint each of the
buckets so they're going to have beautiful colors and people can
feel awesome about this kind of, you know, if you like hard
labor, job of collecting water from the lake.
They'd feel proud that they had their individually named and
designed bucket that they could have.
And then later on a couple of weeks later, he said, well look,
I could actually design A pulley system and add wheels to my
bucket. So not only is it a beautiful
bucket and it was easy to carry if they need to, I've also made
it faster. I can carry water from the lake
back to the village in half the time, so I don't need as many
people. I need half the people or in
this case I'll keep the same amount of people cause we'll
double the amount of water that we are bringing back.
And at the end of the month, the village out of called the two
gentlemen back in to have a conversation.
He said, look, I've seen what's happened.
You've been adding more people to your bucket line.
The first gentleman, that's nice, I can see that working.
And the 2nd gentleman, I can see that you've been working very,
very hard and you've added huge amount of features.
These are beautiful buckets. You are, you know, you've got
people who are moving water much faster back to the village.
And he said, and I've made a decision about which idea I'm
going to go with. I'm going to go was option one
with gentlemen one just adding more people to the bucket line.
The 2nd gentleman, the one who'd been working so hard with his
beautiful user friendly buckets asked straight away was quite
angry and he asked the village out of why?
Why aren't you using my idea? It's it cuts down the journey by
50% And the village outer said, Despite that fact, when you come
back to the village you have a hole in your bucket.
And so the amount of water that you're collecting is only 1/3 of
how much I get from each bucket. I get delivered from the
gentleman one's idea who's just added more people to the way we
do things today. And that analogy is important
because it shows you that it doesn't matter how hard you work
on something. It doesn't matter how many
features. It doesn't even matter if those
features actually make the process better, right?
They would literally. The wheels were a great idea,
the color was a great idea you had.
You know, maybe they were desirable to even do the job.
However, if it doesn't do its prime fish purpose, if it
doesn't solve, it's the fundamental problem you're
trying to solve, which is more water back to the village.
Doesn't matter how much time the the village out.
Didn't say he didn't care how long it took, he just needed to
solve a problem of doubling the amount of water that the village
needed. If you don't solve the problem,
if you don't solve the fundamental problem that you're
trying to achieve, everything else doesn't matter.
It doesn't matter how much time and effort you spend on
something, and we forget that. We forget that when we're on a
project we don't challenge it enough and This is why the
business case and the pre project phase of business
analysis is so important and why we talk about it so much at the
institute. It is, it is where you know 90
or let's lose the 8020 rule where 80% of the decision making
you know is the most fundamental and 20 the rest is 20% along the
way. OK, whether or not you're going
to deliver it or not. So just remember that analogy.
If there's a hole in your bucket, if there's a hole in the
idea, if it's a fundamental problem, a hole, even if it's
small and you see it, raise it straight away.
It's, you know, some people call it the elephant in the room, but
I call it the hole in the bucket scenario.
OK. So that is fundamentally, if
you're getting that feeling that we're not solving the problem,
then you know, you need to call it.
And so how do we, how do we get there?
So one is to ask what the problem is that you're trying to
solve. When you jump on a project,
understand the problem, making sure you bring it up, making
sure that the objectives of the project link to the problem.
So the objectives in this case of the bucket scenario was
speed. Then maybe, you know, increasing
speed would have been fundamental, but the number one
objective was around moving more water.
So that should be your objective that this the problem you're
trying to solve is bringing more water back to the village.
Then the objective should be increasing the amount of water
that would deliver to the village by 200% by the end of X.
So you've maybe got a timeframe around it, which is a smart
objective. So that the front do 2
fundamental techniques that you should understand as a BA, which
is problem analysis, which we've talked about.
And if you don't know what that is, I'll go on to our YouTube
page or listen to the podcast about it.
And the other one is around objectives, using smart
objectives, which we cover in the level one course, which is
how to define smart objectives, which we have talked about a
little bit last week. We were lucky enough to have
Donna Jacobson on the show, Senior Product Manager from
Zenergy. And he talked about the fact
that of you know, when he was working on Share Tank, which was
a consumer facing app, not an internal facing app.
If no one wanted it, if if that there were some customer stats
they had to measure and if no one was, if they weren't
reaching those milestones they needed to, then the product
wasn't desirable. People didn't want it.
So you've got to make sure that you know when you've got an
external facing app. It's quite easy to measure in
some ways. If people aren't buying the
product then you've got a problem.
But we don't do the same thing when we do internal facing apps.
So if you're working for a government department or a big
corporation and you're working on an internal project, you need
to apply the same kind of logic. Is this piece of work that I'm
working on you know, worth it? Is it?
Is it something that they really want to invest in relative to
everything else they're doing? And remember, you won't
necessarily know everything else that's happening at the same
time. And by asking that question on a
daily basis, you may even, you know, rattle some cages and
people might get pissed off with you.
So there is a, there is a sense of just and making sure that the
problem you're trying to solve is a problem and the fact that
you're solving it using your solution.
So once you've got the fundamental and sorry, I'll talk
about how that might relate to an agile team, how that relates
to an agile team is that the first user story, the customer
journey, you need to focus on that customer journey, the ideal
customer journey with the highest level epics that need to
be done, the must haves, those have to be delivered.
So you can apply the same scenario in an agile
environment. However, that fundamental
customer journey, the jobs to be done, which may be defined by
your epics, I think the process steps in solving the problem
that you're trying to solve, those ones have to be done.
So don't they have to be prioritized in your backlog.
They are your fundamental study user stories.
So there are some not even if you've got some really cool
features or products or services or things you could do, you have
to do the fundamental ones 1st and actually it does talk about
that in the Angel Manifesto. It we do talk about that and
Scrum, it's got to be the end to end solution you've delivered.
So it doesn't matter necessarily how you've delivered the solving
the problem, but you've solved the problem right.
It may not be an efficient way and you may be able to
continuously improve how you deliver the solution from I
don't know, you may have started off making making it very
manual. As we saw we solved the problem
of increasing water through just adding more people to the the
current process and that solves the problem.
So that's a good place to start and then you might continuously
improve from there. But making sure that you've
solved the problem first, even if it's in a manual way end to
end, is what Agile's supposed to be about, doing that first and
then implementing continuous improvement on top of that.
So I'm not saying you should throw continuous improvement out
the window. You just make sure that your
fundamental footing is there, and that should be what your
high level requirements phase is all about.
So something that's very similar to that, you know, should you
throw it out, you should you continuously improve your way
out of a situation. There's another situation that
you might find yourself in which is very similar.
It's when you get to a position where you're a BA and you've
been asked to, I don't know, change a component within a
system. So maybe you've got you're
working for an organization and they click information, they
survey their customers through SurveyMonkey, and then there's a
process of exporting those results into Excel or CSV.
That information is then sucked into a database through, I don't
know, dropping those files onto a file share.
It's sucked up into a database, And then then there's another
reporting tool that meshes it up with another part of the
database, and you pull out another Excel spreadsheet, and
then that Excel spreadsheet is then dropped or sent to someone
else. And then they suck that into
their reporting server and then they produce a dashboard.
Now that is a one example of something that's very, very
common. You see this all the time with
internal reporting and that journey.
What I've just talked about, you said made it fantastical, but
it's very, very common. Now in that situation, if you're
asked, for example, to change the SurveyMonkey form, the
upfront form with a new technology and new survey
application, you could look at this and go, hey, look, I can do
that. But you know, that's not going
to improve the efficiency of getting the reporting out.
So if your goal is to make sure that it's less tiresome, there's
less people involved, it's less than efficient to get the
information from the survey and the report at the end.
You know that the problem is all the stuff in the middle, the,
you know, the constant exporting of Excel and pulling into
databases and the mashing up and the and all that stuff, All that
data integration and ingestion and processing and
transformation may be necessary. But you know that that's where
the problem here is, That's what needs to be improved.
So you should make that very clear out front that yes, I can
do this component, but just so you know, if your goal is
reporting, this is not necessarily going to solve that.
Yes, it might help us using a new survey talk because there
might be some benefits from it. But ideally your problem is
somewhere in the middle. Now, if that middle bit becomes
so complicated, then what you can do is something called black
box thinking. Okay.
So you need to make this judgment call, and this is
something that I wouldn't suggest you do unless you're in
a very senior position. You've been around the block a
bit. Black boss thinking is when you
don't worry about the middle but you say look the input is a
survey. And we know in this case and
this is this is a. This is an example that we don't
usually have the luxury of saying we know that this
information ends up in a report, you know at another person's
desk who runs the report. Now if that was our only output,
which is what I said, sometimes we don't necessarily know how
information's used and we'd get worried about it.
Then all that middle. But I talked about with the
Excel spreadsheets and the the databases and the input and
output and the the upload from the file share maybe irrelevant.
Maybe to attack that problem we don't need to worry about it.
We black box it and we say, OK, let's ignore that, let's not
even bother doing current state analysis, let's ignore how we
currently do it and keep it running that way.
And in parallel, let's think about a completely blank sheet
of paper. Start again model.
Don't continuously improve what we do, what don't change each of
the components. Don't spend a little time doing
current stat analysis. They should just step back and
go, how would we do this today? And you may even get the people
involved who are doing that job, even if they're invested in it
and you know, they might enjoy that to go, If you were doing
this from scratch, what would you do?
And you might find that the architect, the architecture, and
so therefore include the architect in this discussion,
might say, look, we've got a very easy way.
Do you know that SurveyMonkey or the new tool you're putting in
has out-of-the-box reporting now?
Well, it didn't exist before. It does can actually get a
report straight away. So you've now reduced that
complexity all the way to 1 tool.
Or you know, Power BI can report, can connect, now connect
to SurveyMonkey output, and you can get a report straight away.
And if you want to copy in the data warehouse, then call.
You can also store that and it just gets sucked into the data
warehouse straight from SurveyMonkey and that's it.
So you've completely redesigned the architecture, But if you get
caught up in all the steps and what happens here and here and
here and here, sometimes you shouldn't do that.
Sometimes you should black box it and go and be very clear on
the input and output. That's the hard bit, by the way,
making sure you've defined the input, the process that happens
in the output, and then black box it.
So that's very similar to when should I throw away the product
or and start again or should I continue to improve?
It's also the case when you look on projects that are quite
complex, especially technically complex or go through a lot of
steps. Is it worth doing process
analysis all the way through, or is it best to say, let's look at
what the future status straight away, So it's my top tip for
this week. Now, for those who are
interested, we have a free course on a website called
Introduction to Business Analysis.
It's a free course. It's just going to give you an
overview of what the profession's all about.
You do the course, there's a little quiz there at the end,
and you get a certificate you can share on LinkedIn.
So the course is just giving you an idea about what BA is about
and the proper sense, the word, that's its purpose.
You are not going to learn how to do business analysis from
doing that course. But hopefully you'll have an
idea about what BA is all about. Now if you do that course and
you share that on LinkedIn and tag in the Better Business
Analysis Institute, we've got a page on LinkedIn.
Then we will share with you a coupon for 25% off the Certified
Better Business Analysis Level One course.
And that Certified Better Business Analysis Level One
course is the course that will teach you how and what to do as
a BA. It's not overly expensive.
It covers the cost of our Tudor's time, who review your
assignments, give you feedback and for the material to be
continuously improved. And at the end of that course I
you, you then get a certificate that can be verified, it's
accredited by us and you will be able to, I think call yourself
A/B A and you'll have all the toolkit about how and what to do
at the right time and your journey as a BA.
So if you're interested then please do a free course, post it
and then that will help us spread the word and also we'll
give you 25% discount code to use on the certified Better
Business Analysis course. Okay guys, that's it for this
week and I'll catch you soon.