The Better Business Analysis Institute presence, the Better Business Analysis Podcast with Kenjamin Walsh. Hi everybody, and welcome back to the Better Business Analysis Podcast with Benjamin Walsh. Now we're going to focus on a topic here today, which is actually for some of you your core job or for some of you a job that you would like and for other B. As this is a mindset, it should be a mindset regardless of it's your job or not.
And something that you as ABA, it is part of your remit, it is part of your role. And if you follow the teachings of the Better Business Analysis Institute, it actually relates to one of our phases called release and Operational improvement. And this topic I'm going to broadly call continuous improvement. Actually, we are going to focus on continuous improvement. What does that actually mean? What does that mean for you in your role? What does it mean for you on
your project? What does it mean for operations and all those things? And we're going to bring it together hopefully in a concise, easy to understand podcast episode. What is continuous improvement? What does, what does this continuous mean? Well, if you're from the world or the world of Agile, then a whole lot about Agile and agile delivery is around the continuous nature of running a machine, really a delivery machine, and allowing it to work in a great way.
So that's the that's the whole point of it, which gets feed in basically into a backlog where and the machine starts to do its thing. And off the back of Agile and DevOps, we now use the word continuous, not just in continuous improvement which has been around for a while since the Six Sigma days and and even before that, but we also tag it on to things like continuous delivery and continuous testing and continuous integration. So you know, it is, it is the
word of the day. And so when we can talk about continuous improvement, it's really just making sure that we
are making something better. If you have a product, the best analogy and probably the best use case for an agile delivery team, once you've established a product, which I would argue you know is not an easy job and falls outside of the scope of a delivery cycle, Say you've got a web app which is successful, you've done all the upfront startup things and you're now in a continuous improvement loop of making it better, right.
That's, that's where we can use a a great example of continuous improvement in action where you get customer feedback and you add features and you do AB testing and you know you grow it to target different markets. That for me all in itself is you know, continuous improvement on a product. However, we also can apply the word continuous improvement to look at processes, right. So a process regardless of product is just not operating in an optimal way.
In reality it's usually enough that the there is benefit, more benefit than cost to change what we're doing and that's an important factor there. So not all things not everything will be working perfectly and and actually to be honest perfection I would say is is you know the opposite of progress in some cases. So you know aiming for perfection's it will never come plus the world changes which you can't control hence you know move forward.
However with continuous improvement we talk about the fact that when something has a strong business case and I'm going to use that in a general sense. So it simply that the cost benefit analysis is positive. Say that again in more simple terms that it might sense spending money in time and effort fixing an issue such that you know that the outcome of spending that money in time and effort will be more valuable than what you had before.
OK, so that's simply what we talk about when we mean continuous improvement. Now there are methodologies for doing that. The the analysis we're looking at this process end to end, let's say the easiest example in the examples where continuous improvement was really corporalized was in manufacturing. So you know things like Toyota and the the building of cars and you can imagine it actually helps to have that analogy. It actually helps to have something simple and real.
So you've got to convey about with an order and it's not really focusing on that really. It's really the assembly line which they were focusing on and making sure that they were removing inefficiencies and reducing costs, OK, over the long term. And they there is the concept of lean, the word we've talked about before 6 Sigma, there were, you know, there's there's a whole Kaizen, there's a whole, there's a whole movement which is still with us today.
And a lot of that is aligned with the Agile movement, all for that. But in simple terms, if you don't know anything about those methodologies, I really suggest that you learn about them, that you learn about 6 Sigma specifically in lean. And just read those stories, they're just fascinating, really great in the general sense.
I am a very, very, very, very pro removing waste, which is the word that was used from a process, OK, because it just doesn't benefit anyone and it's not necessary to drive the bottom line or reduce costs or get rid of people's jobs or anything. Any of those outcomes that corporations might be looking for. My I just don't. I just don't like it when there are unnecessary steps that don't benefit anyone and society.
Can be can be one of the people that lose when you spend money, the wrong money in areas which are inefficient where you could be spending them on other areas. So this is not confined to the corporate world. So continuous improvement is around taking a process and looking for initial efficiencies and then you know you really move from a a current state to a future state process in stages, which is important like the
agile cycle. You don't do everything at once because you want to measure that the change you made actually made a difference and you might try things, you might not do them all. So it's not necessary. You've hooked on changing Step 2. You know you you try different things and and and those methodologies have a good way of measuring. They've got different measurables to measure. You know how efficient the process is. OK and where the areas for improvement are.
OK. So that's the that's the bottom line when it comes to continuous improvement, it can get you know, quite scientific actually. Now we bring that up, that's so we don't need to talk about the those particular methodology. You can go and read about them. But in the general sense you're improving a a process that existed continuous improvement.
So we've just said we can improve our product in the sense of agile and you can feedback and make it better and I'd argue that's what product management is all about. You have to make your products better or they will just, they'll just die death, OK. Product management is not about just owning, you know, product ownership or just keeping ownership of the product. You have to improve it over time
or do different things. So you know, you might say Coke, the formula for Coke hasn't changed since they tried some stuff in the 80s, but they do bring out new products. So we've just said Coke 0 now. So they don't don't think for a minute because the base rule product, the actual formula of Coke hasn't changed in a while say let's just say that that's true of their main product which is just the standard Coke.
They are always were looking at improving processes at Coca-Cola, OK. They're reducing costs and selling more moving into other countries distribution, they're a huge distributor. They're actually to be honest that the main part of their business is how to distribute, you know they acquire other other brands. They you know are playing with their their diet range as we've just talked about they know sugar range and how they best do
that. This will continue that there is a constant continuous improvement in Coca-Cola. So don't think don't if you just you know take it at service level might look like some of these products don't change over time. They really do OK and the companies do and they respond to the market. So that's continuous improvement. The product, the company itself and processes which form the the company. And of course there's people,
processes and people. The way to improve people only use a continuous word here is to take a mindset of continuous learning. OK, so continuous learning is really important here. So not only do we have continuous improvement in those areas, to continually improve yourself, you need to learn and you need to adapt and you need to experience. And for you as ABA, this is where this is where the topic becomes more interesting and that is the fact that you have a challenge in your role.
You have a challenge as ABA and that is that the business landscape is continuously, it's changing all the time. OK. So you're you're forced to respond to that. There are cycles, yes, there are cycles and patterns, but the business landscape always changes. There are new tools, methodologies, industry trends that have merged. They merge all the time. If you see any interesting interviews with Elon Musk or Bill Gates, you know and Co, then the question. They always get asked these
questions right. Their first question is what do you think about AI? Or you know, what do you think about machine learning or. Those topics have been on the table for a while. You want to be good at your job. You should be able to talk about these topics. You won't know about all of them.
There are, there are days, every day I will be in a situation where someone might be talking about something that's new that I don't know about, but I have an obligation to go and learn about that and be educated, especially before a workshop where they might be talking about this topic. So that's your job and that's a challenge. Just moving on. That's slightly different from that point apart from new trends and methodologies and industry and waves and we are in a tech evolution.
So we've had the you know the industrial revolution and we have it. We're still in the tech revolution and now we're probably looking at more of AI such a a big term but the idea of I won't call them robots but I I just the idea that some of the task manual ways of working and and and I want to I need to be very careful with my words here but some of the manual ways of working that don't really add value to you, your life your output so they can be done by
anyone. So they're the kind of jobs that you would look to outsource or you know, big corporations would get done in 3rd world countries can be done by robots as opposed to humans and that will totally change. Even if you are worried about other uses of AII can tell you for sure. When it comes to people labor, AI will have a huge impact on that. So you can't ignore it. OK.
Even if you are not worried about some of the higher level uses of AI, the market, the working class market is is going to completely change and and and no I don't believe that it will as Elon or Musk says that it will necessary benefit humanity.
OK, it might get rid of manual tasks that we think are just it's silly that humans do. We'll look back at it and say why are we doing you know merging two articles into one or rewriting an article and they'll say well you know a a computer can do that once you feed in the right algorithm and and methodology and train it. Now that might be true, but the the reality is that what's going to happen is that a lot of people doing low skilled labor jobs which all involve just time
and data entry, they they're not going to do that anymore. They're going to be done by robots and that will have a huge impact on the market as we as we as we move forward. So just take that as a point, write that down, willing to put bet you $20 on that. So there's that. But then there's also the fact that, and and I'm going to use the word value. And I've just talked about an example of, you know, people losing jobs because of AI development. But your job as ABA is to talk
about value. And what part of that is people's, you know, people doing work that's unnecessary and unnecessary is different from work that can be done in a more efficient way. So continuous improvement might be saying, well, this particular task in a factory where the people are kind of taking the doors and attaching them to the car, we've, you know, you've done the analysis and there was a robot that can do that much cheaper, that totally might make
sense. Obviously there's some impact to the employees as a result of that and you know, redistributing that that labor into a better area, like maybe turning that person into a a machine technician or engineer, that might be a best use of time. And I'm as much as you might have a view on an empathy for those people. Your job is to look at the best value, the big, best use of resources in a company. OK. So your job is to stay informed and provide the best value. OK.
So this is all what continuous improvement is about. OK. So, so we've talked about that. So your job is to respond to look at market trends, to keep up to date and to and to kind of keep learning yourself as a person. Now when it comes to things like Scrum, so specifically within an agile team, now you can Scrum agile use it interchangeably. That's a really good example where continuous learning and improvement is built in.
So you do a Sprint retrospective, which is around to look at the team internally, looking at the team what went well, what could be improved, what should be adapted. So I I like that analogy because that's exactly what continuous learning and improvement is about. It fosters that. It's built into the framework. There are what we call empirical process controls. So Scrum is an empirical approach and so we are making decisions on what's observed, not what we think.
And we learn from that throughout the project. So it's kind of the idea of having this kind of, I guess it's iterative approach allows the team that you're working with to learn from successes and failures and refine OK as well as the backlog because refinement is what is built into the backlog grooming. And the fact that your list of requirements that you start with might be quite different at the end in terms of what you plan to do upfront.
And there's a there's a kind of a principle which talks about inspecting and adapting. So Scrum emphasizes the importance of inspecting the current state of a project and then adapting the pro approach based on learnings. OK? And that cycle promotes continuous learning throughout the development process.
So that is how you can incorporate, I guess by looking at the benefits of Scrum, or at least even if you're not in an Agile ish environment and you're working in a more traditional way, you can still do these things. You can have a a retro by looking internally. You can, you know, start to measure things and based on what's observed, like a scientific method, you can inspect and adapt based on what's worked for the last
series of time. You can call them sprints if you want and you also have the concept that within within Scrum Agile is that you are releasing the product and getting feedback. So incorporating and I don't talk about that enough really, but the idea that customer insights are feeding your backlog, not your just your product owner, you know this, it's very soft around that.
But there should be a stronger emphasis which is better I guess explained in product management and we've talked about that before with some great gifts that the customer is feeding back. So ultimately are they buying it, what are they using, what's their features, you know and incorporating things like hot jar on your web app and seeing where they're clicking and improving the user experience or
you know is all is all that. So that's continuous learning and improvement and I don't think you can, I actually don't think you can. If you're looking looking at this higher level of abstraction, like I said, not down in the weeds. I don't think you can actually pull apart continuous learning and improvement.
So continuous learning is is and improvement is kind of locked together what and I guess it's a Venn diagram because you take learnings, you might not do anything with them, but the overlap is where you've you've actually taken learnings and you've improved, right. And you can have continuous improvement which is a bit more random not from learnings just by trying things which is wasteful.
So the true continuous improvement, I would say, OK, so this is, you know, those who have studied 6 Sigma and all the rest of it. For me, true continuous improvement relies on continuous learning, right, And learnings generally. And the overlap you've actually got a reason to look at improving a process, not just trying to improve everything and spending lots of money and then not actually having a better outcome.
So that's important. And then in terms of practical uses of continuous improvement as a whole at the Beta Business Analysis Institute we talk about release and operational improvement at the end of a of a of the kind of journey and you know the the two big topics we we've squeezed them into one and because I think it's really important that you are aware that when you're released it's not done.
So you're looping back and and that all connects quite nicely with Scrum and the idea is you're releasing and then there's usually and the reason we don't collect continuous improvement, we call it operational improvement, is that at some point I guess it's continuous if the program and the project team is still working.
But it's usually an operational team and you need to appreciate that when you're handing over a project which might have all this great continuous improvement culture, continuous learning baked into it, man that that can die at death when it goes to operations. If that isn't the way your operational teams are set up or whether or not that team isn't already an operational team delivering you know the delivery side like you know they're not already a internal delivery
team. So you've got to be really careful about how you hand that over and you need to hand over more than just the project and the product and the insights and the documentation as we always see and the and the training guides. You need to hand over the culture that actually this is, this is how we do it. So you know in a product, true product management shop that is all done because it's baked into the fact that product's going to be there for the end of its life.
Having product teams and the operational area is is OK. I I think they need my personal preferences. They're one and the same as the project team, overarching, and they're involved in change. Not like true change, big changes, not just tweaks to the product. But as we talk about at the institute, release and operational management of the product or service really contributes to the betterment of of the product, right. It it it contributes to how you do that.
Sorry, I guess how you do that is a is a hugely important step and we need to kind of think about things like release planning, you know what does that mean in terms of the the risks that we have on the project. When you think about how we test it continuous, I guess quality assurance and continuous testing maybe our acceptance criteria, change management, benefits realization and then and then
right. So we can think about all these things when we do release management and then of course we're thinking about OK, well when this does go over to the operational teams, we need to collaborate with them to look at ways in which we can actually establish process optimization
after the fact. So it is not even though we've got these continuous improvement and learning processes within the project, it is not the product team or deliveries job to make it the most optimal process, right, The not to loop around the most optimal process when delivering their product. I'll say that another way, the goals of the project, the delivery, the production, let's say it's a new product, There is usually nothing written into the objectives.
There's nothing in the business case or the link canvas. There's nothing that says and and in some ways I'll justify why that you need to make sure that the process is the most efficient, quite the opposite by delivering something very quickly and by focusing on the user stories within the job to be done to get the result and focusing on where the customer we're going to get the biggest value, value driven. That's the whole point in releasing a product to the
market, focus on the value. You are actually maybe flying in the face of process optimization. OK. So we're just going to be really careful here. We've talked about before that you know a project might spin up which is literally taking an existing process and we may be trying to improve it, OK. And that generates a project, right. That's that's that's one way of looking at, that's one angle Now in the in the kind of situation where you're talking about a
product, right. And and probably the same for people by the way, it's not always you know, the most optimal situation for them to be in and we'll come back to that. But in regards to a product, that isn't the goal, the goal
isn't necessary. Making sure that every single process step that a customer goes through to interact with your product or your back end processing or the way you support it or even the kit it runs on, none of that, none of that journey is focused on making sure that that is the most efficient process step. I would say it's the opposite.
It is the most. It's usually the most MacGyver way you can do it. Now hopefully, if you're this is a scalable product, you've baked in, You've taught, you've thought about technical debt From a technical point of view, you've got architects, business architects.
Thinking about how this might long after the product is in market, you've already thought about how it can be integrated with the rest of the ecosystem and you've even baked into the project plan or the program or the operational support budget. This is, this is the trick. So if you're in the situation do this, I always say don't process optimize, OK. So I'm going to say, OK, sorry, sorry, let me rewind.
If the project is kicked off to improve a process, so you're moving a process that's paper based into a system or another system into a new system, you will probably do some process improvement. That's how you generate your requirements. You know what doesn't work today? You won't just simply lift and shift that process into a product. So there's that side of it. OK, Making it better, OK, that's
fine. But now you've got that process inside a new product and the combination of process and product there might be more efficiency sees with the way you use use the product now to fulfill those processes. So at more down at the procedure level, OK. And that level don't try and optimize that at the same time don't fully optimize that process. You will improve it by nature of moving to the to the new
product. The BA will work with you and work out better ways of doing things and new UX, but you won't really know. You won't really know where to put your money improving that process right until people are using the new product. Not at the procedure level, not the low when I say that it's a lower process level. Once you use the product, you might start using new features that you didn't know existed before, and you might start optimizing things like screens. OK.
And that is a different lens. That is a different lens. Continuous improvement at that point is a different lens. It's optimizing every single step. And that's very hard to do if you don't know what the solution's going to be. OK. So like I said, you can do that with an existing product. You can do that even at a high level process point of view.
But when you're and you can actually do that the procedure level, all I'm saying is that if you're going to do a project like where you're moving a process you've improved it, you put into a new kit, the best time to do real process optimization is about 3 months after you've released. And there's something you should think about. Don't try and intertwine those two things.
They're quite different. Even the skill set you need the focus, you know, the fact that you don't really understand the product, what you'll know after three months of using the product with the process, the improved process probably that you've put into the system, That's the point in using it is you'll actually start to get some facts about how people are using it, OK. And it's it's that's a corporate example, that's an internal example like moving to a new CRM
system. But it's the same methodology is all about, well, you don't know what to change in your product until you release it to the market. So when we talk about public facing products, you actually don't know what you should change until you've got customer feedback on it. Once the product's established,
it's exactly the same. We're moving to a new internal system like a moving to a new CRM system or ERP is that you can prove it to a certain degree, but you you know upfront process improvement, but you won't be able to do procedural improvement or low level process improvement until people have used the product. I hope that's clear.
But when you do do process optimization, which is the series I'm talking about, real continuous improvement, you're starting to look at things like automation opportunities, workflow enhancements, data-driven recommendations and customer feedback. So all of those four factors are feeding in and and that changes the focus of the project to be more operational in my mind, right.
Not only people using new product, you know the new if you've got a brand new product, customers using it or you're, you know using an internal product and your users are using it. All of those things, you can actually have a different lens on the project after the fact and it will save you money because you'll be spending money in the right place if you do it after you've done the initial
implementation. What I'm not saying is don't you know don't do any improvement upfront, just do the big things. OK, cool. So we've got the, I think we've ascertained that continuous improvement and continuous learning overlapped and some of our project processes are baked in for that. And we've just talked about the fact that at the Better Business Analysis Institute, we think about those things both in release and operational improvement, OK, which is one of the stages of the delivery
journey. We're doing continuous improvement and continuous learning throughout where it's a that's a consistent mindset that we're applying just across our organization regardless of team. But we are specifically saying that when you go from release into the operational teams which are probably going to be different.
We then have a specific phase and a specific lens that we are now putting across our product and our service that is both like we said to get the best bang for buck in terms of where we spend money based on customer feedback that you're learning know and user feedback once they've used the product. But we're also not just talking about that, We're also talking about the fact that our organization, we need to think about how our product and our processes fit within the
organization. And I'll give you an example there. So if your large corporate is getting into a new business, let's say that your telecoms company, so telecommunications company that just does mobile phones very much a commodity company, decides that this is not much different to selling electricity, OK, Also a commodity that people need these days. So you need your mobile in some kind of messaging and you need electricity, OK. That's just the developing
world, that kind of necessities. Now they have sourced electricity from a from a generator and they're just going to sell it, right. They're going to do some kind of wholesale agreement and they're going to sell it, start packaging it together. Now all the processes that are needed to support that new business stream, new product, new service, one on the same that might exist outside of the organization right now because it's just in a product team's
idea. And they're thinking about things like building an interface and things like, I guess, buy like how they're going to purchase this, how they're going to manage managing meters and homes because they are now a retailer. And so they need to worry about all those things. They're worried about disconnection, They're worried about customer services.
So this whole business model, well, let's just call that the program or the project and the organization doesn't have all that infrastructure set up. So as part of that project, ideally, you've got phases, you've got sprints thinking about that that's baked into the project. But that's why we have a specific phase delivery phase called release and operational improvement. It's not just around improving the product, making it better.
It's also about the organization's ability to respond to that new product or service, OK. And it's around setting those things up, change management, BAS may be involved in organizational structures even fitting into that that probably the best people to place placed on the project to go well, actually there's three or four new processes. What teams do you have today?
There's a gap, capability gap and identifying that maybe you know that you're introducing new services like quite different to what you've got in your new team. So if we take a telecoms company, they probably already have a call center. They probably already got customer acquisition. They're probably already actually even clearer around connections and disconnections.
So you might think, well those processes, think about it for a minute, they'll integrate with those tanks that do that today, right. We might need new personnel, more staff and more training, but they kind of fit. But then equally you might have a process which is very specific to the electricity market. Maybe it's, I don't know how you the charge, how you charge the complex complexity around charging or you know maybe that just goes to the finance team.
But there might be, there will be elements which are unique to the electricity market and you don't necessarily have a team in which you're going to hand that over to, right. You don't just hand over the the box that is the project, you hand over processes that have changed.
So you need to create that. So this is what this phase is all about and the reason I bring this up and you could say this is you're going off on a bit of a tangent here and I I am specifically to say that that is you need to worry about all that stuff, right? That is for me still the scope of continuous improvement and learning. It's not just about the project or the product or the services, about the people and the organization responding to that
after the fact. And if you don't worry about those things, if you ignore those things and you just focus on your project and say they'll just take care of themselves or wow, the operational team needs to get used to that, they're busy. They're doing BAU. They they've got enough time for this. This is your job. This is your project team's job.
If you don't think about that and you ignore that, then all that continuous improvement you've made throughout your projects phase and all the great BA work you've done to improve the process, it's all Nutter. It's all it means. It can mean nothing. It can mean nothing if it's not fully embraced and recognized by the organization. And it's not just them accepting it like a, you know, throwing a baseball and then catching it or whatever. And other analogy you want to use.
You know, they need to prepare, They need to have the Met, They need to know how to play the game, and you need to do that as part of your program. OK. You as ABA are critical in that. So the final point I guess I want to make around continuous improvement in learning and and why I'm stressing, it's so important and needs to be baked
into your project, your mindset. The four PS that I've talked about with you know people and processes and products right and projects is that you also have 222 other kind of aspects here you have the continuous learning from the project team itself by sharing that knowledge. This relates to the last point I just made around having knowledge sharing sessions.
This is where you're this is the way in which you are doing what I would say the greater change management, change management plus plus where you encouraging members of your team to or expertise in the in the team to cross pollinate that knowledge that you've learnt to the organization. You can talk about what you've found. You know you're in a lucky spot. You are. In some ways, the operational teams can get jealous of this.
And this can happen, especially if the team that's working on the project as a contractor or consultant. You know there can be jealousy here, so you need to share your knowledge. Your job is not to retain that knowledge. If you are a contractor or a consultant, your job is to empower and leave the organization better than you found it. You can have brown paper bag lunches.
You can have lunch breaks and formal presentations, talk about new topics, industry trends, lessons learnt, what's going on in your project and updates something fun demoing back to them. You can also like integrate operational members into your team. So this is all about continuous improvement and learning. It's about the people side by maybe pairing up a team member
with a less experienced person. Sometimes you know you might have a senior programmer in your team and they're working with a junior and you know they can't afford to pay the best wages for internal staff. So you end up with a junior there and you know your job is to transfer that.
That can be quite rewarding. There's also around the fact that you could even this is this happens infrequently but I I've recently been involved in this where we're encouraging the BAU operational team to have a learning budget right. And because you're you're on the project so you're working with a product let's say you're just integrating off the shelf
product. So some product that you've just as part of the project you've integrated or put in a product and someone's going to look after that and you find out because you know how's the operational team because they know about it. You're the one who's worked out that it's going to fit and you've done all the the work in terms of requirement management and your architects worked out technically, it's it's nice and you and you've your projects
worked on it. And as part of that learning you pick up that the certification for learning how to use this product is cheap, right. It has certifications, it has learnings, it has conferences. Salesforce would be an example. Dynamics 365 would be an example. There's a whole ecosystem around these products.
And so you can maybe suggest to the team that you might be handing it over to or your SME team that, you know, your project manager could do this, that they need, that this is how much it costs to get educated in this area. And so as part of your project, you could put out some of these recommendations that people get trained in these tools. And so they're ready. Like I said, they've got the mat, they're ready to catch the ball.
You could also suggest there's some learning time for them and you could do a bit of a, you know, a bit of a playback session to that team. So I think there's, there's some good ways in which you can help with operational improvement or continuous improvement in learning for the organization outside of the project team that you're working on, OK. You know, allowing them to be involved a bit more, sharing, you know, you're fostering this continuous learning in a kind of
collaborative way. I think that's really great. So there's that aspect, right. And then finally there's the aspect about yourself, OK, we talked about like learning, keeping ahead of business acumen and soft skill development. Well, not not so much on soft skill development but industry trends and how you can provide value but and emerging
technologies. But one of the things that I think that you could do as ABA and I touched on it there with the soft skills kind of gave it away is just making sure that you are continually learning yourself, OK about your own tools, techniques, processes, you, you as a human also, which I you know not very good at, there are things that you could learn to be better with soft skills.
So getting certifications, courses, micro credits, listening to this podcast, you know, going on to our website, reading articles about BA, going to conferences, all of that is continuous learning and improvement of yourself. So I'm going to suggest that you find one area where you can add or improve yourself 1%. So it might be going for a walk, you know, not drinking as much, taking some time out, sleeping in, you know, it doesn't have to be anything big.
It's your list, it's you. But improve yourself by 1%. If you do that every day, then you know it's just like interest. You'll end up in a much better place than you are today. So I think it's really important that you do focus on improving yourself.
What it allows you to do, and the reason why it's good as BA to do this exercise, is that by having a mindset of continuous improvement on yourself, you're able to find and look for and recognize continuous improvement opportunities in a business and just in life generally. So I'll leave you with that action, which is to continuously improve one area of your life by 1% every day, and I'll see you on the next episode.