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.