E012: Problem Solving with the A3 Method

This is the world of work podcast with James and James, hi. This

is James and just before we start this episode, I wanted to remind you that you can support us via Patreon on our website at WWW dot, World of work.io. Forward, slash support. Okay, let's get on with the episode.

Hi everyone. This is James. I'm Jane, and here we are again for another episode of a world of work podcast. We've made it up to number 12. I know we've solidified our double digits. We didn't ever necessarily think that was going to happen, but that's pretty exciting.

Today we're going to be talking about problem solving. Specifically, we're going to be talking about the a three thinking process for problem solving, which comes out of, broadly speaking, lean Lean process improvement. So that's what we're going to be working on. Today, we'll be loading up some slides that you can look at to our website,

which is www, at www, dot the WoW podcast.org, and you can also reach us on Twitter, at the WoW podcast, seamless. We're clearly a bit rusty this week. We are a little bit, aren't how's your week been anyway? Has it been okay? Yeah, it's been good. I'm probably for context, we should let people know that, similar to one of the other episodes, you are on one continent and I am on another. Yeah, I've had a nice time, right? So I went up to Boston for a while and saw my family up there, and then I'm down in Charlottesville and Virginia now as well.

It's good. So I got to do some nice stuff. It's been nice out here. I have had a lovely week. I've only been rained on three times. My house looks like a bomb has hit it, because my dog is very muddy, because it's so cold, and the minute she comes in to trash the place. So in in, you know, painting a picture of our two lives meeting across the Internet right now to record this podcast, I'm relatively confident the listeners understand who's got the better end of the better end of the deal. Yeah, I feel pretty good about that, to be honest, right now. I mean, it's not always away, but I'm not going to say it's bad at the minute it's been I'm alright though, because I put my summer holiday for next year, I'm happy. Well done. Well, you're ahead of us. We've not done any of that yet. So there you go anyway. So today we're going to speak about problem solving using the A three thinking method, and we're going to do it as we usually do so we'll run through some definitions, then we'll do a bit of a research round up. And in that research, round up, what we're going to do is we're going to give an overview of the high level steps that one should go through when thinking about solving a problem in a work environment. We'll do a little bit around identification of problems, a little bit about how you can prioritize your problems or opportunities you want to work on. We'll talk about who should be in the room for problem solving. We'll run through this actual problem solving approach, and then we'll talk a little bit about implementing solutions. Once we've done the research around it, we will pop on to our list of a week, which is some things to watch out for when solving problems, so things that can commonly go wrong. Then we'll do stories from a keyboard and final thoughts and top tips, and then we'll check out, and that will be us done with another episode. You know, that's beginning that sounds like a little familiar, or, I know it's almost like we're trying to be consistent. This is probably, I'd like to clarify. Thanks to you, James. This is probably the most consistent I've been in anything in my life ever. So I like a list, I like a list, and I like a structure. So that's good. Yeah, it's good. And we get to say return on investment this episode as well. So it's a little hark back to a glory. Those of you who listen to podcasts at the beginning, you'll know how excited. And the hilarious thing is you're going to mention potentially return on the investment. I might be talking a little bit about finance. I know, I know.

I think you should speak about finance in every episode from here on, so we'll see if we can make that happen. I think that's not bad. But anyway, okay, so should I kick us off? Yeah, why don't you start with some definitions. Okay, it's that time of the podcast where I like to have a little think about the terminology and some of the definitions around and words that were going to crop up. This one's a pretty straightforward one, I think, this week around problem solving. So we start with what the definition of a problem is. And thanks to my personal favorite, the Cambridge dictionary, problem is a situation, personal thing that needs attention and needs to be dealt with or solved. I'm just going to mention very briefly, there's a very odd thing in definitions of problem that they always seem to mention the word solution, and solutions always seem to mention the word problem. And that's not truly defining something, if it's just the reverse of something else.

But, and I think I do wonder if that is because people struggle with defining what a problem is. But if you knock off the end of it, it is a situation, personal thing that needs attention and needs to be dealt with. I think I don't know what you think about the fact that there's a person in there. I was smiling at that. I'm not sure that.

Yes, really will be interesting if you follow on their definition in relation to parenting as a problem child. And I think that's quite old fashioned thinking. Yeah, I'm not, I'm not, certainly, in our context, in the world of work, I wouldn't think of a person as a problem and yeah, I have heard that referred to in a number of contexts. Yeah, yeah. Which, makes me sad. Okay, so from problem I therefore, I thought it would be a good idea to look at the definition of solution, and I turned to our trusty friends of business dictionary for this one. So there's it's answers suggested or implemented to try and solve the question or problem.

A solution can be either simple or complex, and may require few resources or many resources. For example, the solution to a math question may be addressed quickly with a calculator, but a solution to preventing accounting fraud may be more complex and require a great deal of time to find I didn't realize we were going to get that much finance. That's exciting. I mean, accounting fraud as well. I take that especially,

but I've got a real issue with this definition. And actually, I've got a real issue with most of the definition.

Firstly, the context is dreadful. The idea that maths is simple and that there isn't like high level theoretical maths that involves huge resources is crazy. And I understand they're trying to say it's either small or big, but those are bad contexts. And I also think, I think quite often, solutions

are not answers suggested or implemented. I think solutions are a way of rectifying or resolving or improving

in response to a question or a situation. I'm not even sure of what my term is, but I know I don't like that one, so the third and the last two are opportunities. So an opportunity is a favorable juncture of circumstances that the halt that provided an opportunity for

sorry, start again. Opportunity is a good chance for advancement or progress, was the one that I picked out. There's another one which is crazy and I don't really understand, but the most important one that I would talk about with opportunity is a good chance for advancement or progress, which I quite like. I don't know whether they mean a good chance, as in an increased chance, or whether it's a positive chance, but either way, it's good. Yeah, it's good. And then the last one, and this one I'm mentioning, because it's going to come up later, I think, is around root causes. And I've taken this from a slightly odd place. So I've taken it from the global voice of quality, which is the American Society of quality, wow, global organization that advocate about quality standards and stuff anyway, talk about root cause analysis. And I really like some of the stuff they said. So they say root cause is a factor that caused a non conformance and should be permanently eliminated through process improvement. Now, I'm aware that's a very quality, specific statement, right if, at first glance, doesn't

apply to the wider world, but I think it's really important that it is something that is a root cause is something that is causing something that you don't want to happen. And that, for me, is the bit that matters. And the fact is a root cause should be permanently eliminated rather than trying to solve the problem you think you're solving. So for me, that was, I think it's a really interesting definition. There's also, there's a bit underneath it on the website, which I just had to share. The root cause is the evil at the bottom that sets in motion the entire cause and effect change causing the problems. That's lovely, but evil at the bottom, we need to sniff it out, don't we? I mean, it's just, I mean, it's so when you think about it in the context of a problem, can be a person, for example. Oh, I know we can't. You know, there's layers. There's just many layers in that that I'm really not but

I do like that definition in particularly in relation for work context. And I like the fact that it talks about the fact that you should address the root cause. I think that's really important. When we come into problem solving, it's not about solving a problem. Isn't really about mitigating the impacts of a problem. It's about changing the way things are so that that problem doesn't occur again and that necessity so. And you know, I like to borrow from other industries, right? So for me, an industry like quality, which has such specific processes, so when they talk about non performance in the food industry, for example, they're talking about, you know, the wrong amount of salt being added, or the wrong temperature that something's set at, or, you know, an output that they weren't expecting from a scientific process. But I think you can really well take that and label it.

To people's behaviors, organizations, processes and things like that. Yeah, it is translatable. So I think, I think that's a useful definition for what we're looking at Cool. Well, that's the definitions of the terminology that I picked up for this week, cool. So hopefully, if we keep those in mind, they're kind of helpful for what we're going to speak about. What I'm going to do is I'm going to jump on to a research round up now, and in this I'm going to run through a high level sort of process to do with solving problems. We'll have a little look within that, at identifying some problems. We'll have a look at prioritizing some of your options. We'll have a look at who you should engage with for problem solving. Who were right? People are we'll look at solving problems, and then we'll look at implementing solutions. And one of the things I wanted to say fairly early on here is, I'm speaking about solving problems, pardon me, and we read a lot about problem solving and problem solving methodologies and things like that. And to me, solving problems is really about making something better, right? You know, we talked about identifying root causes. We talk about various things like that, but fundamentally, what we're talking about doing is changing the way we do something in an organization so that we get a better outcome. So maybe increased quality, maybe reduced time, maybe increased consistency, maybe increased consistency, absolutely, maybe reduced cost, all these types of things. So for me, there's quite a lot of overlap between problem solving and opportunity improvement. They're both about taking a current state way of doing something and modifying it so that you get a better outcome or a more efficient outcome. So I'll talk about problem solving, but sometimes I'll maybe use that slightly interchangeably with, you know, improving opportunities. So I just wanted to mention

that. So let's start by having a think about high level process, right? And you might have guessed or picked up from my rant of what we're going to talk about, roughly what about processes? So the process is, you need to identify your problems or your opportunities. You need to prioritize them so you know what to work on. You need to get the right people to work on them with. You need to then work on them and come up with solutions, and then you need to implement the solution. So that's that's really what it is. And fairly often people think they just need to solve problems. But there's a little bit more to the framework than just getting into a room and solving problems. So if we start at the beginning, you've got to identify the problems and the opportunities that you want to work on if you're in a business or any other walk of life, to be honest, there are often a myriad of things that you can choose to work on that would improve the way things are for you. Okay, so if you're thinking about it from you know, say you're a team leader in an organization, or a manager or head of a function, there are different ways that you can identify things for you to work on, things for you to improve. So there are sometimes things that necessitate improvement right away. So you can have a break in a process. You can have, say, a regulatory issue, you can have a customer complaint, you can have things like that that necessitate immediate change. And so those are drivers for process improvement. So they're a fairly standard way to receive a problem for you to work on. So that's one way to do this, and they're often priorities. And then there are some other ways where you can identify things to improve as well. So you can go out to your suppliers and ask for feedback from your suppliers around the way your process works. They might be able to provide you some problems to work on, or opportunities to improve. Maybe a little bit more important, or a bit better to some extent, is customer feedback. So you can go out to your customers, be they internal customers or external customers, and ask for feedback and say, you know, what could we do better that would lead to a better outcome for you? What's not working for you now, and how would you like things to be? And that can help you identify things to work on, or things to improve,

to focus on. Then you can do another thing, which starts to bring your team in. What you might want to do is you might want to go out to your team, or your broader team, and say, Okay, why don't you, being close to the processes that we're working on, come up with some ideas and send in ideas for things that we could work on to improve. And why don't you suggest you know what those things are, why they're important, and how long you think would take to fix them? And then then then we can have those as a pool of things to consider. And another thing that you can do is you can get your team together, or a larger team, you know, broader team of some peers, and have a brainstorming session and really work through things to improve on.

So so that that collection of processes gives you a really broad way to identify things that you might want to work on in your business or your team.

I said at the beginning, things like the sort of mandatory ones are important, and they absolutely are. But at the same time, making things better for your customer is very important, and something that I'm quite passionate about is getting suggestions from people in your team, because. Is they are close to the way things work. So quite often team members,

people involved in delivering the day to day operations for your team, have a really good sense of what could be made to be better. And I think really picking up ideas from them is an essential and important thing to do. Not only does it mean that you tend to get some of the better ideas and you know, good options to work on, but it really drives engagement in an early stage with solving problems and making improvements. And there's some interesting sort of literature out there about how a lot of the stuff which derived from,

you know, sort of Toyota and their approach to Lean management, some stories about how this really does drive engagement, and how getting, certainly manufacturing process improvement ideas from within floor staff is a really powerful thing. So stage one is identifying things to improve. Yeah, and I think just one thing around that, getting team involved, I find it really useful to

set a context around the strategic plan or the operational plan that they're operating under.

Because I think one of the things that is challenging for them is to think about things that will work for more than one area. And I know you've alluded to this before when we've talked about it, and I think so one of the things is about if you are going to get ideas from within the team, within the team, how can you set the context of what they're thinking about and what sort of problems they're looking for, rather than focusing just maybe on the problems that most affect them in their daily routines? Yeah, that's great. Yeah, different levels of problems are definitely a thing.

So once you've done an activity like that, what you tend to find is that you'll have quite a few things to think about. You'll have opportunities that you can look to implement to make things better, or you'll have problems that you think you need to try and solve. Now my suggestion would be that you only ever work on one or two problems at a time in a team, and problem solving takes quite a while. So what you need to do is you need to prioritize amongst those options that you've identified to work on and try and decide which ones you want to start. You know, where do you start? How do you how do you decide what order you do things in? And the way that I seen this work fairly effectively in the past is something that I'd call, I'd call an ease benefit metrics. So I'd get the relevant people in the room, and I'd have basically a two by two grid. I would benefit on the vertical access and ease on the horizontal. And I would take each one of those options for improvement that you've identified and put it into one of the boxes, if it's got high benefits and if it's easy to do, I'd stick it out there in our top right box. If it's got low benefits and it's hard to do. I'd put it in the bottom left box and so on, and I'd map out each one of those things that we'd identified and put it in a box and then start with ones furthest to the upper right. You know, the easiest ones with the highest benefit are where I'd start.

But part of the purpose of this exercise is to make sure that you and those involved in the process think about prioritization and reflect on but easing the benefits of what you're doing. So it's just good to have a process, really, and that's one I recommend.

So I do, and I think it's a really important thing. I think very when problems, particularly when problems are quite presenting, so people are seeing them, they tend to rush straight to, let's just get it sorted. And I think in times like that, it's when you really need that, that process, you really need that thing that everyone knows that's the way you do things, yeah, consistency in the organization, that you don't just do things a certain way. Yeah, that's right. And this is really the only way you can find the highest return on investment things to work on. Oh, James snuck it in. I know you're a little bit sad because we didn't have a return on investment last week. I know I just wasn't thinking. I was a bit rusty. I didn't think about it. But if we've done it again, I would have got one in, aren't you? But you're right, and you're right. You know you can solve all the problems you've got all the time. Pick the ones that are going to make the biggest impact or that you most need to do. Yeah, exactly, exactly. Okay. So, so then, at this stage, what you've got is you've got a list of problems, and you've prioritized them in order, and you know which one or two you're going to start out. You know, I don't ever start one at a time. You could run some contemporaneously, but start one at a time. So now you know what you're going to work on the next stage. Then before you actually look at solving the problem, is figuring out who you should have in the room, right? Who should be involved in helping you solve these problems fairly often. One of the things we see is that leaders think that they're the right people to solve problems, but I would just say that that's wrong for lots of levels, for lots of reasons. You know, they might have good things to say, but in reality, leaders often aren't as close to the details as lots of people, and they probably really have other roles to play in the organization and solving problems. You know, their role is about creating spaces and environments and ways of working that help people solve problems and recognizing good behaviors and things like that in relation to problem solving, more than it is to actually solve problems with that. We need to figure out who the right people are to have in the room. So.

Yeah, and some things that I'd suggest thinking about are groups of people that I'd suggest thinking about are,

you know, the people in the team, so the people doing the task closer to the day to day work, as opposed to the leadership. I'd think about, if any processes span different parts of your business, are there process owners who know, you know, the precursors and the latter stages of a process, they'd be good to have involved. Are there technical experts that you need to get involved? Do you need to get people earlier in the process flow? So potentially, your suppliers, from a data perspective, or information perspective, involved? You need to get your customers, so the people who will be receiving your output, so they can think about what, what the impact on them would be if you're leading to something that might need project implementation to develop. You might want to have a project team person there so they can tell you about some of the technical stuff. And you know, the processes that exist, you might want to bring in people from peer groups who have done similar things in the past, who might have some ideas. And one thing I'd say is that, you know, all those people are useful. And if you're going to pull together a fairly broad, multi skilled and multi knowledged team, then what you might want to do to help with your problem solving is actually get a facilitator in because it's hard to contribute to problem solving while facilitating at the same time. So in that, I didn't mention the team leader at all. And of course, that's hard for team leaders to step away. They don't need to step away completely. But you know, it's maybe okay if the team leader steps away from a problem solving approach well, and I think I would argue quite often, and it relates to something I've seen in other processes as well, around business process. If you can step away as a leader, then you can, especially at the beginning,

it gives someone who wasn't in the room an opportunity to be a little bit more candid and a little bit more independent. Further down the

road, yeah, getting out of people's lives, I think, is useful sometimes. If you're all in the room and you're bought into a solution and you're convinced it's the right one, it's very hard to

be the person who thinks actually, hang on. And I think, you know, without all of the noise presenting a solution and realizing it's not, it's not going to solve the problem, that you actually that you actually wanted it to, but it's the right thing to do. And that happens quite a lot, when people come up with great ideas, but they don't solve the actual problem that they're meant to be solving. So then they get rushing forward, and they're still, like, left with the same issue. Or, even worse, they make it worse because they're implementing something good on top of something bad. Yeah, yeah. So that's a piece around getting the right people in the room. So what we've talked about is how you identify the things that you want to work on, problems or opportunities, how you prioritize from amongst those options and who then you want to have in the room to help you solve those problems. So that's kind of a precursor steps to solving problems. What I'm going to talk through now really quickly, and again, as usual, you might benefit from looking at some slides or doing a bit of googling. What I'm going to talk about is a problem solving approach known as a three thinking as I said earlier. This comes out of Toyota, and it's fairly, you know, lean based in terms of what it is.

There are seven steps to the A three thinking approach to problem solving. What I'm going to do is just touch on each one quickly, so you get a sense of what's here.

So a three, as I said, it's got seven steps. It kind of divides into two halves. The first half, which is stages one to four, is about understanding the problem and what you're trying to do. Then the second stage, sorry, the second half. So stages five, six and seven are about your solution, and it's really important to do them sequentially, because you've got to understand where you're coming from and what your what your current sort of situation is, and what you're trying to do before you go on to find solutions. And you know, when we talk a little bit later about some advice will reflect on this. But one of the really important things that this methodology helps teams ensure that they don't do is jump into solutions. So you know, a lot of times you'll get people in a room and you'll say, we're working on this problem, and somebody will say, Oh, yeah, we just need to do this. And they'll immediately try and find a solution to it. And a lot of what the a three thinking approach is doing is trying to prevent that happening and trying to implement structure and logic and, you know, a sequential process so that you get the right information in place before you try and come up with a solution. So that's, I mean, if there's one key takeaway from all of this, it's, you know, understand what's going on before you try and solve Yeah, and I think, I think the thing about having a process that's really important is that quite often, the whole idea of jumping to first solution, it might be first one, or it might be the one the most senior person in the room at the time says, Yeah. And I think

having an adopted process as an organization gives people who are more junior a a stick to bring some control to the situation. Yeah. So.

You know, you know, yeah, absolutely, that's a great solution. Thanks, boss. But let's go through the process anyway, because that's what we do as an organization. And yes, you'd be a bit, you know, it's annoying to someone, but actually quite often it's not the right solution. And if it is the right solution, great. You've got evidence. Yeah, on that one time when I wrote this out, I gave everybody little laminated pictures of a cartoon frog. So when everyone, anytime anyone, started jumping to a solution, they could just chuck their frog at them. And that actually, once I'd done that, you know, nobody ever jumped to solutions. I don't know why it worked, but you could just show somebody the picture. Whenever they jumped to solutions, there was a picture, like a cut out of a hop in frog, yeah. So the reason they didn't do it is because no one wanted their card thrown at them. Yeah? And it just worked. It worked really well, right? Just that little physical. I love that. James, I'd have loved to have been in that room. I'd have been jumping to stations just to get one thrown. It was fun. It was a fun way to do it.

Okay, so let's talk through these stages then, so listeners know what's going on. So stage one sounds obvious, massively important, what is the problem, right? What I find really interesting about this stage is, if you get a mix of people in the room and you ask them what the problem is, if there are seven people, you'll probably get 10 different answers, right? I mean, you know, defining your problem statement is a hard thing to do. What you want to do at this stage is you want to try and reach consensus on what the problem is, and you want to make sure that the room, the people involved in problem solving, are clear on why it's worth spending time on this problem. As I said, you know, you normally get more problem statements than you get people in the room, and what you'll find is, as you go around the room, people will call out different different problems. And if you're facilitating, or someone's facilitating, they'll probably capture some of those. And then, once you've let everyone had a chance to speak, you might be able to create a summary problem statement that people are fairly happy with. But it's important to get consensus on what it is that you're trying to solve at an early stage.

Now this isn't actually the first time last time that we look at what the problem is. You'll probably need to return to it as you go through the a three process, but it's it's important to get at least a starting point of consent. So that's stage one, defining what the problem statement is, or opportunity statement, but usually problem statement. So once you've done that, you can go on to stage two, and stage two says, Well, we know what the problem is. What's the actual current state? What's happening at the minute? Let's try and talk through the way the processes are at the minute so that everyone's clear on the things that are taking place at the minute.

You know, what are the flows in which this problem occurs? And here you want to ask things like, when does the problem happen? Who's involved? What happens after the problem takes place, what systems are involved in this process? Does this problem happen every day? How many failures happen when this happens? Are there ever any exceptions to this and so on. So you start to build up a detailed understanding of everything to do with this problem. And you might want to capture this definition of a current state as you know, a list of bullet points. You might want to do it as a flow diagram. You know, really whatever works for you is helpful, but the purpose of this is to make sure that everyone understands all the different factors in play in relation to your current state.

So that's stage two. So by the stage by the time you've finished stage two, you've got a view on a problem statement that everyone's agreed on, and you've got consensus from within the room around what's actually happening at the minute. You know, what is the playing field that we're operating within?

From there, you can then go on to stage three. And stage three is about saying, Okay, well, we know what the current state is, what future state do we want? You know, what is the future outcome that we want to have? And what you're trying to do here is reach agreement within the room on what look what good looks like in relation to the problem statement. And you don't want a solution here. You don't want a complicated set of flows. You just want something simple. And the statement might be that system x produces timely output that's accurate and that's easily passed of a customer, something like that, right? So you're just looking for a simple statement at this stage. Now, something that that's interesting here is that quite often when you start to think about your future state, it can lead you to need to re evaluate what your problem is. So you might find that the future state that you've defined is not really related to the problem that you thought you were solving in the first place. So once you do future state, it's worth cycling back and thinking about your problem and just making sure that you're actually happy with what your problem is.

So that's stages one, two and three. So again, what's the problem? Is everyone happy that we know what the problem is? What's the current state? What's going on at the minute? Do we all know what's happening around our problem, and what's the future state to stage three? Do we know where we're trying to get to roughly? Do we do we have a vision for a future loosely? And then with those three things, we've got a lot of a building blocks around.

Problem to let us start to really think about it. Now that leads us to stage four, which is, for me, probably the most important stage and stage four is root cause analysis. So when we get to stage four, we can say, is everyone involved in problem solving? Or we can ask them, Why is this happening? What is actually the source cause as to why this problem is occurring. And here you'll use probably different tools that we won't touch on in detail here, but there are tools like the five whys and Fishbone analysis that can be used to help teams drill down sequentially through potential causes to try and find a root cause that helps them,

sorry, to get to a root cause which were they to resolve would mean that the problem doesn't occur anymore.

And when you're looking at root causes, it's important, in my mind, at least, to think of a range of different root causes that can be out there. So the way that that I'd probably try and run this. If I were running it as a session, is, I'd get everyone in the room to brainstorm as many root causes as they could come up with.

And actually, I'll delve a little bit into five whys and Phish them, just really quickly. So but five wise basically says, Think of think of a cause, and then ask yourself why that happened. And then, you know, the root cause that comes out of that. Ask yourself why that happens. And basically, keep asking yourself why, until you can't find a lower level cause for something that's all five wises.

And then so I'd ask the team to think about five whys and come up with all their potential root causes. Then I do a sort of grouping exercise, grouping the root causes thematically around the room and labeling there. So probably with some labeling, you'd end up with broad headings for root cause categories of things like, I don't know, people, processes, systems, culture, loose headings like that. And that just gives you an overview of root causes that are there, that are contributing to your problem. And that's really part one of a three thinking approach. It's getting an understanding of what's going on now and where you want to be. How's that sound to you? Jen, is that roughly what you I'm a real fan of this. I you know, sometimes I think things are over engineered, but actually, when you think in practical terms of a group people sitting in a room trying to figure something out, I think it's a really good approach to in establishing

the very The very fact that there is a root cause analysis stage suggests automatically in people's heads the problem is probably not the real problem. And that's a great place to start from. Yeah, I think, I think it's good. And,

you know, the whole process can take longer than people think. You know, sometimes it can take you a couple hours to get to the end of your root cause if you're trying to tackle some more complicated things, and that can be frustrating and difficult, but, you know, it's worth it. I think it's I think it's a good process as

well. So let us jump on to the second half then. So here we've got consensus in the room on what the problem is we know everything going on around it, so the current state, we know where we're trying to get to the future state. And we've done a lot of good work identifying some root causes that we think are the source of our problems and we want to fix them. So we know all of that. We've done our sort of research. Now it's time to look for solutions and to move on to the second half of the problem solving piece. So stage five is the short term solution. And what you're trying to do in Stage Five is you're trying to come up with a workaround or a quick, immediate solution that will help you overcome any immediate problems. And for me, the short term solution is something that I'd only use if a problem is an urgent problem that's causing

immediate challenges for the material to the team. You know, if something's happening that's preventing you doing work, preventing you delivering something for a customer, then I think you need a short term installation. I think, though, that if what you're looking to solve is kind of working okay at the minute, and you've got an opportunity to make stuff better and things like that, then I would actually skip straight past stage six and go, sorry, skip past stage five and go straight to stage six, which is focusing on long term solutions. And this is about trying to really, you know, not mitigate things, but really address for root causes here.

So the way that I'd look to tackle long term solutions is I'd pull out the information from my root cause analysis with the team, and I'd say, you know, we've got, here's the outcome of our five whys. Here's the summary from our fish bone analysis. Here are the high level grouping areas that we looked at when we grouped our root causes into different strands of similarity. And I'd say, you know, we've got these. What we should do now is we should assess these root causes and see if we can come up with solutions that help us overcome these root causes in such a way that we can create a cohesive, overarching solution to our problem. So if one of the root.

Or strand is systems. We could discuss systems and say, Okay, well, let's look at systems and think about what are the things that we could do to provide a solution to the system problem for what we're doing, and if there's another area that's maybe around capability, if that's another strand of root cause, we'd say, Okay, well, what is a solution that we could implement that would overcome the problem of capability. And in working through each one of your root cause areas, or individual root causes, and trying to come up with a bit of a solution in relation to each of those, then you can come up with a combined, overarching solution that should help you really address your root causes so the problem goes away. So for me, that's an important stage. And again, this can take time, but for me, it's important to make sure that you've been comprehensive in identifying solutions that span across the different areas of root causes. Is that the way you do something like this? Jane, is that similar? Yeah, I think so. The bit about jumping past stage five, around short term solutions. The way we dealt with that was, the question was always at the end of stage four, the question was, how much time have we got? How much time have we got before this becomes business critical? And sometimes the answer is zero, because it's a mandatory legislative, legislative change. For example, yeah, we had lrm teams, yeah, yeah. So then and that, that answer to that question was always critical for salt deciding if we needed a patch, and we quite often used patches, not not a patch, in an IT term, like a patch for the solution. We knew that, you know, something was taking far too long, and we were like, Okay, well, temporarily, we'll get someone in to cover that process as an admin staff. But long term, that is not a solution, and timing is critical then, because then it's about how long have you got that short term solution in place? Because it can't just be open ended, otherwise you never solve the

problem cool and in terms of a longer term piece around trying to tackle the strands of root cause is that a similar type of approach that you go through for longer term solution solving?

Yeah, it's almost, I mean, I would say without, I wasn't particularly familiar with lean up until about two, three years ago, yeah. But I would say that's a process that we've used, I've used in my operations teams, which is where problem solving tends to be at its most detailed. Yeah. And that would be a process very similar to what we use. Yeah, cool. All right, so that's stages one to six. So what we've done is we've defined the problem, we've understood it. We know where we want to get to. We never root causes. Maybe we've patched it or put in a like an immediate fix to to overcome a critical issue. If we haven't done that, then we've started to define a longer lasting, longer term solution that will actually overcome root cause. So we've done all that, and that gets us onto stage seven. And stage seven is all about starting to transition to actually implementing a solution. And this is about creating an action plan. And what you find is people get kind of excited about coming with solutions. It's quite creative. And what you need to do is you need to try need to translate that excitement about coming up with a solution to actually starting to be able to implement that solution. And the bridge is creating an action plan. So when you have everyone in the room, you need to start saying, Okay, well, what are the specific steps that will help us achieve the solution? And if you've got or you've created solutions in relation to each root cause strand. So you've got a solution related to people, you've got a solution related to systems, you've got a solution related to capability, whatever it happens to be. You need to start to drill down into each of those solutions and define your sort of project management plan that you would need to go through to implement the solution that you're looking for. And you should do that in the room with the people who help you solve a problem, because quite often, they'll be the people who help you implement it. You might need to bring in a sort of project team to deliver, but quite often, it's those people that are there. So the last stage of your a three thinking approach is really looking at how you how you plan and structure the task level, milestone based activities that you can deliver that will help you implement your solutions and that, in a nutshell, this a three approach, so just really super quick run through again for you. Stage one, what's the problem? Why do we need to spend time on it? Why is it worth spending time on it? Stage two, what's the current state? Stage three, what's the future state that we want to create? Stage Four, what's the root cause around why are problems happening? Stage Five, what's a short term immediate ethics? Stage six, what's a long term solution that we can implement? And then stage seven, what's the action plan that will get us from where we are now to the long term solution that we want to implement? So that's a three. There we go. Wow. I think it's I was just thinking the one thing that probably doesn't come up, or maybe to add on to what I was thinking earlier about, you know, we were talking about who's not in the room, yeah, and team leader, quite often, is one of the reasons that's really effective is because someone's usually got a resource the solution, yeah, someone's usually got to sign off budget or time. And I.

The challenge. But the benefits not having that person in the room is you get quite an organizational approach, so they're going to be a bit independent. But the challenge of that also is that you've got to be really clear how you can sell it, because quite often, if you've been in the room, you understand how you've got to that solution. But So capturing that process is really important, capturing stage one to four, so that people understand why you've got to your chosen solution. Is really important. Yeah. And throughout the whole activity in the room, somebody should be capturing this. You know, your facilitator should be guiding the conversation, but there should be somebody in there actually documenting this in a concise form that you can share with people. I'd agree.

So what you've done then is you kind of got to the stage where you've got your action plan, and everybody's in the room and everyone's happy, and you're going to solve a problem, and that's good. And then you know what? The meeting comes through its end, and everybody goes back to their desks or wherever they are, and that's when, to be honest, the work really needs to start.

So the last stage that I put into this overall problem solving higher level processes, you need to actually go and implement the solutions. So if we step back a level, we talked about identifying problems and opportunities, about prioritizing them, about getting the right people identified to help you solve them, about solving them. But now we need to move on to that last stage, which is actually implementing the solution. And quite often, things sort of fall down here. You've got your solution, but you know what? You've actually got to do the work now, and that's been work now, and that's a bit harder to do. So there are just a few things, but I wanted to call out to make sure that, or to help people make sure that they can actually focus on this stage. So, you know, we've captured the actions. That's great. We've done a bit of action planning. What needs to happen is that action planning needs to be translated into a live plan. So you need to have your actions on a plan. You need to have owners against each of your actions. You need to have due dates against each of your actions. You should get statuses against them. So sort of red, amber, green, project management type status reporting for different actions. You can track those against the due dates that are in there. You'll create that into an actual plan that you use and that you circulate, I try and make it visible. I think that's a helpful thing to do. You then need to track progress over time and get people to work as a project team to deliver this. So potentially, have a weekly or fortunately, check in. And by doing that, you can help next year that work's actually completed. And the thing that really stands out for me in all of this is, if you're the leader, and if you've not been in this room,

or whatever your relationship is, if you're in a position to do so, you need to give people the time to work on these prioritized problems, right? So you know, if you've asked people to solve a problem, they need to have time and capacity or resource to do it. Otherwise, they won't get it done. So that's really key to being able to implement your solution. And the other little piece around solution implementation that I touch on is that you need to say thank you to the people working on the problems, and you need to help them celebrate the successes. You know, the small steps that they make, celebrate those demonstrate that things are being valued and that they're working, and that they're working and help trying to build some of that momentum so people feel positive about the changes that they're making. And those are the sort of high level points of me around implementing a solution. There we go. Wow. Everyone should be able to solve all their problems now. They should be. I think they probably can. I think we can probably stop doing any more podcasts, because I think just with this, I'll be able to fix anything else that's out there. It's like we've taught them to fish or something like that. Ah, look at you. Okay, well, that's I give me some food for thought. Actually, some there's a while since I've looked at some of that stuff, and actually been a while since I've done that kind of session as well. So because I haven't had an operational team for a little while. So it's funny looking back and thinking how

well, it's interesting, because if we move on to the list of the week, yeah, the things that I was thinking about while you were talking other things that were on the list of week, but I hadn't, kind of clicked, but how important they are, yeah, just before we do list of the week is you talked about operational teams. And this is powerful in operational teams. And obviously it leans an operational process, but I think you can translate a lot of this to less operational teams as well. So without Without question, I think it works at a management corporate level. I think it works in pretty much other functional teams and back office, I'm not it's just that I happen to be in operations when we used

it. But absolutely, and I think one of the reasons that becomes really clear is the things that you put down on list the week which I'm going to share, because I think

these are, these are issues, things to watch out for, that happen every time you try and solve problems in any environment, in any context,

they show the importance of a process. Yeah, that's interesting. Cool. Yeah. So list the week this week is James put together five things to watch out for when solving problems. And as I say, for me, this was a real I don't know.

Because it is all the reasons that I have always been drawn towards having a process for problem solving, even when people have told me I've over engineered it. And it's why, it's because these things happen every blinking time. So number one things to watch out for jumping to solutions, right? And that might be the first one, because everyone loves it, and then no one's got the guts to say, I don't like it anymore, or it might be, the most senior person has come up with solution, and a process then gives you something to be able to challenge up with a jump. Just watch out for jump solutions. There is nothing worse than being in a room and watching the most charismatic, intelligent person come up with a solution, and everyone going, Oh, that would be brilliant, because he said it Yes. And then you can just step away from anything, and oh, and then you just not gonna get anything effective or meaningful out of evaluating that solution. So second, number two, solve. Don't solve the wrong problems. And this is really why root cause analysis is so so important. And, and it's interesting, when you were talking about the first stage of a three thinking, which is, you know, get everyone to talk about what problem they think they're trying to solve, and they will all be different, because quite often, I have seen people spend a lot of time and money solving the wrong problem because they actually haven't got consensus at the beginning of even what the problem they're trying to solve is. So that's huge. Number three is creating solutions that cause problems for other people teams. And I if I could, and if I had something, I would bang my head against the wall right now the number of times, and I know you meant when we were talking earlier, you mentioned before the podcast, you mentioned this has happened to you, and I hadn't really tweaked how much this has happened to me in a different context, but creating solutions that people do not understand impact other people negatively because they haven't thought through that impact across the whole organization.

And I see this consistently with board board members who think they've solved a quick fix of something, but it's ends up with a load more work for someone else because they don't really understand how things work. Yeah, and I have seen it with pretty much every member of my team who's who's come to me, going to look, this is what we're going to do. And I'm like, Well, you're not going to do that because comms will never speak to you again. Yeah. And they're like, but it's the right solution. I'm like, it's not the right solution if it only works for one department. I don't care how I don't care how effective it is if we're going to any other department working with us. So I love that number three clicks, as I say, create solutions to cause problems for other people. Number four asking teams to solve problems without giving them the time to do so. And I would add money. Yeah, time and money cannot stand leaders who think that just because they've got clever people in the room, they should be able to fix everything in the organization without giving them the time, the energy, the effort and the resources. And by the way, that means sometimes taking the other work off them. So giving them time doesn't mean saying, Well, you can work on it all next week, but I still want all your other stuff done. And then number five, failing to pass on the benefits of problems to the people that solve them. In a really practical example, that would be when someone figures out how to make a process that was costing the organization too much money, cheaper, and they don't get any benefit. So they don't get any

any reward for solving that problem. They don't get any more time to work on anything else. They don't get any of the budgetary savings to put into their own work or into other solutions, recognition, even to powerful or recognition. What's that about? Why do people always insist on saying this team did it? Sometimes you just need to call out the person who figured it out, and it won't always be the same person. Yeah? So I think this is a really strong list, and I think it's a really important list for being able to advocate for why you need a process. Yeah, I think this is the list you put in front of senior leaders quite often say, This is why we do waste your time, as you say, and not just jump into the first solution, because quite often it's the wrong one, and it costs you money, so just to run through that again. Number one, jumping to solutions. Number two, avoid solving the wrong problems. Number three, avoid creating solutions that cause problems for other people, or teams. Number four, avoid asking teams to solve problems without giving them the time, money, resources to do so. And number five, don't forget to pass on some of the benefits of the solution to the people that have created that solution. Great.

This week. It's great, cool. One of the things I say around passing on some benefits, it's a funny thing, but I think it's really powerful, is that sometimes a benefit of stuff is getting more interesting work to do, right? I mean, like, people want to do interesting stuff a lot of the time, so if somebody saves time, then free them up to work on more interesting things. Is one of the things I think about from passing on benefits anyway. That was a little possible. Well, let them work on more problems if they've enjoyed it. That's the other thing. Understand that if you've got someone whose skills are in this area. In one such section, there probably be a great facilitator for the process somewhere else, yeah, and that's where you can really start to get your organization working more effectively outside of silos. Yeah, absolutely.

All right, so we are getting towards the end. We've got some time for stories. Do you want to start off? Do you want me? Kick off with stories. I'll kick off. Yeah, so James knows the

story I'm gonna tell, which is probably making him metaphorically I can't see him. Hold on. Are you rubbing your hands together with glee? I am indeed. So

I'm gonna, I'm gonna mention a story from a department, finance department that I used to and we were small to medium organizations, there were like 300 people working for it, and it was a nonprofit. And nonprofits are really interesting around budgets, because actually, you get rewarded for spending the right amount of money. You don't get rewarded for under spending right because the whole purpose of a charity is the money should be going in and out as you expect, and you should be doing what you said you're going to do, and it should cost what you said. And so if you do make savings, they should be either going back into that project. You should talk to your funders or your donors about how you do that anyway. So one of the really, really common things is that everything takes longer than people expect, and so they end up with an underspend towards the end of the year. And

this was manifesting itself by the board would get the projected budget, spend and budget and actuals right for the year in January, and it would look okay, and then they would get it in April, and there would be this massive underspend, right? And so accounting, we're getting their nail knuckles wrapped every year for like, three years, and they couldn't understand it, right? And they were like, they I was just amazing, right? So they invested money in training managers in how to manage budgets more effectively, which had a hilarious consequence, which I mentioned later. They spent loads of time rejigging the schedules. They started sending out budget updates more often because they thought maybe people didn't have good information, right? And they'd asked what was going wrong, and people have been really vague and sort of contradictory. So they were like, oh, maybe they just don't understand it. So anyway, they never really got to the bottom of what was happening, which anyone, if they'd got the put them a drink, off the record, would have told them that people were not getting the work done as far as they wanted. They were conscious that there was a rule that if you underspent significantly, your budget was going to be cut the following year. So what they would do is they would keep forecasting they were going to spend all their money, and they would make it look like it did, and they would accrue it until the point where they couldn't spend it, by which point next year's budget had already been written, right? So effectively, what you've got is a bunch of managers deliberately misforecasting or highly optimistically in University Commerce, in air commerce,

over estimating how much they're going to spend, because they're trying to protect the money for their division and following it. Now, I'm sure this happens in all organizations, but the hilarious thing is, they never got to the bottom of it. Even after I left, I couldn't believe it. They were talking about these really high level plans, and remember to check going out for a drink or the financing. You know, they know they're doing this, right? You know, if you sat them down in January, they would tell you that this absolutely is what they're expecting to happen, but they're worried about losing money. Just change the rule, change the rule, and you'll be fine. And they were like, oh, maybe I'll talk to my manager about that. I was like, please do please. Because, you know, the organization is spending a lot of money, and they shouldn't be anyway. That's my favorite one, yeah. And you know what? That's, um, that's not just in the third sector. I know, I know, but it just makes me, it makes me laugh, because they were trying so hard to help these poor, and it's a classic thing of accounts department going, Oh, they must be not number literate, yeah, of course, when they did the training, everyone went, Oh no, I really understand how it works. I can totally gamify this. Yeah, I can do it even more so from from a corporate perspective, a lot of what actually happens

in larger organizations, for ones I've been in, is the teams come up and the same thing happens, right? So there's a little bit of a desire to save money, but also a desire to protect your budget a little bit. So people do the same thing. They do their budgeting forecasting, and then what happens is, it gets submitted centrally, and then it goes to group exec or one of the big cost committees and things like that, and generally they say, Hmm, I think people have been overstating by about 7% so now we're going to go back to everyone and say you've got to cut 10% out of your budget, yeah? So it bounces up and down, and that's how it forces it its way down that way. But and that I've seen that happen, yeah? And so all I've seen the following year is someone has cottoned onto that and gone 20% over, and you're just like, yeah,

that's funny. Okay, anyway, that's mine. It drives me crazy. Cool. Okay, so then a story from my side is around, I guess, a relationship between this type of problem solving and systems thinking. And it goes back to the point that we talked about in the list of a week, which was around creating solutions that cause problems to other people within the teams. So within one of a large organizations that I worked for for a long time, there was a lot of focus on the sort of lean based process improvement and problem solving. And the purpose of this was to improve the functioning of business units and operational areas so that the organization.

Action would be better and the organization would be able to achieve its higher objectives. So some of the higher objectives that were in place were things like customer satisfaction, customer complaints, and some of those large, you know, customer impact metrics that are group wide. And what the organization found is that by delivering a lot of this sort of lean based process improvement, that lower level metrics around individual business unit performance would improve, efficiencies would improve at individual levels, and some of the you know certain things around cost would improve as a result of some of the initiatives. But that it was really impossible in our finding through this type of you know, problem based improvement at a fairly siloed level to achieve fundamental change and improvement in the, I guess, a real macro organizational KPIs in a large, large business. So what the organization ultimately ended up doing is saying that these things are great for smaller local things, but that ultimately what we need to do to achieve improvements in these really high level metrics, is to move towards a more systemic approach and really recognize that organizations are systems, and look at end to end process transformations. So instead of, you know, letting say, your ops team understand your your whatever it is, your onboarding process for a new customer, what you need to do is you sort of flip that on its matrix and think about your your customer journey as an overall process, and then focus on that, I guess, horizontal work stream, and consider your whole customer journey as a single process to be assessed and modified by people from all the different areas that affect your customer journey and that by looking at the more systemic approach like that, and looking at your end to end processes, that it's possible to achieve a better outcome for your higher level KPIs. And so that's a bit of a convoluted story of the week. But the message there is that these things, problem solving methods, are great for local things, but when you need to do something really, really macro, you need to think in a more macro way, and you need to pull the different strands of your organization together so that everyone's working in

in a constructive and aligned way to get the best out. Yeah, and for me, that's why. And I know when we talked about strategy in the last series, we've kind of undenied about how, how important it does, and how, you know, over complex it can be, but it is why the whole organization needs to be on board with the same plan, absolutely same strategic plan, because if they don't, then all of that system thinking won't work. Yeah. There has to be a shared context as an organization, and there has to be buy into that. Yeah, yeah. And so when I was speaking about those high level metrics that we're talking about, things like, you know, customer complaints for large financial services is a really high level objective that you want to get right, particularly where, you know, things have been hard in financial services for a while in terms of some of the customer things going on out there, I think generally, any service that provides to a large sector of the population.

The benefits of economies of scale in processing have hugely damaged what the customer experiences. Yeah, and I don't think banks really. I know banks get hard rap because it's about money and it's people's people get very nervous if it's not done well. But generally, customer service, you're not in Europe, you're not in your you're not in your own customer services. There's a lot of it out there. Yeah, yeah. And actually, interestingly, one of the things about the unintended consequences of problem solving and creating problems for other P teams is absolutely around customer service. So you know, oh, look, we've got a brilliant way to make save loads of money and managing our customer there. You haven't, yeah, you've done is outsource the work to the customer. And I think you were, you were talking about this the other day, yeah, but it drives me crazy. It drives me absolutely crazy. That is not an improvement. It's cheaper, great. It's not an improvement, yeah? And it's a short term, short term, unhelpful. Yeah, and you've then had the W complaints team, by the way, yeah, exactly, somebody else's problem. I know it's just shifting the problem around anyway. All right, panel folks, yeah, I get that. I get what you're saying about that story. And I think it's something I've seen. I probably don't have metrics on it, but I've definitely seen it. Yeah, it's just worth keeping in mind for anyone out there who's thinking about solving problems, you know, it's a big picture piece.

All right, any final thoughts or top tips my lab too? Yeah, go for it. You're allowed to. Okay, so number one is about resources. Yeah. So if you are presenting someone with a problem that you want them to solve, yeah, have a really clear idea how much it's worth to you in your head to get this problem solved, because at some point they're going to need money or time to do it. Yeah. And if you are being asked to solve a problem, yeah, make sure that you are really clear about the person who's asked you when you're articulating the solution, how much it's going to cost in time and money. So that's in time and money. So that's fine. And the second one is

start the process in the first place. All too often, I see problems that have existed for ages, and people don't know where to start, so they just and they think that there can't possibly be a solution, so they don't, and it sits.

In teams like this cancerous experience, where everyone knows there's this thing that's not working, and everyone's like, where do we start? How are we gonna solve it? Who's gonna listen to us? I'm just not gonna do anything about it. So those are my two get started and do something about it, and use this process to kick it off and do resources, resources, resources, resources. Yeah, yeah. Cool. And mine's really aligned to the resources one, and this is for any leaders out there looking to make changes. If you're going to do this, give people time, that's all I'd say, right? If you want people to make things better, then you've got to give them the time to make stuff better. You know, just asking them to do it on the side of our desk might get you a little bit, but ultimately, it'll lead to a bit of resentment, and it's just, you know, it's not fair. Sketch the in

schedule in regular problem solving sessions, I think, is crucial. Yeah, it's part of the job. Not, not an add on, like you say, I was chatting, um, one of the organizations I was at, we had one of the big four consultancies, uh, being a professional services firm, doing some work around process improvement. And we were chatting about, you know, what normally goes wrong, what? What's their experience? And they said, people just don't give time. That's the biggest thing, right? People just don't allow time for it. They expect it to be solved without any time. Well. And the thing, I mean, you know, if I'm sitting, no matter what level of the organization you are, if you're sitting at your desk and doing your day job, and something isn't working, and, okay, it's not making life easier, but it's not making it horrific for you, yeah? And someone says, solve it, but on your own time or find time, yeah. Why? Why would I do that for you? Yeah, because what for the love and the good of the organization? Well, you know you're gonna that's gonna run out at some point. It will run out, and people might enjoy problem solving, and they might have goodwill, but you got to maintain that, and it's not, right, cool, all right. Well, I think that's us. I think we've done a little bit. We've run through some definitions, we've talked about an overarching process around problem solving. We've done some specifics on the A three methodology. We've We've shared a list around things to watch out for when you're solving problems. We've shared a couple stories, a few final thoughts, and I think it's just time to check out. Wow, is it time check out. Well, so don't forget you can see some of the information about this process on the website, and you can follow us and say hello to us on Twitter, yeah, at the WoW podcast, get in touch. Tweet. We'll be there, responding away, responding away, tweeting, probably with word

phrases like resources, resources, resources, exactly explanation, or what's your return on investment, which may become a thing I need to find out. Like, if I can find some internet thing for return on investment, there's got to be some gift or something. Yeah,

okay, so in which case, it's nothing more but say goodbye and see you next week. From me, yeah, and goodbye from everyone. Bye. Hi.