Episode Transcript
[00:00:00] Speaker A: If you have a good structure, if you have good KPIs that cascade through your organization, then that's going to be a leading indicator that's going to help you to understand the when a risk could happen. Rather than developing a department to catch bad products at the end of the process and then having to mitigate that or having to react to that, is
[00:00:21] Speaker B: that welcome to why they Fail, the podcast that pulls back the curtain on why continuous improvement efforts fail.
Buckle up because we're not here for motivational fluff. We're dissecting the short sighted decisions and leadership agendas that sabotage CI success. But don't worry, we'll clue you in to the few simple keys to success to avoid these pitfalls. If you're ready for the truth, let's do this.
[00:00:56] Speaker C: Welcome to why they Fail.
Today we are exposing a major corporate illusion, traditional risk management programs that burn millions of dollars only to end up as rubber stamp checklist exercises. If your organization is relying on quarterly audits to catch failures after the fact, you are simply driving, looking exclusively through the rearview mirror. Joining me today is Joanne Braunish, a risk management specialist with extensive experience across financial services, economic research, accounting and operational governance. Joanne is also the author of the book Risk Management and Key Performance Indicators where she breaks down how organizations can ditch reactive compliance traps and connect leading operational metrics directly to real risk exposure. Get ready for an eye opening conversation on how to break down departmental silos and build proactive risk management with KPI and apos that actually protect your bottom line.
[00:01:58] Speaker A: Joanna so what was your catalyst? What got you into this methodology and what you do now? Tell us about it.
[00:02:05] Speaker D: Well, I started actually in risk management in the financial services industry.
I created a risk assessment and I worked on the governance system that went along with it where they would keep all their documentation.
And so I was familiar with the framework for how a risk assessment could be created. As I worked through this, the first thing I realized is that companies, be they financial services or even public, were putting a lot of time and money into this. Especially when Sox first came out, which was in the late 90s, companies were putting, particularly even the public companies, were putting millions of dollars and resources into risk management. And as I worked on it myself, I realized that one of the things is risk management is only reasonable assurance that you're not going to have a risk. That's the one thing that I thought about. And then as time went on and I saw how risk management programs, particularly operational risk programs, were growing with documentation and resources and systems, I started to believe that this was getting out of hand, I guess you could say. And it wasn't really providing any kind of return on investment.
I don't think it was working the way it was intended to work.
And part of the problem is with the traditional risk system. The traditional risk system relies on documentation, relies on heavy controls, relies on auditing primarily to find issues.
Well, we all know that auditing usually is what, maybe every quarter, it's semiannual, annual.
So that means you could be having an issue and not recognize it until audit hits it. So you're just compounding. Compounding. And I thought once I got out of the financial services industry, because I also had background in economic research as an assistant, I did accounting, I did operational supervision.
I thought, I believe that even public companies like manufacturing and service companies could really benefit from a proactive risk management system.
And the traditional system, in my view, was not proactive, but rather reactive. So I started thinking about it and I thought if people could align risks, their known risks with key performance indicators, it would give them more real time information as to something going wrong, rather than waiting for these auditors or regulators to come in and say, oh, you got a problem? So that was my first, the start of this. And as a result of the start, I did write my book, Risk Management and Key Performance Indicators, where I took each of the streams from product development all the way through to customer service and distribution. I took some of the major functions within the company.
I researched some of the common risks that the manufacturers or the service people would be having, and then I researched some of their key performance indicators and I tried to match them up to say, well, if I saw a key performance indicator going outside this target, what risk might it indicate to me that I might be having that I need to control?
So that's where I started with it. Then as I kind of started going on, I realized that the culture in companies doesn't always match with the idea of a risk program.
Meaning. And Kevin, in your book that you have about why things fail, why they fail, it was interesting to me that a lot of the things you called them, sometimes a little bit different than I call them. But basically we were saying similar things, like there was no tone at the top. It was like the flavor of the month. People thought of it as. And people just didn't put importance to it. A lot of times it was just in what I saw in risk management. It was becoming no more than a rubber stamp as the quarter came. I gotta do my risk assessment. Oh yeah, here it is. It looks good. I read it. Bam. Rubber stamp. I signed it. Nobody was getting any value from it. That's why people really never took the time to look at it as they should.
The other interesting thing I found is everybody is talking about just tone at the top for these things. So I thought to myself, what does that really mean? I did some research on that and it was interesting because it talked about tone at the top by itself was not sufficient for projects to succeed. Tone at the top was more the top management, who are far removed from the processes, actually saying, we think this should be part of our culture and part of our strategic goals too. It should be, but then they remove themselves from it. The second piece to tone at the Top I found in research was really the idea of leadership, which is different than tone at the top. Leadership is the person that they would give it to to implement the program and make sure it's going and get teams and so forth together. So it's almost a combination of the two for success. It can't just be one. If I got leadership and no tone at the top, it's not going to work. And vice versa, it's not going to work. So that kind of. And I know you covered a little bit of this in your book as well. I thought that was very interesting to make sure that it had to be in the sink, if you will.
[00:07:55] Speaker A: Joanne, this intrigued me about you and the way you think. We think the same way, maybe from two different angles. In order for a company to improve, whether they improve their ability to manage risk or they improve their ability to process a service or a product, they have to have an understanding of what they're doing, their targets, their KPIs. And those KPIs have to be somewhat correlated to the health of the company at the very top, all the way down to the very bottom. When you talk about tone, I see this in a lot of companies where the tone from the top is we want continuous improvement or we want risk management. But that is then pushed down and as long as it fits their agenda, they're okay with it. So there is no alignment from the very top to the very bottom. There seems to be quite a bit of disengagement. And that's where I say is find KPIs that flow down throughout our organization. Then everybody understands exactly how they impact the company. Let me ask you a couple questions. You kind of touched on these a little bit, but I'm going to formally ask them to lead our conversation. So in my book, I talk about how 96% of deployments fail within 18 months because leaders chase a quick fix. From your risk assessment background, why do traditional programs turn into a rote compliance driven checklist exercise?
[00:09:22] Speaker D: In my opinion, it's because nobody sees the value in it. It's a lot of documentation, a huge structure that some companies, you have to have a risk management function, they have to have a gr, what they call a governance risk and control system.
Companies are putting risk managers in every function.
There's all this paperwork and documentation and at the end of the day, my question to these companies is, you've spent all this money, what have you really accomplished? What's your return on investment for all this money that you put out there? I've yet to see somebody have a big return on an investment. And I think as we look, the interesting thing is, and I got to kind of digress here, if you don't mind, Risk in and of itself is really interrelated with quality and inefficiency. If you look across the three and recognize that, that they're really all quite related because they're all looking at the same process maps, they're all looking at the same process, but for different reasons. Risk management has grown to a point where in some companies you could almost say that risk management has become an inefficiency in and of itself because not only the structure around it, that's really not providing a lot of value. Also in many cases it's caused controls to be put in place that may not either be the right controls, they may not even need a control, or maybe they used a manual control and they should have used an automated control. And the other thing is in risk management, when you're looking at what they call enterprise risk management, IT umbrellas a lot of things. It's technology, it's procurement, it's operational, it's compliance and SOX risk, financial risk. If you look at SOX risk, for example, and even compliance risk, those are technically looking at the same risks and controls, but from a little bit different perspective. You could be using the same control for compliance risk, for financial risk and for an operational risk. So now each of these people have their own risk assessments because compliance risk assessment is one, operational is another, financial stocks risk is another. So now I've got three documents, three people asking me the same questions, three people looking at the same controls, but for different reasons. And that's part of the big inefficiency of the program. Just as well is the redundancy in how these things overlap.
[00:12:04] Speaker A: Kind of looks like over time we've built in or risked a department that has become its own silo, its own entity, and it's kind of broken off into different sections, but it looks like we're doing something just to do it. A lot of what you talk about is really encompassed in our everyday actions rather than taking on a risk. I don't know, different part of the company.
[00:12:28] Speaker D: Well, I understand, particularly in financial services and in some private industries as well, public industries, that there is the regulatory compliance piece and it is significant and you do have to make sure you do it. But my take on it is that as a function, you could be still handling that through key performance indicators and instead of waiting for, let's say in the financial services industry, the Office of Currency and Control to come or the Federal Reserve auditors to come. Auditors.
[00:13:01] Speaker A: I just said a podcast with a gentleman and we were talking about end of the line inspection. Happens a lot in manufacturing. And that's kind of what I see as this risk as you're explaining it. It's kind of end of the line. So bad things have happened. Now we are having to catch them and then mitigate them. But you're saying, just like in continuous improvement, if you have a good structure, if you have good KPIs that cascade through your organization, then that's going to be a leading indicator that's going to help you to understand when a risk could, rather than developing a department to catch bad products at the end of the process and then having to mitigate that or having to react to that. Is that. Am I on the right track here?
[00:13:47] Speaker D: Absolutely. I think you've got it right with that statement. The traditional programs are very reactive, as you can see, because of the time lag. And that's why I just don't think that they should be continuing to pour all this money into the programs, into the GRC systems and so forth. Just like when SOX came out. Like I said, people spent millions of dollars to create these programs. And what did it give you?
[00:14:15] Speaker A: I will tell you that in projects that we take on, there are a lot of companies we deal with that are financial companies. And we hear a lot, especially when we're doing tools to solve a problem, that there are steps in the process that are business value added, they have to exist.
We define business value added as something that a regulatory requirement tells you to do. I always hear it in a financial project when I'm working or my colleagues are working, that we're in this project, we're doing a process map and we find a step that is Business value added because they say it sucks. And if we really let them do that, half the process would be that business value added color. But it's funny, we always go back to them and say, well, prove it. Prove that that is a regulatory requirement. And about 90% of the time they come back and they can't do that. It's just something that they developed over time. I can see where if we had a better understanding of our indicators, it would make us less reliant on catching things at the end through these different regulatory systems.
[00:15:23] Speaker D: Even if it's not a regulation, people put controls in place that maybe don't need to be are. It's just draining the resources and the money and the productivity levels by doing that.
[00:15:35] Speaker A: You coined an excellent phrase about organizations running in mud because departments operate in complete silos. How do we stop quality, risk and continuous improvement teams from looking at the exact same process through entirely different lenses?
[00:15:51] Speaker D: Well, that's not really an easy thing. I'm just starting to investigate some of that. But the first thing is everybody, every function, has to understand not only their old risks, but what other functions are they relying on and what risks within those functions could impact them. That's an important point that people have to understand to be able to do this. You can't just be looking at I'm in the floor in manufacturing and that's all I care about is these risks that I machine downtime or whatever. But what about the procurement people who have to do the supply chain? What kind of risk they have that maybe might impact what I'm doing? What about HR or what about sales? Are they giving me the right data so I know what my production schedule should look like between market and. The interesting thing is I got to kind of regress here. I've tied quality, risk and inefficiency all to what I call the internal tax rate for a company. Because the internal tax rate in essence tells you how efficient or inefficient you are. The norm that I found was generally everything. The industry Standard is about 15 to 20 cents for every revenue dollar is the industry standard for the internal tax rate. Anything much beyond that is saying you're starting to move toward inefficiencies. I've tried to look at all of these things. The inefficiencies, the qualities and the risks all is part of the internal tax rate. I'm starting to find all of this is so interrelated that it's becoming. The internal tax rate in and of itself is a lagging indicator. If you're already telling me that you're at 30%, well, you've lost the game. What you really want to look at is the key performance indicators that cover these risk, quality and inefficiencies, those that feed up into your lagging indicator, and they're the leading indicators of where you're going to be. I've been trying to research to investigate just how can we combine and get people to look at these things from a more consolidated perspective. If you take level one and then a level two process map and you start with those and you identify the critical areas of marketing, sales, and so forth, and then you do a deeper dive into those where you might have some issues. There's so much interrelationship between some of the activities within all of these streams, like, for example, marketing. One of the examples was if marketing is using a KPI of how many leads were generated or something like that.
So they're just churning out leads, churning out leads. They're giving them the sales. Sales is taking these leads and they're saying, wait a minute, only 10% of these leads are qualified leads. Now I've got a disconnect and an inefficiency which is probably part of what you would be looking at in your program between marketing and sales. What I'm working on right now is an article about how to sum up the inefficiencies that you can see between some of these functions. Recognizing that technology is probably one of the biggest where you see inefficiencies because of the infrastructure and possibly the way it's built, but they exist between sales and marketing, between technology and a lot of the functions, and even between operations and sales. All of these things have to be part of the review, and it has to be a total process flow from beginning to end product development throughout the door so that you can see these interrelationships in here. Some of them are going to be risks, some of them are going to be quality issues. And I think some of them could be the inefficiencies that are coming up.
[00:20:06] Speaker A: Joanna, we. We've really talked about this at a high level. I can correlate what, what you do and what you're talking about to what we do in improving processes. You have to understand a process or a company. You have to understand what makes a company successful, what are their targets of success, all the way down from the very high organizational level, all the way down to each person, so that as we start to achieve our goals, we know how that goal is going to affect every level above us. We know that when we do something, it's not going to go off in an eversphere, not have an effect, even though we might do something very good. But having those cascading KPIs. And I think you're saying that if we can look at this in more visual way by understanding the handoffs, the interdependencies among these different departments and what their numbers are, then it would make it easier for us to understand where we tend to have the most risk because it's not performing well to those KPIs. I see that every day. I'd see that companies don't really have that overall picture. They just have the high level KPIs. They've got leaders that are reacting every day. They're hired to be managers, not to have a vision, but to react to problems as they happen. Am I on the right track here? A very visual tool guided by numbers, KPIs, targets and understanding in real time where those things are so that we can tell where the hotspots are, we can tell where the spots are, that we're doing well. And that kind of helps us with risk management rather than waiting till the bad thing happens and then reacting at the end. A lot of companies do this as they put in these risk management functions, but those functions are really kind of checking off the box to eventually catch a bad thing after it's happened.
[00:21:59] Speaker D: Yes, that's what I had seen. The other part, which I didn't say, was once you get this audit, which may be six months from maybe this thing's been going on now for six months, let's say there's a time, once the audit recognizes it, then the department has to go back and say, okay, now we have to put in a plan to correct that, mitigate it. And then after that maybe they're given 30, 60, 90 days to get that done at the end of that mitigation period, now audit's going to come back and test it again to make sure it's going right. It may or may not be going right. Now. You've not only had your lead time of however long it's been going, now you've got another three months possibly for mitigation. And then by the time audit gets back in and decides if it's working or not. So this could be going on for quite some time before.
[00:22:48] Speaker A: It's when these lead times between the audits, because they're months, the process changes on a daily basis. To me that almost seems ludicrous because you have a lagging process that is not going to catch the changes that are happening. So this sounds so much like what happens in manufacturing. You're making a widget, you're making a part, you're making service or transaction in that service industry, and we don't catch it till maybe a couple days or a couple weeks later. Right? And you've already lost visibility to what really caused it. So you're mitigating at the end. But then the time it takes to determine the mitigation, that process may have already changed again. So whatever you put in place is not going to work. I see this on a daily basis where you've got qa, you've got QC in companies and very large companies, where the real problems are hidden in inventory and hidden in the process because we have such a huge lag time to really deal with it. So that that's really where my thinking in Six Sigma, that people that think like I do, to get away from catching the problem at the end, let's understand the inputs in the process that we know what they're going to create. If I'm trending towards a risk potential, I want to see it trend. I don't want to see it actually fail. I want to know that that risk is trending towards happening.
[00:24:12] Speaker D: Correct.
[00:24:12] Speaker A: And that gets back to KPIs. If we understand our processes at a more finite level to where we understand what the metrics are of each process, each person, each department, each cell, each division, then we can watch that in real time that data populates and start to understand where the trends are. And understand this is going out of statistical control. And that should tell us that we need to then react to it before it ever gets out into what's called failure.
[00:24:41] Speaker D: Correct. And that's the idea, as you say, a couple of things about KPIs. First of all, the importance of setting the targets and watching the targets. Because the target range you're going to see, let's say your target is five to ten, okay, the midpoint is seven and a half. Well, as you start going below seven and a half, you might want to start looking at that, because now you're saying, oh, something could be going on. That's where the risks and the inefficiencies can come in, or even the quality to say, okay, what is causing the slip in that target? What's the root cause of why this is happening? Is my supply chain failing me? Are my machine downtimes too great? And that's where those come in. The second piece is not only understanding some of the risk exposures that are around that, but also making sure that your KPIs, whether they're tied to a risk or not, are answering the right questions that you need them to answer.
[00:25:44] Speaker A: I had a kind of a correlation to that. When you're driving a a car, we don't have cars that have speedometers that just say too fast or too slow. We've got a speedometer that tells us exactly how fast we're going within what the speed limit is. That's what I see in a lot of companies. We don't know what we've done until we've gone too fast or too slow.
There's no, really no way to gauge on target. Are we moving at the speed that's comfortable to us. I see that in methodologies like Lean, where Lean just says go or no go, just don't make a defect. Six Sigma we really talk about capability, which is the capability to be within the target and away from the spec limits that we're getting. What you're talking about with risk management is the same thing. It's just something that's called risk management and not something like quality. But they're doing the same exact thing, inspecting in quality at the end and then reacting and then having too much of a lead time to actually react to cause any kind of a change in the process because by the time they react, something else has happened. You're always three weeks behind the real problem.
[00:26:54] Speaker C: Thank you so much for listening to today's episode. The major takeaway from our conversation with Joanne is that risk quality and operational inefficiency are deeply connected. When your risk program is treated as a separate silo, it becomes an expensive internal tax rate draining your company resources rather than adding value. Instead of waiting months for an audit to tell you what went wrong, you must implement cascading real time leading indicators that flag process slips long before failure happens. If you want to dive deeper into why so many corporate initiatives fall flat and how to build last operational alignment, make sure to grab a free PDF copy of my book why they Fail and the Simple Key to Success linked in the show notes below. Subscribe to our YouTube channel, which is a completely free way to support what we do. Make sure you are following the podcast on both Spotify and Apple so you get every new episode instantly. And please take a moment to leave us a five star review.
