Reliability | John Sewell on Fixing the Wrong Things & Making Better Reliability Decisions

Welcome to the Factory Futures Podcast! Join us as we dive into the world of innovation and best practice in manufacturing. We sit down with industry leaders in reliability, operations and production with the mission to uncover new technologies making a real impact, driving performance and enhancing profitability of your site. We explore the leadership journeys of our guests, learning from their challenges and gaining from their insights. Subscribe on your favorite app to stay ahead of the curve with our latest episodes. Thanks for listening and enjoy the show! We are now talking through his approach and his way of working when he does work with sites. We first talked about professional journey, a couple of minutes in, and then about five minutes in, we talked about the problem that he observes with how most organizations approach maintenance. We got eight minutes in talking about how you should select the right problem to solve, and there's a lot of discussion throughout on this selecting the right problem as both the symptoms, we talked about how to frame and prioritize problems that was a little bit prior to 20 minutes in. We talked about building a reliability strategy that actually works. This was approaching a 25 minute mark, and 30 minutes in, we talked about the idea of a strong business case in reliability. And we end this show close to 40 minutes on John's advice to maintenance and reliability leader, which was surprising to me, and I think it's fantastic advice. This was packed with value, I hope that you'll like it, and I find that this was especially relevant as a conversation to have at this time of the year when people are hopefully having a little bit of time post shutdown to think through what is reliability strategy that's going to work for them, whether it's something you revisit or something you do for the first time. So thanks so much for listening, as always, I encourage you to send us your feedback. And if you have questions as well this year when I try to take more listener questions, there's a few that came through last year. This year we will do a better job at asking questions from yes to, well, questions from listeners to our guests, sorry. Thanks so much for listening and enjoy the rest of your day, guys. John, welcome to the show. Thank you very much for having me. Yeah, and it was a pleasure telling this before we recorded. I have been a fan of yours for a while. I think probably about a year now is when I started following you and a lot of quality content. So thanks for sharing it and thank you for it deciding to agree to come on. I'm very pleased to be able to chat to you. Yeah, no, it's been good. It's been really good to get to know you. You're very well spoken in the world of reliability. So as usual, I'd love to share with you talking us through your professional journey. How did you get started and what do you spend most of your time doing today? Yeah, very, very early in my career started. I started working as a maintenance reliability professional and I was at a reliability conference. I had a very uncomfortable at the time. It was very uncomfortable realization at the time I was a maintenance reliability engineer at a chemical plant. I'd been there a few years, you know, head down, work in long hours, taking any kind of project that came my way. But I started to get the sense that the effort really wasn't leading to results. Like there was some, some disconnect there. And at the conference out there that I was at, I was sitting in a presentation back and I'm Hans block and Hans block. He's kind of a legend in the maintenance reliability world. And I realized just all of a sudden it hit me like a ton of bricks that I was not taking an active interest in my own professional development. You know, in that moment, I went from unconsciously incompetent to consciously incompetent. And as I said, it was, it was really kind of uncomfortable. But that moment lit a spark that sort of has ignited the career and changed the course of my, of my professional career. I started reading everything I get my hands on after that conference about maintenance and reliability. Just super eager to implement a lot of the stuff that I was reading. I started changing some lube routes that I was working on back at the plant and on paper. It was a huge success. Greece usage was down cost were down productivity was way up. But at the end of the day and in reality, it just didn't feel any better plan. The reactive work was there. The firefighting was still there. The culture was really completely unaffected by the work that I did. And that's when I had the realization that the biggest constraint for the plant wasn't technical skill. It wasn't having the right tools. It wasn't having knowledge of best practices. It wasn't even hard work. The biggest constraint and what was really holding us back was how the business decided what was important to the business. It was a decision making process. And once you see that pattern, you'll see it everywhere. I've seen it there at the chemical plan and after I left there and got into consulting in industries all over the southern part of the US all over the United States parts of Canada and even a few international clients that I've had a chance to work with. It's the same pattern time and time again. It's good people who are working very hard long hours doing everything that they can. The rat works just not getting done. It's a tremendous amount of cost and effort being put into these initiatives, but they're not being any results showing up on the bottom line. And that's really where I focus today. I work with organizations trying to improve their decision making processes so that their effort and what they want to actually do actually shows up on the bottom line and leads to good effective outcomes because what I've found over the years is that a lot of reliability problems. They're not execution problems. They're actually decision making problems. Interesting. That's a cool story. A few quick questions on that. So when you started to make that shift from unconscious to consciously competent, you said, I read everything in my hands on what. What did you read first and what, you know, what are some of the materials that that you still recommend today? Yeah, one of the first things I ran across was the Society of Maintenance Reliability Professionals. They had a reading lesson to kind of get you prepared to take the exams. Downloaded their reading list started finding all the books I could that were even related to that. A lot of Heinz block books and a lot of good, a lot of good authors from all over. Just different industries and fields. So yeah, there's a lot of good, a lot of good resources out there, but started reading everything I could for me. Less Marpee's reading the list and ended up setting for the exam and becoming a sea of Marpee there. A few years after that, just as part of my professional growth. Well, fantastic. Congratulations for that. It seems funny to me that that feels like a common story. You know, that regardless of the profession, a lot of us are in a profession where we're doing our best. But we need this moment. We need a compelling event to go like, well, you know, am I really spending time in my development? So yeah, thanks for sharing it. Where you ended is where I meant to go next with a bit more of a deep dive into the problem with how most organizations approach maintenance. You said it there that you see often so much work get executed, but then the results are not really appearing. And so I think it'll be good to dive some more into this. As a guiding question, I was thinking, what mistakes do you see that are so common that you can almost predict them before you walk into a site? Being the person that walks into many sites now, as opposed to working just for one. Yeah, so it would be good to talk about that. You have a lot of articles on your website about them. I've probably classified them into five categories, but without more context like how would you answer this question? There are some common mistakes because it's all built on some similar patterns that you see it doesn't matter the industry or are really where you're at in the world because at the end of the day, you're dealing with people, human beings, where the same no matter where you go or what industry we haven't be working at the time. So I think thanks to your question that the common mistakes, the first thing is that these aren't bad organizations. And these aren't certainly aren't bad people. What I see is that these are predictable outcomes from how incentives are set up in organizations and how real production pressures work at a lot of plants, males and minds. I'll give you a sort of a simple example. I was at a plant and I went in one day on one of my first visits and went into the sort of the maintenance shop sort of office area. And off to the side, they had a set. But you know what I'm talking about. If you've been on a plant anywhere, you know that sort of like unused corner of the office space boxes have been pushed up in front of where some vendors have come in and set some things. So half open things, people had rummaged through looking for some parts on mid nights and not before and say, you know, you end up with a lot of stuff like that, but that was over in front of the maintenance whiteboard. And I really got to look in there and it when the last time this was updated and looking at some of the numbers on there, the whiteboard had not been updated in about two and a half years way, way off on their KPIs, they hadn't been updated recently at all. In that same room, there were two big screen TVs hanging up that had up to the second production reports on them. They were using a program that was measuring what product they were producing on which line, who was ahead, who was behind rate speed, quality, red lights, green lights, all these sort of things were being up to the second updated on these big TVs right front and center in the room. The whole focal point for the maintenance team and what they talked about in every meeting was another whiteboard that was off to the side and it was their maintenance turnover board. It's where they tracked emergency work, who's on what job, what jobs are waiting on parts that were having to have hot shot or expedited in, who, you know, what job needs immediate attention. Not really the center point of the room, no one ever told that maintenance team to ignore the KPIs that was never an email or memo or some note that got passed down. No one ever told the team to ignore the KPIs, but the system made it clear on what mattered immediate action to break down Scott attention and long term improvements just simply did not. Really no surprise then that that plan struggled with, you know, high costs and downtime, the system made it very hard for them to succeed because they're making decisions that the systems designed to reward short term fixes over long term improvement. So that's really a common problem that I see across a lot of different organizations is people who think they're set up to choose reliability. They may have a mission statement, they may have a vision statement, maybe print it out, everybody can say the right thing, but in actuality, their day to day decisions are quietly choosing firefighting for nearly every job that they're working on. Yeah, I see this too too often and as a as a really simple, maybe simplistic question, but why do you think that in a lot of sites there, there is definitely an emphasis on like production metrics that are easily visible. As opposed to maintenance, is it because of the good old like production makes money maintenance spends money? Is it as simple as that? Do you think there's another reason? Yeah, sure you've always got this sort of assumption out there in a lot of places maintenance is a call center only and doesn't really provide any value. So there is a misconception I think in a lot of places that the true value that maintenance and reliability can provide, which is, you know, one of the things we out out there on LinkedIn trying to change the perception of is there is true value out there if you do maintenance and reliability correct. But yeah, some some definitely poor perceptions out there. Yeah, yeah, unfortunately, and maybe another thing that I like a comment on from you is you have said this before in talking about your experience going through this and I know you write about this often, but when it comes to misallocation of maintenance resources, why do you think that's happening? Is it because some of the points that you say there or is it because you think people don't actually really understand where the real problems are or something else? Yeah, trying to understand where problems are really is a big point. I think that sort of brings up the bigger question of what really is a problem and what is a symptom. And I think really understanding that distinction is really important not just for reliability leaders, but it's also important for anybody that's making decisions out out in business. I like to think of a symptom as maybe a simple definition is just something you can act on quickly where if you're addressing a problem that requires you to make tradeoffs and frankly to your point organizations are not set up to to address making hard decisions and tradeoffs. Organizations are set up to reward action or activity or effort thinking about that maintenance team. They're not set up to reward long-term improvement on KPIs doing those actions that may show up weeks, months or even years later. They're rewarded for being out there quick with their tools when there's when there's a breakdown as soon as that board changes from green to red. That's what that's what the system was designed or rewards you end up with a lot of in a lot of plants teams get busy chasing symptoms and I think maintenance reliability teams sometimes just kind of looking in the mirror. We're bad about that because we love buying tools the latest new tool whatever it is sending people to train and launching initiatives, but the issue is that we can do all those things without really addressing underlying constraints. Just another little example I worked with a site one time there are annual goals came out and a big PowerPoint deck and if you counted them all up, it was 48 goals for this one for this one plan was not a big plan 48 goals that way too many. It was really just a wish list. Now there was no prioritization. There was there was no alignment and what I always remembered about that other than that there was exactly 48 goals was the advice from the long term. The long tenured employees folks who had been there a long time their advice to new people was in a nutshell, danger lane, don't over commit. Now these weren't bad people, but the system made it really impossible for projects that required cross functional support to succeed. They were not set up for making tradeoffs and hard decisions and they had created environment where it was impossible to say no to anything. And that's really getting at sort of the heart of of strategy and maintenance strategy in particular is being able to identify those few important things that one or two things it's really going to move the needle. Let's go back to our definitions. That's what a problem is is going after that main constraint and it's saying no to everything else, even though it might be funner or easier or something we can knock out without involving a bunch of teams who are difficult to get along with and whatever. But saying no to projects that are easy to go after sometimes because that's again our definition that's that's a symptom and that's chasing the wrong thing. Yeah, yeah. And how do you like how do you tend to because I know you have writings about like how you craft a reliability problem statement, which it's nice to see this. I found this really interesting about you is that a lot of the things that you were writing about are like analogous to business level like creating a business type thing. Like, you know, these are all things that we did when we created a business like with the hypotheses, what are the things you're going to solve? What is the real statement? So how do you craft a real reliably problem statement for you? Yeah, building a building a good problem statement definitely is there there's some art and science to it there. As you said, it's important for anybody in business to understand, but sometimes we sort of forget the business side of of maintenance and reliability, but really just some tips on creating problem statements. You want to start with a stakeholders and have a have a big definition of who your stakeholders are. So know who you're going to talk to who's going to be impacted by the by the problems, try to get the voice of a lot of different people. Also when you're developing problem statements, don't go ask people why too soon, try to get some input into the problem without asking why sometimes when when we answer a why question, we're stating an opinion. Say it out loud, we sort of hold fast to our opinions and don't want to come off of it in the face of evidence later on. Go out and try to get some good information. Don't try to tie into everything at once. A good problem statement is going to be specific. If you can possibly narrow down on those one or two key drivers, that's really going to be the most important thing for your problem statement. Just don't hesitate to tie into a complex problem going back to that plan I was telling you about that had 48 goals, sort of a common phrase that was used at the time was they didn't want to do projects that they call boiling the ocean. I don't know if that's a that's an expression you've heard before JP that that's something like a project that's like too big to succeed. I've learned have learned over the last several years is sometimes a project that looks like a boil the ocean project is actually identifying that one thing that everybody needs to stop what they're working on and go and go do. So there's a maybe a fine line of some wisdom of don't boil the ocean, but there's also the same side of me that's strategy and really narrow in on that one important critical thing that says, yeah, let's now let's get everybody to stop what they're doing chasing these symptoms and go after that one thing that really matters. So the advice is sometimes you must boil the ocean. Maybe maybe not really. Yeah, I agree with you though this is often. Yeah, it's often there. Thinking and maybe I'm guilty of this as well, but I've with our customers often we have to to help them identify quick wins as well. So finding that balance between the quick wins and the real problems is often a problem. But yeah, we're where you began to answer the questions where I was hoping to go next, which is he really out on how to frame and prioritize problems. So if you if you have that list of 48, which is it's a funny story, but it's also a common. It's probably often a common part of the journey for for any team to. Think and brainstorm really I think in my mind is often like they've they've only done part of the exercise and haven't finished it they've identified all all the options on the table, but then they've said, you know, we're going to do all of them, which clearly no one's going to do 48 things. So how do you go from that to what are the what are the one and two things I think you you have a few frameworks that are about choosing which problem matters the most right now. And so what will be your advice if you came to them at that point. Yeah, I think just just quickly to sort of cover some of the more technical side of this is once you have a good problem statement and a good problem statement should capture the one thing that you want to fix. If you have an idea of your constraints if you're going to be you know limited by time or budget or whatever you want to have a good understanding of that when you develop your problem statement, but then really breaking that problem down and thinking critically and creatively about the there's a technique called decision trees that you can use to break down the problem into its parts and there's some different tools. The process is you can use to write good decision trees, but you want to break that down into finer and finer parts until you start identifying those things after a couple levels date that you can actually work on and you'll identify those hopefully pretty quickly but developing out your your decision tree. You can also prioritize your options and come up with some hypotheses it's not something we talk a lot about in mainstream liability it's sort of you know we might have learned the hypothesis word when we were in in school taking a science class but somehow we we get out in a plant and we you know we put on our heart hat and safety glasses and we forget that hypothesis or a real thing so I'd encourage if we go get your science book and dust it off and and check what check out what that is but basically just trying to develop some some idea. So build some scenarios around what do you think is is driving the problem and then go test and see if they're if they're true you can get some basic data do some interviews look at some some facts and figures out there and try and get a good idea of what's actually driving that problem statement because what you want to do is as you said narrow down from that list of 48 things that could possibly have an impact on the business and how do you narrow down to those one or two things that are going to have the biggest. The biggest impact in the in the time period that you've got to work with yeah I like that that's that's great and one thing that I think would be nice at this point and you forgive me if this is slightly deviating from. From the plan and but only quick comments would be super helpful is to think through if if it is true that the situation that you observe at sites is very common then presumably I'm thinking the. Problems themselves as in that the one or two things a site should decide to focus on must must also be common in itself and I think it you know as a as a general on pastry website you have them all there like run away maintenance spending repeat equipment failures on the same pieces of equipment too much unplanned down time low productivity can you can you make a comment on. A couple of them whichever one of you choose and and when you observe them what you tend to think is a good way forward yeah I think you know trying to really say this is what matters to a to a business it's really hard without sitting down and looking at some of the information to say here's what's actually going on. Because I'm just like everybody else and I have bias opinions and things that's working well for me in the past you know projects I've enjoyed so we sometimes have a tendency to bring that bias when we come into a new site or you know start a new job or run into run into a new problem. Think well what worked last time is going to work this time so it's it's really tempting a lot of times to just jump on that thing that we we think is always helpful like okay I got some PM's I need to do I'm going to do PM optimization I'm going to do our CM this time and that's really going to get it that may be. Maybe the right decision and it could be totally wrong so really just stepping back and saying what's the problem here that's actually happening what's what are some things it could be driving this problem how do I narrow those down how can I prove. That that actually is driving the problem through some some data and evidence and then focusing on those on those few key things yeah that's a good answer yeah because you. Avoided the loudest voice problem right where someone is in the room in that time and they're like no I've been here before I've solved this problem so yeah just. Yeah that's that's absolutely right that loudest voice situation is can be quite common in a lot of different places so. I was actually working at a at a plant one time where everybody from the plant manager all the way down to the front line maintenance technicians just just knew they just knew that the problem had to be PM's and on the surface that that look to be right they had low PM compliance they really weren't finding a lot of issues with their PM program they had a lot of failures breakdowns they had a lot of downtime because those those emergency breakdowns and things that were taking the equipment down so on the surface PM look like a major culprit and they expected us to come in and say okay you need PM optimization for your whole for your whole plan but before we've launched off into just rewriting all the PM's and changing frequencies just take a step back and say okay let's let's test that hot pot said if that is let's assume we were able to maybe swallow our prior a second say okay let's let's not just jump the PM's let's state that as a hypothesis I believe it's PM's can we prove it and just set up some very simple structure to test it just ask a question if PM's were perfect here with the plant get the benefit from or not that's just a simple simple question and how can you prove that we'll go do some interviews look at some data and in this situation what we found was was actually quite surprising they didn't have a PM problem they had a defect management problem they had a lot of very good very engaged operators and mechanics finding a lot of defects out with the equipment the problem was they didn't have a consistent way to to support those problems so some of the frontline technicians were telling their supervisor who would write notes on a whiteboard they had white boards out out in the production floor and they would write down notes of things that they were having problems with their equipment or things that they thought weren't going right you had other supervisors who would not use the whiteboard and they would just get right into the sea the mess and write a notification so they were you had notifications coming in that I think they were using SAP so you had notifications coming in you also had some supervisor who didn't want to do any of those things and they would just holler at a maintenance technician on the radio or catch him when they walked by on around so I think you can kind of see where I'm going here that they were finding lots of issues but they had no consistent way to prioritize or get that work done so what happened was the reason you said loudest voice kind of brought that story to mind maintenance was responding to whoever was complaining the loudest that's that's just what was going on so a lot of good work important work things that weren't urgent at that very moment the things that we're going to take them down eventually those those kind of jobs were falling through the cracks and that was a big big issue for us and that's really the power of I think a good structured approach if that plan had pushed forward with PMO PM optimization or a reliability center maintenance or whatever PM program that they had deemed necessary they would have spent a bunch of time it would have been very expensive and frankly at the end of the day they would have been disappointed with the results power a structure just as simple as the one I explained helps prevent organizational bias organizations just made up of people human beings and we all have biases having those structure helps prevent that bias and and hopefully helps you prevent some very costly mistakes as well yeah that's good that's such a good story yeah very interesting you mentioned a couple of times there as well doing these internal interviews that you do talked about like defining the stakeholders that are present in any situation so I suspect that what you're doing here is those stakeholders are the ones they get interviewed and it's a it's a pretty casual process is that about right that you you need to get interviews and production from maintenance multiple different stakeholders not just the one team yeah I think sometimes we you know if you're maybe an engineer type or HR we think it's an interview it's a formal set down come set in this chair I'll sit in this chair you know I look across you don't over my glasses with a legal pet now it's it's usually nothing like that it's it's just getting out put your boots on put your hardhead on safety glasses go talk to people and I just for a short hand use that as an agent but what I mean is just go out and chat with folks and they you'll you'll learn a lot more standing next to the equipment with a good operator than you will then any conference room anyway so I'd say yeah it's it's most of the time that is a formal as it sounds with interviews and stakeholder analysis and all this it's it's mostly identifying who you need to talk to and just going out and engaging with folks okay that's a good five yes we've got a few quick sections to go through before we wrap off but I think this one's only going to summarize a few of the things you said it seems to me that a lot of the the points that we discuss now are bringing us to a reliability strategy that actually works you have probably most of your writing I would say is probably around this what would you say what are the reliability activities that people should stop doing which ones people should double down on I suspect that's what strategy answers effectively what is what is you thinking there yeah yeah that's that's exactly it that the heart of a good strategy and it's it's a good question so the answer on what should I stop doing or what should I you know do more of the answer is it depends although probably not in a way I think most people would would appreciate my simple answer that may may raise some eyebrows potentially with your listeners is if you're going to stop doing something stop chasing best practices just just stop a lot of organizations collect best practices like they're collecting something important you know a little a little PM optimization here a little RCM there a little bill of material cleanup there you know a new CMMS tool there but they do all that without a clear consistent coherent strategy and and all those efforts and activities they are they are not necessarily going to add up to the outcomes that you actually want to see so a reliability strategy has to start at a higher level so first you have to understand what the business is all about no maintenance department exists purely for itself you're you're you're doing some activities to support a larger business what is that business trying to do what are what's important to them is it throughput making as much product as they possibly can as fast as they can is it costs we've all been in industries before we're cost is a major issue and trying to keep cost as low as possibly can is it risk that they really did they really want to do everything in our power to reduce the risk and you have to have a good understanding of that build a good maintenance for my ability strategy and how all that maintenance for my ability is going to support the overall overall business business strategy second you really need to be able to honestly assess your own capabilities and gaps and that's very hard for most organizations to it's hard for me to look at the mirror and say what what am I good at what am I bad at it's it's hard individually it's hard in organizations but we have to know how what we're good at and every organization's got good people who are good at doing something how do those good things support the business and how do the gaps what gaps do we have that that aren't able to support the business and of all those things that we could potentially get better at or go chase or spend money on only a few of those are really going to drive an impact on the the bottom line of the business so those kind of kind of first two points tied directly back together and then third and this is really the only time that talking about these technical activities makes any sense is then you can decide which sort of technical technical activities you want to do maybe RCM is exactly what you need to do maybe a bill material clean up and and cleaning up the CMS is the the right thing that's going to move the organization forward but you can only come to that decision after you've done the hard work of of identifying the business needs and sort of assessing where you're at currently kind of the theme that's coming to mind as we have our chat today is strategy really is is all about decisions and hard decisions require trade-offs and so we we need to have a good understanding of what those trade-offs are what are we going to really focus on and at the same time as you say what are we what are we just not what are we going to ignore for a time yeah yeah that's fantastic so don't start number three and that's exactly right is a good conclusion and and suppose then as the natural way for suppose then that that we've gone through this and then we we are we have certainty but we have like really good reason to think that we have found our priority what about a business case for such a priority because then the points always going to be made to be the same that you know we know we need to focus on his reliability but we can't get the funding for yeah yeah the the business case side of reliability it's always can be tricky for people but at the heart of every successful reliability business case it's a very simple formula and the formula is opportunity minus cost equals net benefit that's all there is to it it's it's one subtraction operation is really all you have to do the math is is not complicated the key really is how you define those parts of that equation and starting with opportunity that's one I think a lot of people really struggle with and maintenance reliability opportunities have to be presented in a good business case they have to be presented in a way that is important to the business so you have to tie your opportunity what what is the size of the prize out there you have to tie that to something the business cares about and it's undoubtedly going to be something like throughput or cost or capital or risk one of those four probably not a maintenance metric don't present over liability business case in terms of rich time or oe or some we speak these languages in our maintenance for liability groups all all the time and we know what that means but if you're going to do a business case and show ROI or return you have to be able to to speak in terms of what's important to the the business at large on the cost side it's a little more straightforward than opportunity but it's implementation and sustainment cost that's really the only two types of costs are so what does it take to get this project started maybe it's some training maybe it's some implementation costs there but also the sustainment cost what is it going to take to to sustain this change long term and those could potentially be much larger than the implementation cost so once you have the opportunity sized and something that's important to the business and the cost you just subtract those two when you're left with the net benefit which can be shown really in any any way that the business likes to see some of the ones I've seen or like payback period or our NPV you know you've got these these sort of financial ways to show the net benefit but really what's important I want to stress is that the clarity you're providing is much more important than the final number at the end of this equation. It's sort of math with a heart and ahead the power of a good business case is the conversations you're going to have with your team as you go and build it. Just give you a quick example I work with a client one time who was trying to get some investments from their senior operations team around maintenance reliability. They wanted they had some good ideas they wanted to get basically funding to carry out some of these good ideas so we sit down and we built a very simple straightforward business case around hiring a planner and so the opportunity size then we looked at the amount of reactive work that they had and how much of that they could realistically avoid by better planning and scheduling so kind of a good clear wage just quantify how much is planning and scheduling worth to us. And then on the call side that was very straightforward its salary benefits you know ramp up time to get the new planner up to speed and then we were left then with the with the course and that benefit that was related to the time of of doing all these activities. And so the math really wasn't you know wasn't difficult but I said in the meeting when the team presented that they're sort of findings to the operations leadership and it was amazing to see the the shift in the conversation. The conversation started with well should we hire a planner and that was the question sort of at large but by the time they got done showing their their business case and how much return there was potential. They the conversation shifted to do we need to hire two planners and how soon can we get started so that's really the powerful aspect of a business case. It's not just a number it's not a dollar sign over time or some relation to time when you get done with your spreadsheet it's having a chance to talk through a lot of what the value is to the to the larger organization. A good business case the point is not to show a final number it's really to align decisions around the right things to do and that's a good miss case I've seen it happen in real person they are effective that's it's a very relevant one I think especially as you know this time of year people are thinking about the formation of their teams for the next year the planner near the first reliability focused fully reliably focused engineer these roles are. Are important to a site yeah it's it's good to hear you say that good planning would would be a business case around it so thank you very relevant example say I think it's a last section just love to often we do this we we go a bit wider and we followed a great path and it was all very logical if we just go wide again and talk through just advice that you have in general for reliability and maintenance leaders which is another area that you know you've you've got a lot of writings about yeah. That's just a final advice listener one piece of advice to a new reliability leader walking into a messy side i'm what would you want to say. Yeah I think the single most important thing I'd say to somebody coming into a messy side is don't rush into fixing anything quite yet when you when you come into a new side there's a there's a lot of pressure to act that's probably what they've been place in value on for for some period of time to get into the situation there at activity action. Movement that's what they that's what they've placed emphasis on and as somebody knew enter in a site like that even like me as a consultant coming in there's a lot of pressure to start doing start having me start changing start doing p.m. Launching into some sort of initiative but I think the advice is slow down and take time to actually uncover what's what's going on in a place like that you want to understand what the business cares about and actually what's driving some of the problems that you're really having at a site like that sort of going back to my story you want to understand where the effort versus effectiveness is located and you want to spend your time on the things that are going to be ultimately effective once you're clear on on what actually the one thing that needs to actually happen. I'd say focus the entire organization if you can in that one one spot and then drive action from there you'll get results and those results are going to then lead to. You've been able to do bigger and better things but the clarity that you can provide from sort of an outsider coming in is is invaluable and that that carries a lot of credibility so use that credibility then to as permission to start making real changes at the site. Excellent fantastic I didn't think you were going to say that which is nice a few times you surprise me yeah absolutely so well I'll say here now thank you so much on super super relevant. Yeah very good very good thinking that you have especially relevant as we get to this time of year to think at this level where can listeners find more about your you know your methodology if they're interested in what they heard today. Yeah I think I'm active on LinkedIn so if you go to LinkedIn and and search for john soul s e w e l you'll find me their own LinkedIn. You can also check out my website JS inside consulting dot com and there you have a chance to check out the inside library I've got a place to sign up for our newsletter encourage your listeners to do that and also if you if your listeners are listening here in real time they can visit with me in person we're going to be at the reliable plant conference in. June 16 through 18th 2026 in Reno Nevada we're also going to have a booth number nine 25 I'll be having one of the learning sessions there I'm talking about means for liability strategy and how to have a strategy that survives turnover and all the changes that are going on out in the world so. I come check out the talk and visit us at the booth that's also fantastic very good topic to talk about because lots sites of a lot of turnover so yeah that's that's awesome well thank you thanks so much for making the time to speak with us hopefully listeners can find you there and you know after that's done and in your future love to have you back for for take to where we talk about some of the other things you've been writing about so thanks again so much john and you enjoy the rest of your day absolute my pleasure thank you. And that's it for this week's episode folks thank you so much for listening in and tuning in if you enjoy the episode and think it would be valuable to anyone else feel free to give it a share on LinkedIn and feel free to subscribe as well on your favorite up enjoy the rest of your week.