
Good intentions, bad outcomes
A podcast about challenges and practices you might encounter in the workplace... things that were intended well, but have outcomes that aren't so great. In most cases, the organizations aren't even aware of how bad the outcomes are.
Every episode we discuss a situation that has something wrong with it: the what, the why and what can be done to address it.
Good intentions, bad outcomes
When Business Cases Go Wrong: The Danger of Manufactured Numbers
In this episode of Good Intentions and Bad Outcomes, hosts Gino and Wayne explore how organizations' well-intentioned financial approval processes can lead to unexpected negative consequences.
Wayne shares a real-world example of a project where financial justification documents were created with manufactured numbers to satisfy process requirements rather than reflect reality. They discuss how this common practice can lead to poor resource allocation, wasted time creating meaningless documentation, and potentially harmful business decisions.
The hosts offer practical alternatives including:
- Implementing shorter funding cycles with regular benefit verification
- Expanding the definition of "value" beyond just monetary returns
- Using throughput accounting instead of traditional cost accounting
- Creating metrics that don't solely focus on headcount reduction
SUBSCRIBE for more episodes that reveal how good intentions can lead to unexpected outcomes in the workplace!
Contact us at feedback@goodintentionsbadoutcomes.org
[0:02] Hello.
[0:03] Welcome to Good Intentions and Bad Outcomes, a podcast about the challenges and practices that you might encounter in the workplace, where good intentions have unintended and often unnoticed consequences.
[0:14] I'm Gino.
[0:15] And I'm Wayne.
[0:18] And every time, we share a situation that we or one of our listeners have seen in the workplace that is somewhat challenging. We discuss the what and the why, and we try to come up with alternatives on the spot.
[0:31] So let's get started. Today, Wayne brought us a topic. So Wayne, go ahead.
[0:36] Well, you know, it's interesting you mentioned that, because as we were talking about this, it brought to mind a time when I worked with an organization that wanted to spend their money the right way. And of course, nobody wants to put down lots of money on a project that's not going to go anywhere or doesn't get the results that they want.
So they put in place a process—like many organizations have—to take ideas and vet them, review them, and come up with a benefits realization document that describes what money is needed, how it's going to be spent, and what return is expected. They put together this process and ran all of their projects through it.
[1:18] So the one fairly big project that I was on had all of these documents made up, and we got our funding to go ahead and started working on this project. But there were some unintended outcomes for this process.
[1:36] Well, we'll get into those in a second.
[1:38] So, if I understand correctly, the intent there of introducing that process is to make sure that the money was allocated where it made sense for the company, and as a result, the people were supposed to come up with some kind of benefits analysis, if you will, to justify that spending.
[1:59] OK, so I mean that makes sense, right? You're like, "Yeah, what could go wrong?" So tell me, what did go wrong?
[2:08] Well, on this particular project, it was interesting. We were probably about two years into it, and I got talking with the finance guy who was actually responsible for writing up the numbers piece of the benefits document. We asked him, "How did you come up with those numbers?" And he sort of sheepishly admitted to us that he just made them up, more or less.
[2:32] And we said, "Well, how could you possibly do that?" There was some pressure from some executives to make sure that this project happened. So what he did was he manufactured some numbers. They were not necessarily wrong or misleading, but they weren't necessarily based on fact either. So he created a document that would help them justify going forward with this project.
[3:01] Yeah, I find your definition of "not necessarily misleading" quite interesting, but yeah, let's leave that where it landed.
So yeah, I mean, there are definitely a couple of challenges there, right? I see this every single time when people are pushed into a certain process to achieve a particular outcome—and the outcome in this case was making sure that money was allocated in the right place—that they kind of fall into a compliance mode where they, in order to get their things done that are... I'm sure that they meant it well. I'm sure that they really believe that those projects make sense, and they just needed to figure out how to use this system to get other people in line as well and supporting their case.
[3:56] And the problem with these things, of course, is that at the beginning, when you're starting a project, those benefits might not be that clear-cut. It might not be so easy to calculate them. And oftentimes those processes that are introduced require quite a lot of detail—detail that nobody can produce in all honesty. But because they're expected, people will make something up so that it looks like, "Oh, hang on, we spend a million dollars, we get three million in return—no brainer. Let's give that money," right? So that's essentially what happens.
[4:36] And I don't think that in this particular case, or in many of the cases I've seen in the past, anybody was approaching it with ill intent. Like they didn't mean to try to do something that would hurt the company or that was bad, but because they felt some pressure to conform to this process and they were asked to try to make this thing work, they gave it their best shot to make it work.
But it always made me wonder, you know, what if this was really a bad idea and they shouldn't have spent their money that way? Would that person feel empowered enough to put up their hand and say, "I can't make a business case, but it doesn't make any sense. These numbers don't add up, and I think we should just not do this." Is that an option?
[5:14] Yeah, and that would be entirely off the topic of this particular podcast. But yes, that is a problem, and there are other challenges there as well. But let's just assume that that isn't the case and it really is with good intent, and the executives really do believe that this is a valuable project that needs to be funded—whether it's the executives that provide pressure or the pressure just comes from a personal passion that they really strongly believe that this is a good project.
So I will make sure that I fit within this process and we can get the funding that we need. It doesn't really matter where that pressure comes from. The point is that the generation of such a document that would support the requirements or that would allow that money to be allocated is really what the challenge is, because it's not based on real data.
[6:13] So how could we go about... And obviously the outcomes or the unintended consequences are that money is badly allocated. We don't get the benefits that we expected, or if we get benefits, there are an awful lot less, and we might even lose money, right? Who knows? So all of these are possibilities, right?
You could also say that a bad outcome from this well-intentioned process is that we spend a lot of time and effort putting together a document that really doesn't serve any purpose other than soothing our own minds that we're making the right decision. It could be wasteful, right?
[6:57] Yeah, exactly. The whole facilitation of the process itself is... OK, so how could we go about this? How could we approach this differently, Wayne?
[7:06] Well, a couple of things popped into mind. I think there's kind of a fundamental flaw in the thinking that you can anticipate in detail what the final outcome of a project's going to be, especially if it's a big thing and it's going to take a couple of years. We don't know exactly how it's going to unfold or what the market is going to be like, or if we can even get the money that we expect to get or the benefit that we expect to get from this thing.
So to try and define that in a lot of detail upfront is just a fool's game. You can't really do that. So to take that approach in the beginning, although it might be well-intentioned, is not a good approach. And I wouldn't recommend it because it results in lots of the things that we've talked about here.
[7:54] Yeah, I think there needs to be a change to that. I think what you're alluding to—and I've seen it be very successfully applied in large organizations where a new CTO comes in and suddenly says, "OK, hang on, I'm not going to approve any projects anymore that are over a certain amount of money or that take longer than"—I don't know, like three months, twelve weeks or so... one hundred days, I believe this particular executive was using.
So if it takes longer than one hundred days, I need to see results in one hundred days, and those results will justify a potential next spending or next slice of the pie, if you will. And so that is a way to indeed introduce that and have more like showing that you have the outcomes, that you have the benefits that you can realize. It's not always possible to generate benefits. Sometimes it really is, you need to set up some amount of infrastructure, and that infrastructure might cost a lot, but you can try to figure out how to minimize this while still realizing some benefits, right? So that you're not making all the biggest expenses really early on in the project or in the initiative.
[9:16] So that's definitely something. I wonder if there's anything that we could do as well around this process itself—not necessarily around the time frame that we're allocating money for, but also how it's evaluated. I'm, for instance, thinking about the flawed idea that we have all those details, so why not come up with something else? Why not allow people to make a case and not require a dollar amount benefits realization at the end of the project, but be able to somehow justify it in things that make sense for the company, are valuable, but are not necessarily easy to explain in a monetary value?
[10:09] Yeah, I suppose you could create a definition of value beyond just money. And of course, there are lots of different things that are valuable. I've had that discussion lots of times with different groups. How do you define value? So if we could come up with a more rounded and encompassing definition for value, then we might be able to measure those things and see those things even sooner, perhaps, than the dollars coming in.
And in all honesty, I have seen it in business cases. It's just not front and center. It's more like an additional piece. It's secondary: "Also, these things are important for our brand," instead of putting that all the way up front because it might be the biggest piece of the benefit.
[10:52] Anything else that you can think of we could do this differently?
[10:58] Well, now that you mentioned that description of the benefits... I saw one organization that tried to reduce everything down to dollars, and in fact, they went one step further. It's dollars saved by number of full-time employee positions that would be eliminated. And it really, you know, "We stand to save so many million dollars, which is like thirty or forty full-time employee positions," and it never sat right with me that we would describe leaving people out as a benefit.
Time saved, money saved—all of those things would be great—but let's not describe the elimination of people as a benefit.
[11:44] I've seen it too. I was cringing as well when I first heard it, but on the other hand, when I went deeper into conversation with this particular leadership team, they were telling me that it was not so much about replacing people. It was more about not renewing people who would naturally retire or people who would move into another role, right? And that was more focused on this.
But I do understand. On one hand though, it can go both ways. I'm not sure if I feel only bad about that particular metric. I can imagine that it's a valuable measuring stick, if you will, because you might argue, "Well, you know, finding good workforce is very difficult to do. So if we can save time—let's say we can save up ten people's time—that means that we suddenly have ten people's time available to do other things and to invest in other things."
It doesn't necessarily mean that we are running this project to get ten people back does not necessarily mean automatically that these people are losing their jobs, right? So I think it might make sense because that seems to be something that is a metric that resonates with people in these positions.
[13:16] It could be a good intention, but it might have a bad outcome.
[13:20] Fair, you got me there.
[13:24] Just to shift direction, one other thing that popped into my mind: how can you do this differently? Well, I'm thinking, you know, if it's flawed to try to think about the cost-benefit analysis for a long period of time, I like your idea of shorter times with sooner feedback in smaller amounts. And instead of doing, say, cost accounting where we're looking at the total cost and the total revenue to calculate our return on investment, we could move to something more like throughput accounting where we're attaching a finance to a small piece of throughput, and we're measuring that in much shorter cycles more frequently. And then we can steer more effectively. So if we're going down a road that's maybe not as beneficial, we can detect that sooner and we can place our money in a better way.
[14:13] Yeah, and that would mean that the business cases that were generated based on nonsensical data would very quickly fall through, right? And you would very quickly see like, "OK, hang on, this wasn't entirely what was in the business case. So maybe we need to revise this."
[14:31] OK, so that's kind of a good way to end this, I think. So that's it for today. I hope you enjoyed the conversation. I certainly did. If you have a situation at work—in the past or right now—that you feel has unintended bad outcomes, just let us know and we might discuss it in one of our next sessions.
[14:50] Thank you, Wayne.
[14:51] Thanks, Gino.
[14:53] Bye-bye.