The Better Business Analysis Institute presence, the Better
Business Analysis Podcast with Hi everybody, and welcome to
this week's episode of The Better Business Analysis Podcast
with Benjamin Walsh. Now, in the last couple of
episodes and across the series, we've been talking about a
couple of. The dimensions one is the people
dimension like the last episode around the experience
ecosystems, that's where people play, that's where customers
live. And I like to talk about the 4P
plus model. So people process projects and
products which then feedback to our people who use those
products and services. And so you can think of those
those P's in a in a quadrant of you know, people on the left
top. Moving over to the top right
which is process and moving down to the project in which that
process is changed within or hypothesized to be changed and
then to the bottom left which is the product service that we are
tweaking or changing or adding to you know to the customer's
experience. And then back that flips around
and is delivered to people who use it and then we go around in
circles. So that's the brief discussion
around the four P plus model when you think about the job
roles that make up. Those different dimensions I've
talked about the fact that not only are there different job
roles that play best in those quadrants, the almost thinking
has developed from those quadrants.
So you could think about the fact that in the people
quadrant, human centered design, design thinking.
Empathy mapping, customer journey mapping, customer
experience ecosystem I talked about in the last episode has
really all in the people's space.
It's about understanding your customers.
Being customer centric is a word we use to describe that.
The only problem we're talking about customers per se is that
it always themes externally facing when we talk about that.
And you could have users which are internal users of systems
and they could be just as important.
So I like to use the word people to describe anyone who's using
the service or product. If you then move to the right
hand side, you then get to processes.
I've had lots of debates with very clever Bas who in some
places they're better than me and other places I can teach
them that. Why is it that processes come
after people don't Processes live within a project and I
would have to say that most Bas that is their experience they
project to spun up. The first thing they do is
current state and future state analysis.
Work out the gaps and to come up with some requirements for me in
a in the world we live in. And I've talked about this in a
previous episode, so I'm not going to go on about it too
much. When people interact with
things, we call those processes and it's really important to do
upfront process modeling in order for you to get your scope.
So I would argue the process of problem analysis, identifying
the right pain points. Doing a link canvas potentially
or a business model canvas all lives in this space.
You could argue from a project point of view it may be pre
implementation business case before you were even thinking
about the solution or even decided on the architecture Bas
that's where I think. Better Ba's play, it's all, or
at least that is where their goal and intent should be,
because it's where the biggest value is.
If you are everything that happens before a project is
conceived, a project is usually constrained because it's a
condition, it's an experiment and it and it has an output.
It's quite constrained, but before that you start having
some of those really valuable. Objective level conversations
about what you're changing and what actually should even be the
scope of the piece of work you've focused on or planning.
Many Bas don't get to experience that.
But when you get to program level business analysis,
enterprise and strategic level analysis, you start to see this.
You start to understand that this is really important.
So I'm not saying you know if you're working on a project and
you're an intermediate, intermediate BA working on you,
but. Do you bit, but it's important
to understand these concepts and understand where the true value
is of business analysis with again with an emphasis on
business. So if I was trying to connect
that dot with the last episode with the experienced ecosystem
or people, obviously the that's a huge influence in terms of
what what we might think is important for our business is
the customers and this people that we serve.
So for me that's almost 80% of anything we do.
We should be thinking of the desirability and the impact to
them and that's really where we might do our benefits for
realization. And if you're doing investment
logic mapping for all government departments, then that would be
where you would map out what the.
Investment case was for making a change to something for a
government department for example if you were getting
funding through the treasury Better Business case process.
So there's the people element and then the the other the other
side of course or at least you know I did say 8020 but it might
be 5050 is your your business and the processes that your
business need in order to run a successful business.
Most companies and we've talked, we talk about processes often at
that level 0 and level one process hierarchy step.
There are common business processes that each industry
carries out. So if you look up the APQC
model, you'll know what I'm talking about if you know
anything about it. So you can divide those
processes into pretty common chunks that need to be done by
businesses. And this is what I'm talking
about with this upfront process analysis when it comes to making
a change. Before you spend money on a
solution and get down to your current or future state solution
processes or even the project itself, the real project proper,
you should really understand where in the business you're
making this change or where in the customer journey you're
making this change and and what that and how that maps down to
the internal business processes. The processes live there, and
for me this whole quadrant is BA owned, driven by BAS.
We are by far the people to grab that quadrant and to elaborate
the tools and techniques in that space.
And a lot of those tools and techniques can be borrowed from
things like. Process hierarchy, 6 Sigma
rolling up even in an MBA and some of the external factors
that we need to consider when we're doing proper business
analysis with a capital B. You then after you've you've
done that step of course you moved down into scoping a
project and I have, I've said this before in the Lane Startup
podcast and previously with the 4P Plus model.
The project doesn't have to. It's project in the in the
loosest sense of the word. This could be a feasibility
study. This could be a proper lean
startup. This could be a hypothesis test.
This could be all the good things that product managers
understand too. It's the same world that product
managers talk about and project managers talk about.
So project managers typically in a more of a structured
environment when they're managing risk very much.
Very much so. In the public service where you
know you do a business case, link canvas in the equivalent of
startup. Once you get bigger, then you do
a project and you do a business case and you might have a stage
business case as you go through. And if you've done your prints
too or PMI certifications, then you will understand that
projects have a certain way of working and you know we should
adopt that. And this area is really much, I
would say owned by project managers.
Project managers are very much. Own this quadrant and they
understand how to set up projects for success.
In saying that, a typical, say, government program manager may
not be the right fit for a startup company.
That's very lean and proper, but but there is the same methods.
It's just a rapid prototyping and product managers are really
good in this realm. So if you're in a product world
and you've just got a product, you might lean on that.
Set of processes which are well defined.
Or you might be a project manager and that's why you have
conflict between the two when you've got various different
methodologies happening at the same time and no clear ownership
around how you drive product change.
So that's an interesting topic in itself, but you know they do
play in the similar vein and a product manager though is more
well I would say more closely related to some of the skills
that a BA has, whereas a project manager which is creative and
empathy driven and project manager is more risk driven in
task management. So yeah, it is an interesting
space and you usually find that when multiple like you know they
say a company's gone agile or they've gone product and then
you've got these waterfall projects, you've got these
traditional project management. PMI officers usually find this
conflict because it's not really clear which leans you're looking
at. Now I that's a huge, yeah, I can
debate about that for hours. Let's just say that they they're
both valid and they're just different ways of looking at the
world. Then in the final quadrant, we
we really have the product world and it is fair to say that you
as a BA have experienced this world when you've experienced an
Agile Scrum project, an Agile Scrum project and in the sense
of Agile delivery, this is what this is what has come into our
world as being a new way of really managing efficient
delivery teams. And it's from the world of
product management. That's where it's come from.
So in this space, this is really where Agile delivery owns this.
And you could argue a Scrum Master or your Product owner
owns this bit. So what does that mean for Bas?
Well, it means that we are subservient to those roles if
we're playing in that space. This is where lots of Bas play.
They play in the delivery side, they play in.
Once the project's been scoped, they plan this space.
Can we add value? Yes we can, because we can do
our current state and see what the gaps are.
And if it's not a product then it's even more useful to be able
to do that. In terms of the services, which
aren't generally well changed through a Scrum environment, it
could be using Scrum teams, but it's not, you know, you're not
using, you're not working with developers per se.
So that whole area Bas can add huge value in terms of adding
the. The process view, the managed
requirements, but this is where we overlap with product owners
because this is their space there in the this is really
where they, I would say own this space.
These days Bas can play the role of a Product Owner and probably
do a better job because we're skilled in how to get
requirements. But this is really where I would
say Bas need to move from. So for me the the, the value for
the Bas, you know for I'm talking about a senior plus here
is outside of that. So that might be where you start
your journey and you move over to this pre project phase as you
mature. There are other types of Bas as
I've said a product manager for example is almost a type of BA
and that. Roduct kind of space joining
product all the way U to customer vision.
So they kind of play around that, but they don't get down to
the detail. Obviously there's the the
product owner role. And then there's of course the
people that need to help with the delivery, who are
specialists now that Bas, some Bas have moved into like data
analysts for example, or process model modelers who work down at
the solution mode or technical Bas we call them, they work in,
they will work in this space. So it's a really interesting
model, the full P plus model. I talk about it often and the
reason why I've just regurgitated and gone over that
is I really want. To make it a little bit more
real, the pre project, well those Bas, those Bas who are
listening, who don't have never played in that space and may be
interested in knowing why they would say why.
I think that's the destination for Bas.
The probably the area that you have touched on or you know
about as part of your job is problem statements.
Now the problem statement is where you define what the
problem actually is. And I would argue you do not
start a project until you know what the problem is.
A lot of people think that a lot of people when you start a
project, they've already come up with the solution, especially if
it's technology driven. So it's to put in a new CRM
system. It's not that we have a problem,
you know, having a central viewable like customer
interactions that might be the problem.
So you end up starting projects incorrectly and you end up not
being able to prioritize your requirements because you haven't
really got any yardstick to measure whether or not this is
going to improve anything or is more important than anything
else because there is no measure of success.
Benchmark put in the CRM system is very black and white.
You don't have any objectives. You haven't defined what the
problem is, so how do you know which features are more
important than others? So this is the important factor
of defining what the problem is. And in order to define a
problem, there are lots of techniques for doing that, and
here I guess two ways. One is to find out what the root
root cause of the problem is once you know what it is and we
can use the five why's to do that.
That is simply the technique of asking the question why five
times. Again and again until we get
down to what the root causes, we can use the Fishbone diagram,
which is the effectively the same outcome of finding out what
the root cause of a a problem is.
So that is just if you if you don't know what it is, please
please Google it. Please understand what it is.
It's like a child asking, OK well.
This isn't working or what happened in the movie is usually
the the question you always get and it's like, oh, that man just
died. Why?
Oh, and you, you know you get you, you you pause the movie if
you're at home and you say, well, he died because he was a
spy and he's like, oh, why? Well, he was working for the
Russians and the American guy shot him.
Why Russian America don't particularly like each other
during that period. And so spies were around, and
they were like secret agents that worked for one side or the
other. And, you know, they were, they
were stealing secrets. So they needed to get rid of the
spy so he didn't steal some of their secrets and take it back
to their home country. That's nice.
Why? Wow, they stole secrets.
Then they might know their plans when they go to war.
And so the idea is, if you ask the question why five times on
the same topic. And it can be a little bit
repetitive, but it is really important and you actually get
down to why, you know in that example why the man was killed.
But why was the spy killed? Because he was killed because
there was a chance that he had intelligence that could have
been used for creating. Or a demand during the Cold War,
for example. And so this is it sounds really
really simple. And it sounds even silly when
you explain it, but I would be amazed if every single one of
you bas went to your product. Manager or your product owner or
your sorry or even project manager or your sponsor and ask
why they were doing this piece of work.
And I I'm sure you'll get answers like because it's in our
plan for the year or because we're implementing a new cerium
system so it will be better. And and I I think you would find
that a lot of them would struggle to articulate the real
root cause for why you're doing something.
You usually find that a lot of these reasons can if you go
through this. Technique.
It could be because the IT manager wanted to do this.
That's simply the reason you're doing it.
One reason could be that it's a new piece of technology that you
want to try and that it starts to really drip away some of the
fluff statements that may have existed and makes your life
easier. Even if you might not expose
that you know in documentation, you know why you're really doing
this piece of work and. So that's the five Y's.
You can do this a similar technique using a fishbone
diagram. You can Google that.
It's really the same purpose is to figure out what the root
causes of of a particular problem.
Now one of the techniques I use, instead of asking someone five
times why is I use the technique of the five W's.
Not to be confused with the five Y's, 5 W's plus the two H's.
And the reason I like this template, which we have a
template online at the Better Business Analysis Institute,
you're welcome to request that we use this technique and we, we
think it's the best. And the reason, the reason why
is because it encompasses effectively the business case on
a page. So it's the most closely related
to a business case on a page. And that is why you're doing
this. You're defining this particular,
you know. The elaboration of a product
problem statement using the 5H5 W's and two H's to find out a
bit more around the problem. Not just the problem, but what
how much you're willing to pay to fix this problem.
And So what we the questions we ask the W's are the simple why
we start with the why. Thanks Simon.
You talk about what you're going to do, you talk about where
you're going to do it and where isn't.
People get confused about this and say, Oh well, I'm going to
be doing it in New York now. Where should relate to those
higher level processes? Where in the organizational
highest level processes and where in the customer journey
potentially are you making the change?
OK, that's really, really important.
Most Bas get it wrong top tip. That is what you're filling in
for the where you're talking about when.
When does this occur? How often is it a regular thing
you're fixing? When talks about frequency, When
talks about when something is triggered.
So you need to think about properly, not just you know in
March is not a valid answer here.
So we've got the why, the what, the where, the the when, and
then The Who. Who is this problem affecting?
Not you're not writing down the business sponsors name here.
You're writing down who has the issue.
Who is this problem affecting the direct person that's
affecting? Not Samantha from accounts
necessarily. Unless you're putting in a new
accounting system and you are hoping to get rid of Samantha,
you know The Who wouldn't be an individual in that sense.
It could be the end customer, it could be.
It could be this whole problem could have been sparked from
insights that you've measured about your customer.
Customer insights should be driving a lot of the problems
that you have. So it's customer driven.
So you would, if it was driven by customer insights, you would
know where the problem was occurring because it would be
somewhere in the customer journey.
You would understand who because it would be your customer, you
would understand the frequency, you'd probably understand who in
terms of numbers as well like how many.
Would be really important and and you could start to define
this problem. So if you if you're an advanced
company in terms of using customer analytics and really
customer focused and you're at a higher level of maturity this
will all and your product company.
This will all be driven by your customer the you know the
problem statements drop out customer insights.
So that's really interesting space in itself and I'll get a
friend of mine to come on board who's a senior product manager
to have a bit of a chat around how you.
Make that happen. So that's that side of it.
And the other two H's is now. So how you might solve this
problem in a real theoretical conceptual way might be to
replace technology, it might be to introduce new capability and
so on. And then the final question is
how much? How much?
Dollars are always good or time as well and energy or resources
would it take in order to solve this problem.
And if you can define that on A1 pager like the template we use
then you have you as a BI should be able to do that.
And for me that's more in the enterprise analysis space pre
project and you're working with the project manager.
And then the project manager who isn't necessarily taught and
trained in these techniques or even the best person to have
those conversations, you've just provided them with the outline
of their business case. OK, so I've given a bit of a
background about where this fits.
This fits before projects in this enterprise analysis space,
in the in the process space and problems.
That's where problems are identified and that's why we do
projects. So problems may only be
identified at a very high level and your job as a BA.
If you want to like get ahead and get to that senior level or
just be a bit of senior BA, then start to define your problem
statements effectively like I've just described.