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.