Tēnā koutou katoa. Welcome, welcome, welcome to today's webinar, which is about how you can use continuous improvement to transform your organisation to improve efficiency, productivity, get better customer outcomes, better quality, better staff experiences. It's going to be awesome.
This webinar is brought to you by Allen & Clark, a consultancy which really gives a damn about making a positive impact to communities throughout Aotearoa, Australia and the Pacific. My name is Jeremy Markham. I'm a senior consultant at Allen & Clark.
My expertise includes continuous improvement, surprise, surprise, but also other areas like business process design, change management, benefits management and frontline operations management. But today with me is the real star of the show, my friend Darcy Melsop. So Darcy Melsop is an absolute continuous improvement guru.
He has been serving organisations for about 20 years through his company CI Lab. He's the author of the book Unleashing the Improvement Mindset, and I'm delighted to have you here. Do you just want to say something to the audience, just a little bit about who you are, your book, your business? Yeah, look, thank you so much, Jeremy, and thanks for having me here.
I'll talk about my business in terms of context of what we're going to cover off today. So CI Lab is all about building capability in teams. So for leaders in teams that believe in building the capability of their team will lead to substantive performance improvements, then this is the area for them.
So what we do is we focus on building that capability within teams, but also helping them unleash that capability. And part of that unleashing the capability is the how. How do we embed it in our culture? And that's something I know we're going to focus on today.
And that was a point of focus on the book, because there's a lot of improvement methodologies out there, but it's about how do organisations best adopt them. So there's the book to help with the how, there's also us, and yeah, we focus on building that capability within teams. Yeah, look, I think we're going to demonstrate it later, but it's an AI version of the book.
So any questions you have, which you usually go to the book to help, it will help you. It means you can ask questions that are a little bit more complicated than you'd expect to see in something like an index looking things up. Ask a complicated question about the next step, and the AI tool will help you through depending on where you are in the process.
But we'll talk about that a little bit later. It's a great tool. I've had a really good play myself.
Oh, thanks, mate. Yeah, no, it's good. So today, just so people know, we're going to talk about the real world impact of CI.
We're going to talk about some practical advice around implementation. And we're going to talk about artificial intelligence. And we will have a little bit of time for some questions at the end.
So please use the chat to add some questions in there. And we can look at them a little bit later. Just to kick us off before we get into it, CI, so continuous improvement is the disciplined application of tools and methods that enables individuals, teams and organisations to understand their current performance and make systematic changes, improvements over time.
So it's about making those iterative and sustained improvements over time. And as we're about to find out, they can accumulate to be quite significant. But before we get into that, what I want to do is I want to run a poll.
Fantastic, find out where the team's at. Yeah, so let's see where everyone's at out there. So on your screen, you should see a poll popping up.
And the question is, how well is continuous improvement embedded in your organisation? So we've got a four point scale there. We've got one, which is very low. So people are going, what CI? I don't even know.
Low is, we've got a few examples, there's a few pockets of success, but there's nothing structured. Number three is people understand it, they get it, we've got a structure. And it seems to be working pretty well.
But very high is it's absolutely core, it's integrated into the way we work is delivering consistent results. So if you're able to answer that, I can see on the screen. What do you think Darcy, it's about to finish up.
I laughed when you said very low, only because continuous improvement is relatively new still in Australasia, in both Australia and New Zealand. When we look at the lean discipline, well entrenched in Asia, we have Six Sigma, well entrenched in North America, and Europe has adopted the continuous improvement mindset for the best part of 60 years, certainly after the Second World War. So yeah, look, I'm thinking I'm really interested to see how that maturity is filtered through and emanated through to New Zealand.
If I was to guess, I'd say a lot of us about one or two still, and there's no embarrassment in saying that it is still quite new. How are we looking? Yeah, I'll tell you, and I should say, you know, in a country where we're talking about how to improve our productivity. Yeah, that's what this is all about.
Okay, so looking so well, the first thing I'd say is that no one said very high. But not surprisingly, we had 71% coming out as low. So that was clearly, that's pretty low.
That's the two? Yeah, that's number two. That's a few examples, but we don't have a structured approach. And the other two are very close on 14% each.
So thanks for that. It gives us a good understanding of where everyone is at. Surprised to hear that, and quite heartened in a way that many have made a start.
Yeah, no, no, it's good. So hey, let's kick us off. Let's talk a little bit about the value of CI, and let's talk about it through a practical example.
Yeah, I think what we're talking to here is the why. Why are we doing CI? And we'll get into the how in a moment. And there's no better way, I think, than sharing the experience of Hutt City Council, who for me, an exemplar example of an organisation that has adopted properly, continuous improvement.
Look, the challenges that Hutt City Council faced, and some watching today will know about those because they've reached the media, are the same challenges almost all organisations face. Differences, Hutt City Council did something substantively good about it. So let's paint the picture of the before.
This is not where they are now. They've come a long way. But when we look at the before photo or the before scenario, yeah, I love before and after photos.
They show so much of a difference, but you can imagine, right? So if we're talking about the resource consents process, you can imagine that there is a cure of resource consents waiting to be worked on. Worked on by a team that was over capacity, overworked, doing more hours than they probably should have, but that showed the dedicated nature of the team. The team were dealing with some technological issues that were a bit aged, but certainly the process itself was too old, too aged, hadn't been adapted, and a lot of rework in the process where they were receiving applications and many of the applications, over 80%, they had to go back to the customer to ask for more information to be able to process it.
And that rework loop would often take about two weeks for the customer to come back with extra information. Again, a lot of organisations experienced the same sort of thing, but just painting you the picture of what Hutt City Council were experiencing. Yeah, absolutely.
And I know that, yeah, you're right, a lot of those things you were talking about are really, really common problems. So what were you able to do? Okay, so with them applying the continuous improvement and starting to entrench it into their culture, the results they experienced was this. Firstly, they have a time limit for which they need to process the applications.
They were meeting that time limit 42% of the time. Now, it's sitting over 97% of the time. The queue of resource applications, that they have resource consent applications, was month on month over 200.
After the continuous improvement initiative, they got it down to zero, meaning as soon as an application came in, it went straight to the team. Now, they've done such a good job embedding it, it's still zero today. Nine months later, nine months later, they've embedded it properly.
Staff turnover went from 140% in a 12-month period to 6% in an 18-month period. Again, showing you how it got embedded, freeing up a lot of the team's capacity. No longer working the 50-hour weeks, getting much closer in less than the 40-hour weeks.
And as bonuses, because they adopted continuous improvement properly, which means measuring your process, they had a whole bunch of new measures of performance that showed the team how things were going, so they could make informed decisions. But also leadership, for the first time, had a really rich view of how things were going. And that helped with forecasting modelling.
And the last point I'll leave you with, in terms of the success story, is because they embedded, they did the right thing. They started by building the capability. And because they embedded it in the resource consents team and got the wins, they were able to reuse that capability for building consents and inspections.
And they had the same sort of results in those areas as well. And that's what it's all about, embedding the capability in the team. Fantastic.
Yeah, that's great, Darcy. Yeah, a real success story. They've done it the right way.
And we'll talk today, now in the session, about what that right way looks like. Yeah, no, great. So, wow, there's so many things you can talk about.
So I said before, it was great that you talked about some of the common problems. One of the things I've noticed is that you can go into it knowing that you need to fix the process and there's some problems, but when you get under the hood, there's more. There's always more.
Yeah, so there's usually, the opportunity is almost always bigger than you first think it is. That's a key message I would have about this. And also the benefits are really substantial.
Some people, they put CI in a box, or they have a mental model which says, oh, that's just, you know, maybe that's little. But the power of the cumulative, 42% to 97%, massive, 140% to 6%. Those are not tiny changes.
That's quite transformative at the process level, right? Yeah, no, absolutely. And I do baulk when I hear people talk about, you know, continuous improvement might be tinkering. It's transformative change, but it's doing it the right way, investing in the team.
And just leveraging the power of the team. So all the solutions that were developed in Hutt City Council were developed, not by me, but by the team in the work, once we built that capability. But the point you were making, it's right on the money.
We're talking substantive changes to make life easier for the team and the customer. That's it, making life easier for the team and the customer. That's what continuous improvement's about.
Yeah, no, that's awesome, man. It's so good to hear. And I guess for some people in the audience listening, they might kind of go, that sounds great, but I don't know if I can do that.
And so I think one of the other key messages I want to get across is that CI can be scaled. And no matter where you're at in the journey, and no matter how much you think you have scope to improve, there's always something you can do to start your journey. When I was a manager embedding CI, you know, we didn't have really a budget.
It was all just within the, you know, the BAU time, but we carved out time and we saw some great results. So that's awesome. And you've got some thoughts about that too.
Yeah, look, it's great that example you just shared, because I know from my experience in the 20 years that I've been doing this is 80% of the changes that people can make, 80% of the improvements are what I'll call behavioural level. So that's either supporting the customer or reducing rework or cross-team collaboration between teams, which means there's no capital outlay for IT. You don't need to make big IT changes.
In fact, as I say, over 80% of the improvements that I've helped teams lead and perform are behavioural changes, which means the only investment you need to make is the time and energy of the team to make those changes. Too often, teams and organisations just perform the work. What continuous improvement asks them to do and gives them the tools to do is how do we improve how we do our work? So they wear those two hats.
That's the only investment, spending the time and energy building that capability and unleashing that capability, having capacity to unleash that capability. You're so right, Jeremy, that's such an important point. Great, and great to see the passion coming through here.
I love it too. Good to have someone else who's as passionate as I am about this. Hey, so want to move into implementation, right? So hopefully by now people have, we've picked their interest about what the potential is.
Thinking about implementation, you mentioned before the how, the process, but let's start by talking about courage. I know that's something really important to you. Yeah, it is.
And you're right, there's three elements to this. There's the process steps, and we'll talk about that in a moment, that any team can go through. There's starting smart, which we'll talk about in a moment.
But before that is the mindset. And I think this is where, in fact, I know this is where organisations go wrong. They dedicate themselves to the tool set.
They need to focus on the mindset first. And probably the single most important trait is one of courage. And this comes back to the point you made, when we start to measure how we're performing, we see a whole lot of stuff that we didn't expect to see, and it's often worse than what we expected.
But that's good news, because it always existed. The fact that we measure it means now we can see it and we can make improvements. We'll have a multitude of things where we can start to make improvements.
In fact, we'll have too many. We'll need to be smart about where we start. We'll talk about that in a moment.
But the team needs to have courage. And also, with that mindset, if I may just quickly, there's some other mindsets that we need to be cognisant of. So for example, some of the conventional wisdoms or sayings around hard work equals good work, we need to decouple those.
That's not the case. And we need to move from a why we can't to a why can't we mindset, where we start to experiment. Those things that are around us that were limiters to our performance, starting to challenge those.
And it all starts with courage. Awesome. That's great.
And of course, when you're talking before about starting smart, if you start maybe smaller and clever, that's a really great way to manage the courage when the stakes aren't necessarily quite so high. Absolutely brilliant. Great.
Process. So there's a basic process here. Talk me through it.
Okay. So irrespective of the methodology, and many people have heard of Lean and Six Sigma and systems thinking and the better everyday approach and maybe Toyota quality systems, they are all underpinned by four key steps. So here's the cheat sheet.
If you want to save yourself 20 years of experience, here are the key four steps that you can follow. And I do talk about them in the book because you need to have the steps and the how plied together. Here are the steps.
The first step is understand your current level of performance. So let me explain each of the steps in terms of what maybe Hutt City Council did, because they're a great example, and also maybe a personal experience. So I'll start with the personal experience.
So my family and I were throwing out 50 bags of rubbish a year. So one bag per week. And that is, yeah, there's your step one.
How are we currently performing? Where for Hutt City Council, it was a lot more sophisticated than that. It was understanding the rework rates, how long it took to perform each step. What was the lag times between the steps? How long was the queue? What are the other problems that exist? Levels of capability that delay to cause bottlenecks, but they're both the same thing.
How are we currently performing? Then once you know how you're currently performing, you want to answer the why, and that's your root cause analysis. Why do we have the level of performance that we do? Now, in my rubbish bag scenario, there was a case of my kids and I getting a rubbish bag before we threw it out, just running a knife down the side of it and going through and going, what are all the components of the rubbish bag, all the root causes that give us the outcome, the output that we wanted, same with Hutt City Council, with their analysis. And once you've done that now, and this is where teams tend to fall over, and this is why I wrote the book about the how, teams tend to jump straight to solution.
And I get that, that's innate in us. We see a problem, we want to fix it. But by properly understanding the problem in those first two steps, how are we currently performing, and why are we performing at that level, now we can develop a solution that addresses the root causes, that reduces, that addresses the performance level.
You pilot your solution, and how you perform in that pilot, you can now test against the baseline you've got on the first step. And for us, we reduced, instead of muesli bars, we went to apples, and the kids volunteered that, it saved a lot of change of management, right, when the team volunteers the solutions. And the kids volunteered that, and over time, when we know that it's working, we embed it.
And what we experienced, if I can just follow up on the rubbish bag, if you're interested, we got it from 50 bags a year, over a number of years, it was about six years, down to three bags a year. And we've been three bags a year ever since, it's been about eight years, but I've stopped collecting the data, because it's just such a regular thing, three bags every year. Awesome, so I love that, that's a really good, really good story, it reminds us all, this isn't just for the office, that you can... It applies to everything, sport is a big one.
Yeah, and I loved also that you talked about the apples and the muesli bars, because I'm just so passionate that often the best ideas come from the people that are doing the work, right? They have to, you're so right. So when we talk about building capability, we're talking about building capability in the team, and leaders should feel solace, I suppose, to hear that, because it means it's not on their shoulders for the improvements, they become facilitators of the improvement in the work, as long as you build the capability in the team. Great point, Jeremy.
Yeah, yeah, no, that's great. So have you got any advice actually about building capability in the team, and how to do that? Yeah, look, there's probably two ways primarily you look to build capability in the team. One is through training, and so you could have as little as two days going through just some of the high levels, those steps we just went through, those four steps, we'd go through them in a little bit more detail.
So when we talk about that first step, the data capture, how we're currently performing, helping the team through, well, what data do we need to capture? So we're not capturing too much data, we're capturing it in an efficient way, we're making sure it's purposeful, it talks to the customer, and what the customer experiences from the process. So you can either prime your team beforehand, by giving them maybe a couple of days of introduction to this, and then unleashing them on a problem. So they're doing those two things, they're still performing their work, but improving how they perform their work.
Or you can do it in the work with someone like us, that can help them analyse the work in the work and make the improvements that way. But yeah, by and large, it's usually one of those two ways. Right, and obviously, you know, learning by doing, starting smart, as you were talking about before, I know that you've got a, you bought in today a K-bar.
I bought in a K-bar. You bought a K-bar that was purple, so I assume it was a gift for me, because that's probably my favourite. I think purple's great, I was trying to toss out between purple and orange, but purple's great.
So if you just want to give it to me, that's fine, but if you wanted to use it for something... I'm going to explain it just before I give it to you, you can have this, because I was never a fan of the purple K-bar, I bought these 40 years ago, and I'm showing my age now, and I haven't had one since. But the reason why I wanted to bring in the K-bar is this is how organisations get it wrong. What they do is they apply continuous improvement to legacy issues, big legacy issues, the same way I used to eat a K-bar.
So what I used to do after school was I'd buy a K-bar, I'd shove the whole thing in my gob, because I love the challenge of first breathing through my nose, this is going to sound weird. Wait, so the whole... The whole K-bar, yeah. It was easier in summer, because you could bend it, and winter it would just snap, right? It took me seasons to work that out.
And then it was the challenge of trying to chew a little bit of at a time while it was still in your mouth, so you can start to breathe through your mouth, and after a period of time you get through it. But that's the slowest way of eating a K-bar. Great challenge, slowest way, but that's what we do in organisations.
We get a team with very limited capability, if any, in continuous improvement, we say you're the continuous improvement team, we get a legacy problem that's massive, and we apply it to them and go fix that, and in six months' time they've made little leeway, little improvements, people are disheartened, and then they go, this continuous improvement thing, the methodology doesn't work. So start smart, flick it on its head, start with the smallest problems that match the capability of the team, so they get runs on the board. If I was to use a cricket analogy, we're looking for quick singles, because what we're not looking for off the bat is big improvements, we're not looking for sixes and fours, we're looking for improvements we can finish that help us better in our culture, and have the thirst, the appetite, the energy to make other improvements.
So we're focussing on the continuous, not the improvement. So I brought the K-bar in, you can have that mate, because there's no way I'm going to eat that. I will have that in a little bit, but I think even so far, you know, that's one of the best takeaways so far, because that is a really common problem that people have, so brilliant advice there, brilliant advice.
Hey, you mentioned it a little bit before about people jump to solutions. What's so important about step two, in terms of doing that analysis? Yeah, so what we're talking about in step two is the root cause analysis, and the better you understand a problem, the better your solutions will be to match the problem, but you have to address the root causes. So if you imagine it as a Venn diagram, your solution and the root causes, what you want is you don't want just a partial overlap, you want a full overlap, where your solutions address the root causes, knowing that when you do that, your performance will change.
Let me give you a quick tip too. How do you know you're addressing a root cause if the frequency of the problem reduces? So if we're talking rework rates, and they're 80%, if you apply a solution, and they drop from 80% down to 40%, you've addressed the root cause. Often root causes, plural, there's a number of them.
But if you're still doing 80% of rework, but now it's taking you 10 minutes instead of 20 minutes, all you're doing is you're dealing with a symptom, still good, but not a root cause. So that's how you know you're addressing a root cause, the frequency of the problem happening comes down. Right, yeah, really important step.
Do not overlook that step two. Hey, obviously, we're just touching on things lightly, but in step three, right, that's when you're doing your solutioning. One thing which is really important in there is about capturing, I guess, the voice of the customer.
And you talk about this idea of the customer echo. I think people will be really interested to hear what you're talking about when you mean the customer echo. Yeah, look, thank you.
And a customer echo is a term I've used to explain when a customer interacts with organisation, there's always something that comes from it on an emotive side. So if you imagine, during the process, the manufacturing process, one thing in 10 comes off the production line, and it's subpar quality, and it hits the customer, the customer echo is going to come out of that. And they're going to do, the echo is going to emanate.
And what we need to do as an organisation is make sure we're part of that feedback cycle, because the customer will go on Facebook or other forms of social media and talk about the failing. We see it all the time, right? I don't have to name brands, you know, people can probably think back to a number of brands I've read. But that customer echo will always happen, because everyone will have an emotional response to the way they interact with that organisation.
The question is, are we aware of that? And that's why we need to be so conscious of the customer echo. The answers also sit with the customer. So the closer we get to listening to the customer, hearing the customer echo, the better and more purposeful we can make our processes to deliver the customer what it is that they want to be delivered.
So have your customer involved in developing the solution? Absolutely. But listen to them throughout all of the steps. That's the customer echo.
Yeah, that's true. And I've certainly been the source of customer echo at times. And I've certainly been also the one who's gone on social media.
You can't not be. And I know you as well, right? Like you think differently when you're in this field, right? So you'll go and you experience services. I think I saw some recently where you'd go into a hotel or something and you're like, oh, that was kind of okay.
But actually, you know, you can't help but think about... I know the one you're talking about in Osaka, where the chicken, the lunch finished at 1.30. And they didn't let you in the rooms to three. And between that one and a half hours, they had nothing available for you. It's like, oh, let's give me lunch or something.
And there wasn't that overlap. And then you're right. Absolutely.
The customer echo. It exists. Are we listening to it as an organisation? Are we privy to it? Are we hearing it and making improvements? Cool.
So we've got to skip on. I'm conscious that there's just so much more. But as I said, we'll talk about the book and how you get access to the book in a minute.
But one final comment for me, when you come into embedding, I said before that I was a manager and continuous improvement was really important to me. And one of the things I just found absolutely critical, a top tip for me was actually making sure you structured the time, really building in time there. So every week we would have a meeting and it just helped to make sure that it was always front of mind and it was keeping just that momentum because we continually to work on new problems.
And I think that that's a really great way for maintaining the momentum. Up on the screen now, for the sake of time, I won't go too much into the detail, but there were some tips there where you get the slides, you'll be able to see them. I want to jump now though, straight to artificial intelligence.
Everyone's talking about artificial intelligence. I've got lots of thoughts about it. You've got lots of thoughts about it, but why don't we start with you? So what are some things, particularly in the context of continuous improvement, what do you think? Yeah, look, there's some exciting opportunities.
And what we need to do is differentiate between those that are mature at the moment and those that aren't. Those that aren't, let's not talk about them too much, but that's, for example, when we talk about building an agent. So something that replicates someone in the workplace.
That's not there yet, not even close. But where artificial intelligence at the moment, or if we want to call it machine learning, which it's closer to, but anyway, where it's at at the moment is it can help us with tasks and activities. So if we imagine, for example, the analysis of data, we can do that.
I know a lot of organisations are reticent because they're worried about privacy, but there's ways around that. So, for example, with this personal data, it's part of a pool that they're going to look to analyse. What you can do is strip off the personal data and encode that personal data as just random numbers, analyse the data, and then once the data has been analysed, then revert it back, reverse that encryption and bring the personal back in.
So there's a lot that AI can do around good analysis of the data. The other thing too is, if we think just as a simple example, again, of tasks and activities that can be replaced, if we think of teams that use WordDoc templates, but they have three or four templates because it depends on, for example, the nature of the interaction of the customer or maybe in Hutt City Council's example, applications coming in that have different components, what AI can do now is look for those different components and do a really complex if-then. If this and this and this property exists, then we'll talk about this in the letter or the response or the decision making.
But if it's this, this and this, then we'll talk about this. So instead of having a number of templates, you can have one template. It gets a lot smarter.
But yeah, that's where it is right now. So if someone called you and I on site to help with analysing steps in the process, we'd do our normal stuff. Which steps are VRAD? Which are non-VRAD, we would remove.
And of those VRAD ones, which tasks and activities can we convert to AI now? Because we can do that at the task and activity level to just save time. We're still talking manual work and saving time, which means the team themselves can focus on the cool stuff, stuff closer to strategy. Yeah, cool.
And of course, if you're looking to automate a task, it's always good for it to be clean. You don't want to automate it. You're so right.
Yeah. There's some good thoughts. Certainly a couple of additional thoughts from me.
So in the CI world, there's this concept that's been around a long time called autonomation, which is kind of like automation with a human touch. I think in the world of AI, that is going to be a big way forward. You're talking about the agents before, and there's actually quite a lot of work needed to really set up the agent stuff.
But I think a lot of the solutions are going to be, like you say, partly automated, but then you've got a lot of human interactions in there. I think perhaps one thing I really wanted to get across, and out of everything I say today, this may be the number one thing. In response to artificial intelligence, a lot of organisations have created the strategies and the frameworks and the policies, which is fantastic.
That's great. It's really important to get that thinking done, get the guardrails, talk about things like privacy, ethics, what your standards are. That's awesome.
But the concern that I have is about the disconnect that can happen between strategy and implementation. So I think when people are dealing with things that are sometimes complex or ambiguous or a bit hard, people kind of just don't really like that, right? So the default can be kind of procrastination, do nothing, it's too hard, I'm just going to ignore it. So my concern is that if all we do is we do the policy, but don't do anything else to really help people work through what they need to do, I think progress is going to be slow, I think it's going to be inconsistent, and the outcomes aren't going to be optimal.
But I'm confident that the CI process is the perfect environment for helping teams to work this through, right? Absolutely. Because you're looking at the end-to-end process, right? So you're not just looking at myopic, like, oh, we could do this with one thing, because sometimes when you make decisions based on one element without seeing the bigger picture, yeah, absolutely, right? So you need to do that. And you're also often getting the right people in the room for the end-to-end value chain.
You've got understanding the root causes, you know, what's the real problem there? And when you get into that solutioning, what a great forum to be talking about, oh, okay, well, what are the options here, and really working it through, then piloting and embedding. Perfect. Absolutely.
And with the team, that's a good point that you make, because when you have the team in the room, they volunteer which processes they want to give up to automate. So you're not having to sell it to the team, they're volunteering them, because they want to see the back of these processes, because they're doing copying and pasting, or whatever it is, and it's soaking up a huge part of their day. Again, as you say, continuous improvement, all about making life easier for the team and the customer.
Yeah, and that's great. If I was still a manager today, I would 100% this year, be dedicating time to doing that, specifically around artificial intelligence. Conscious of time, you've got, we've talked about it several times, show us the cool AI tool you've got.
I'm trying to use AI to get myself out of it. So yeah, look, what I've done is with the book, and the book's all about the how, and that's why I think it supports organisations irrespective of the methodology they want to embed. So it's the how.
So it's really rich in terms of helping people with the how, but it's terrible as a birthday present. So don't give it as a birthday present, but give it to organisations that want the how. But here we go.
What I wanted to do is make the book so live, that people could ask any question at any time and get a response related to them. So what I've done is I've converted the book into a chat GPT into an AI. And you can ask it any question, and that it'll answer, I went into my wrong chat GPT, and you can ask any question, and it'll tell you what you need to do next.
So quick example. The team and I have just mapped a process, and we want to analyse the health of the process. What is the best next steps that we should take to do that? And so you ask the question, and it looks through the book.
Now to analyse its health, your next steps should focus on identifying problems, pain points, and performance levels. According to Unleashing the Improvement Mindset, here's how you can do it effectively. One, capture problems and pain points.
Look at the process and identify where delays... Okay, and I'll just stop it there. And what it'll do, Jeremy, is it gives you just all the answers and all of the steps. And when you finish those steps, just let it know where you are, and it'll tell you the next steps.
So again, you don't have to refer to the book. It's all there in the tool and supplying that tool. So yeah, I'm pretty proud of that.
It's pretty cool. Yeah, no, I've definitely played around and found it really good. Running short of time, so we are going to move pretty quick, but just a couple of tips.
I know we've talked about only briefly, but I think with AI, one of the important things is about accepting that the reality is that it is going to grow. And one of the things you can do around that is just building your base knowledge around that. One practical thing you can do if you're not familiar with it, other than doing things like explore Darcy's book, one suggestion I've heard is actually making perplexity AI your default search engine.
And then what that means is that when you type it in, you just very quickly be able to observe how it's quite different. And that just, again, is a good way to just begin to get familiarisation, familiarising yourself with the tools. Just before we go to questions, I just wanted to throw to you, just in case there's any last key messages.
Is there any, you know, one key message you also wanted to add? Yeah, there would be. And this is probably in defence of continuous improvement, because too often people think of continuous improvement as cost cutting. It's not.
Cost cutting is something very different. In the 20 years I've been doing this, not one person has been made redundant. That's a very different approach to reshaping or reforming an organisation.
What we're focused on, and what practitioners in continuous improvement should be focused on, is making life easier for the customer and their team. We're looking for benefits, we're looking for improvements. So cost cutting, way too narrow of a focus, we're looking at improving anything.
So as you and I know, when we analyse the health of a process, we're looking for every area we can improve, whether we're doing things faster, or when we do things, we do them of a better level of quality, more purposeful for the customer, all of those elements. So continuous improvement is not cost cutting. Cost cutting is more about almost like a form of amputation to lose weight, as opposed to looking at your nutrition and the way you exercise in a more holistic way of changing everything.
So yeah, I thank you for that opportunity to make that last point about continuous improvement not being cost cutting. Yeah, and it's pretty hard to calling your people to come up with the best ideas, you know, in terms of the incentives for the people you're wanting to engage. Yeah, if you're going down that other path.
Yeah. Now, on to questions, remember that if you have any questions, chuck them in the chat. And to kick us off, I just want to cover off a couple of things that came through the registration process.
So I did notice when people registered, we asked people what some of their top challenges were, and there were some questions that came through. I noticed that there was quite a significant portion of them were about AI, and what you can do there. And I thought on top of what I said a little bit before, in terms of some of the quick tips to help people get familiar with it, I've got some ideas personally.
So for me, I know that it took a while to, you know, I'm one of those people that needs to get my head around a topic, I want to know, well, what's the history of AI? What's the social issues? What, you know, what's the big picture? And not everyone is like that. But I definitely am. So for me, I went out and proactively looked for really good content around that.
With content, obviously, you know, books and podcasts and things, you always need to be aware that it's, you know, one person's view and that it can quickly become, you know, I guess not so current, because it's written at a point in time. But I quite enjoyed reading the book The Coming Wave by Mustafa Suleiman, also the book Cointelligence by Ethan Mollick, they were really good. So if you want that big picture, there's a couple of tips for you.
Perhaps another tip, I would say, would be all these different tools, there's so many of them emerging, and there's, yeah, there's so many of them emerging. But one thing that is in common is prompting, right? So in order to get a response out of it, you need to put a prompt in. And there is actually some standard advice, or there's some really good tips that are emerging about, you know, what is the best way that you can frame up prompts.
So I actually think, you know, to really get started, just learning, as well as playing with the tools, playing with the prompts as well, and learning about how to do that really well. So that's one question there. Dus, you've just been looking at some questions.
Yeah, I have. And look, I'll give real short answers, I think, because we've got a good range of great questions. So Pradeep asks about embedding capability in the team, what are some essential mandatory components to do this? Look, we talked about starting smart, one of the best things to do with starting smart is starting, of course, at the right size, in terms of the team's capability, not giving them too big a problem.
But also start where the love is. What I mean by that is, those that want to make improvements, initially, have them make the improvements, irrespective of what those improvements are, start where the love is. Because what those people tend to do is they make improvements, and they translate for the rest of the organisation what continuous improvement looks like in the organisation.
And that's when other people will start to come on board. And if I may, there's just another one from Ann, saying if you're thinking of root causes, how can you build trust with each other? And you're absolutely right. A couple of things I'd say to that.
One is, you're right by talking about building trust, you need to start with building the right team dynamic. So get the team or teams involved, it's not unusual for a process to go across a number of teams, you get them to work together. Now there's a number of tools like problem statements and capturing problem statements that have rules that in capturing the problem statement, there's no elements of blame, you don't blame.
But when we find root causes, what we find is it's not because the team is performing a certain way, it's the way the team interprets how they are performing in the end to end process. So we're working on the interpretation. So that's removed from the identity of the team.
So if we approach continuous improvement the right way, then we're not talking to the people, we're talking to the work. And that means people can be a lot more honest, and we can be a lot more open about the root causes we're trying to solve. It's not a personal thing for people, it's the way that we were working or the way we assumed we should be working.
So yeah, absolve yourself of that worry. Yeah, awesome. One of the other questions that came through in terms of the registration, I think it was Rachel actually, Rachel talked about compliance culture and the relationship between that and continuous improvement.
And so I had a couple of thoughts on that. So firstly, just want to shout out when you use the term compliance, obviously, there are some teams that are, you know, compliance teams or assurance teams that are doing an absolutely outstanding job. So we're not talking about teams as such, it's more about the culture, that really prescriptive culture, which is just like rigid, this is the way we do it, this is why we've always done it, you must do it this way.
And I guess a key point on that is that, you know, most, while that may be true, most organisations aren't at that most extreme end. And like what you said before, you know, go where the love is. So if you can find in your organisation, a part, a team or a leader who's a little bit more open, start smart thinking about what's working, then you can get those runs on the board.
And that's what helps build that those aha moments where people, maybe some of those people that are prescriptive to go, oh, actually, yeah, like, because you want to be able to give them some really good evidence around that. I think one of the key words you said before too was rigidity. So compliance to me doesn't worry me, if a team is compliant, that means they're doing all the same thing the same way, which is actually probably what we want.
If we've discovered, yeah, if we've discovered the best way of doing something, let's make life easier. And let's do that. When you've got variation within a process, you've got issues, more variation, the more the more problems you've got in the process.
But it's about do we have the flexibility in the team culture to go from one level of compliance to adopting a change and then compliance at another level and another level. If they can't transition between the levels as we continuously improve, then they're too rigid. That's a problem.
And there's different tools and techniques that you and I are both aware of that can get us past that. And that is the freedom of the team themselves to make changes. As long as those changes are based on data, address a recourse and serve the customer, then whatever changes they come up with, whatever solutions they design, they'll work, they'll take us to the next level.
So we can't help with that. Compliance, not a problem. Rigidity, problem.
Yeah, absolutely. And I think that's what Rachel was probably getting there. Yeah, yeah.
Hey, really common issue for some teams starting off. Had a question from Claire. What advice do you have on measuring improvements when there is no measured baseline? Just a known issue or pain point.
Yeah, perfect. And so start from step one, which is get those measures. You've got to start with the baseline.
And you're doing yourself, especially if you're leading the team, you're doing yourself a massive disservice because that means your solution, as effective as it may be, you're not going to get, you're not going to understand the full benefits of it. You need the baseline. When you're capturing the pain points, two things you're looking to capture.
One is frequency. How often does that pain point occur? And the second element is its severity or its impact. When it occurs, what is the impact on the team and the customer? Make sure you capture those two, especially the frequency, because of what I said before.
If you address a root cause with your solution, the frequency will reduce. So yeah, capture all your pain points. Make sure you capture frequency and severity.
It's okay initially to go on gut feel about what those numbers are. And then you can compare all the pain points to each other and know which ones you're going to capture data on because you don't have to capture data on them all. If one of them has frequency and severity, infrequent severity is not very, but another one, high frequency, high severity, and it's small enough that the team can tackle, then you've made your decision.
Let's capture the data there. Let's validate what we think. That's great.
Organisation teams need to have clear objectives and right leadership before CI can be implemented. What if these are not in place? How can CI still work? Yeah, look, I don't know if you had an idea on that, so let me keep mine short. Too often what people tend to do is with continuous improvement, they try and embed it across the whole organisation.
Don't. Embed it with a team that has the appetite to make a change. So for example, if I'm talking to a group of senior executives about continuous improvement and what it might mean for their teams and their departments, their areas, I might have two or three that come up to me afterwards and go, what you've just talked about, that's what we need.
I don't try and embed it across the whole team. I start with that three. I never consider the size of their problems because I know there will always be problems or pain points there, but I start with them because they're engaged.
I check with their teams. If they, the teams, aren't as engaged as the leaders, I start there. And as I say, it becomes a translatory piece where we show what continuous improvement looks like in that division, that department, that team, and that team shows the rest of the organisation what it meant for them and have it go out that way.
Don't try and do our organisation all in one hit. Start with the lovers, with those that have the appetite and attitude to say, yes, start with us, start there, because you'll find pain points everywhere. As long as the love's there, you can start with those pain points.
Make life easy. Yeah, no, that's great. Endorse that.
Got a question from Waka. How do we measure someone's capability? So, I guess when you're talking about building capability, sometimes as managers, you want to kind of get a gauge on where people are at in the journey. Do you have any tips about how you can assess the capability of the individuals or the team as a whole? Yeah, look, you'll get that as an outcome because you'll know how quickly they are able to go through improvement initiatives, which really should only be about a month to three months long, maximum, maximum.
Without labouring the point, that is something I've talked about in the book with the two loops. The first loop, the capability is thinner because the team have only done one improvement initiative. In the second loop and subsequent loops, it gets thicker and wider because of all the different experiences they have as they go through the improvement initiatives, as they go through those four steps, and the capability grows that way.
Rather than measuring the capability and seeing where it's at, and that can be hard to quantify, you just check the appetite against the size of the problem. Let them scope it up, and they will say, yes, I'm ready to go at that problem, or they'll go, I think that one's a bit too big. This is what I need in terms of support to be able to tackle the problem.
So yeah, tackle it from that way. But that's a great question, because it's based on the premise of how do we start with the capability, and that's absolutely right. Don't throw your team in the pool without them being able to swim first.
Teach them how to swim in the shallow end of the pool. Yeah, and when you mentioned there about your two loops, that's one of the parts of the book that I appreciated most, because that's real, right? So what you're talking about there is getting people to go through the process, but that's smart, and then building the capability, so then they have the ability to do that more intensive loop. Too many methodologies.
It's the same methodology, whether it's a small problem or a big problem, and that's what suffocates teams right at the start. Again, that K-bar example. So loop one is all about what are the bare minimum things that they need to do, which means they'll survive a small problem and get runs on the board and get it done.
That's great. I'm just having a look and seeing if there's something else. This one's good.
It came from Claire, just about perverse outcomes. This is something that we're really conscious of. So what advice do you have to avoid perverse outcomes when prioritising opportunities for improvement and when selecting your measurements for CI? So what she's talking about there is you're making a change, you're thinking of solving a problem, but actually you're creating another problem along the way.
Have you got any particular thoughts on that, Darcy? Yeah, I'll say this, where you address perverse outcomes is in the pilot. So part of the pilot, and a pilot is about testing the solution on not all your customers, it might be a group of your customers, it won't be the whole process, it'll be on part of the process, or it'll be for a limited period of time and do an assessment during, but you do your risk mitigation and management during the pilot. So what might be some of the perverse outcomes, and how will we know if they're occurring? So you have that measurement monitoring system built into that pilot.
So if things are going great, fantastic. If they're going off kilter, you'll know because you're measuring, monitoring it the right way, and if those outcomes start to happen, worst case scenario, and thankfully I've never experienced this, where you have to shut down the pilot early and revert back because you've missed something in terms of your root cause. Yeah, no, that's good.
And I guess my tip, coming from a bit of a change manager experience, you know, there's an approach where you do a change impact assessment. I'm not saying you'd necessarily need to do something for here, but there's a discipline that you can go through where you're systematically looking at the different parts of the business, and you're looking at across different domains, and you're forcing yourself to think a little bit more deeply and kind of going, okay, so let's just think about this. What are all the ways that this could impact that group, and fleshing it out, and actually just by going through that process, it can flush out some of these things ahead of time, and I would encourage people to, you know, definitely spend time doing that.
Yeah, absolutely. How do you measure, this came from Phil, how do you measure the return on investment of continuous improvement initiatives, particularly in government contexts, right, where financial outcomes aren't the primary measure of success? I think I know what you're going to say here. Great question, okay.
Firstly, financial outcomes should only be a part of the benefits that come out of it. There should be benefits that free up capacity in the team, there's benefits that means what we're doing is more effective for the customer, or we're reducing rework, so yeah, there should be a myriad of benefits. Every improvement should at least have two benefits applied to it, because two good things happen to it.
So for example, rework back to the customer, it saves the customer time, it saves the team time, there's your two benefits. So yeah, there will always be, don't worry about benefits just being financial, there will always be a myriad of benefits. So, and capture them all, absolutely capture them all.
Okay, right everybody, looks like we're out of time, but Darcy and I are both really happy to catch up with you after this, if you should wish to do so. What was the number one takeaway for you? Look, I think the key takeaway is, not talking about why people do continuous improvement, I think they get that, but we talked about a lot about the how, how they can start to embed it in their culture, starting with courage and starting with capability. What about you, what stood out? I just, yeah, it's very similar, it's that idea of, you know, starting smart.
Nice. Yeah, instead of just just eating the whole kei bar, it's about, yeah, just actually thinking about what's we could do that's really manageable to get those quick runs on the board, to build that capability, so then you can tackle a bigger problem. Absolutely think that's good.
Yeah, so we've got a website, our Alan Clark website, not only will have information about this webinar, but we've got now a huge repository of past webinars, all sorts of resources there, encourage you to check it out. You've got a website too, what can you find there? Yeah, look, if people were to go on my website, there'd be a bit more information about continuous improvement and some of the benefits that have come from some of the case studies and some of the improvements I've been involved with. Thanks, Jeremy.
Cool, no, that's awesome. It's been a delight having you here and, yeah, that's all for us. Now mihi for joining, we'll see you at the next one.
Ka kite anō.
