It’s natural to want to do the very best at whatever it is you do. I know I do and, if you’re reading this, I suspect you do too.
We’d rather be right than wrong. We’d rather be perfect than imperfect. We’d rather deliver 110% than 80%.
As a sentiment, that’s very noble.
And for any personal interests or hobbies you might have, feel free to be as perfect as you like playing chess, carving pieces of wood, or learning a musical instrument.
For business, though, that’s not necessarily what we want at all.
What we want is an output that makes economic sense in the context of the input.
A sentiment I’ve put into a rule I call my Exponential Cost Curve rule.
The exponential cost curve
Why the exponential cost curve matters is that the last few percent of perfection on any project can often cost more than the preceding 95% of the project.
Early on, in most projects, the benefit of doing something – however modest – rather than nothing generally has a highly positive RoI. You’re not spending much, but you’re seeing improvements come through.
But at some point, those costs and benefits equalise, so you get back out pretty much what you put in. Now, there are reasons why you might still want to do that, but few organisations realise when they’re in this zone because most financial decision-making isn’t set up to make this clear.
However the trouble with not knowing when you’re in the “flatlining” zone is that you’re not aware that, just around the corner, is the zone where continuing to spend money will generate a negative incremental return.
That is, not only will you not get any additional benefit from whatever you do in this zone, you will build in diseconomies and disincentives so great that they start to take away from the value you generated up to that point.
Every extra pound you spend reduces the return from the project by £10 or £20.
That’s why I call it my Exponential Cost Curve – taken to extremes, organisations burn through cash in this zone and end up with a worse project in almost every way than they would have had if they hadn’t been quite so keen on achieving some sort of mythical perfection.
Especially common in tech projects
The place I’ve found the Exponential Cost Curve kicking in the most in recent years is in large tech projects.
That’s for two main reasons.
Firstly, and most commonly, because the tech co which developed the solution didn’t understand the real world as well as it thought it did, they built in a range of features which don’t make as much sense in the real world as they do in a Silicon Valley board room.
The trouble is that if you want to use this software at all, you can’t just use the high RoI bits, where you’re doing something rather than nothing and thereby seeing a big benefit from a modest cost.
The software provider has bundled everything up together in a single package and you’ve generally only got a choice between buying all or it or none of it. So to get the “low hanging fruit”, you end up buying an expensive system you might only really want 10% of, but it’s the only way of solving your problem.
So you pay for the 90% you won’t want or need as well, meaning that most of the benefit of whatever you’re trying to do goes into the bank account of the tech co that sold you the solution in the first place, rather than into your bank account.
That’s bad enough, but the second reason the Exponential Cost Curve gets triggered in tech projects is a little more insidious.
Someone – often whoever specified the original project – puts a proposal forward to the board that essentially says, “look at all the exciting things we could do with the 90% of this software’s capabilities that we’re not using”.
Usually the software provider or their systems integration partners are happy to produce all sorts of data showing how much more efficient the business will be if only they start doing things in that 90% space. They can smell a fresh batch of licence fees or a considerably longer customer lifetime value at 1000 paces with a project like this.
That’s particularly the case when the supposed benefits are to do with implementing more structure and control within the software environment and the services which rely on that software.
It’s not a bad thing
Of course, a degree of structure and control is not a bad thing. It’s very hard to run a successful business in an environment of complete anarchy.
But structure and control is something you can have too much of. When you build in inflexibility and rigidity in the name of “control”, the laws of unintended consequences start to flex their muscles because they know they’ll be called into action sometime soon.
To give a real-world example, in my days running a large call centre, we had (as most call centres both then and now do) a call scripting system, which prompted the call centre agent with the questions they needed to ask the customer in an order which someone had programmed the software to ask them.
The agent had to click a “next” button to move to the next question.
The basis for doing this was that it would allow us to control calls better and ensure a more consistent call duration which made resource planning easier to manage. I’m sure there was also some theoretical conversations about how a tighter control on call durations would make sure agents weren’t engaging in idle chit-chat with customers, which in turn meant we would be more cost effective as a business.
While all of that is, of course, entirely plausible in theory, the business had reckoned without one important consideration.
Customers tended not to call up primed to answer questions in the order our software prompted the call centre agent to ask them.
Often, for example, they would start explaining what the problem was – which might have been question 10 in the scripting tool – instead of giving us their customer reference number, which was question 1.
So the agent had to wait until the customer paused for breath before interjecting and saying something like “OK, I understand Mr/Ms Customer, but before we go any further, can I just get a couple of details from you?”
The agent then went back to their script and started at question 1, while doing their best to remember what the customer had already told them about their problem (question 10) which would be coming along 9 questions later.
Inevitably there was more discussion about what the problem was when this conversation got to question 10, a bit of recapping of the story the customer had told previously, and some confirmation of understanding from the call centre agent.
The problem is, all of this took a lot of time in a business where time spent on the phone was directly related to our salary bill, which was far and away the biggest cost the business had.
It was too much control
While the motivation of the people who put the call scripting system in originally was well-intentioned, it came from a place where more control was seen as a necessary element of delivering greater efficiency despite, as it turned out, that not being the case at all.
So, at a time when the call centre industry was hardwiring business processes into software solutions, our operations director, Paul, had a brilliant insight and took us in the opposite direction.
He realised that, while we needed the answers to those 10 questions to enable us to solve a customer problem, the order in which we got the answers was irrelevant, as long as we got them all.
So he re-engineered our call centre agents’ desktops so they could skip from one question to another easily. You could think of this like tabs on an Excel spreadsheet, where clicking a tab instantly takes you to a different part of the spreadsheet.
Now, if a customer started at question 10, it didn’t matter. While they were giving us the answer to question 10, the agent would key in all the details needed for that question. Then they’d let the conversation flow naturally until all the questions were answered.
Think about this for a moment.
We gave up control.
Rather than the conversation being directed and controlled by the call centre agent (or, more accurately, being dictated by the software on their desktop), it was being directed and controlled by the customer.
But get this – on average, calls were much shorter because there was less backtracking, less repeating of information which had already been given once before, when the agent wasn’t on “the right question” to capture the information, and less interrupting by the agent to get the conversation back to flowing in an orderly manner from question 1 to question 10 if the customer had gone off-track anywhere in the process.
Some quick maths
Thanks to this realisation, our average call duration went down almost 20%.
In very approximate terms, we therefore needed 20% fewer agent-minutes to handle the call volumes. And, in theory at least, that meant we could reduce our salary costs by 20% too.
Flipping that maths around, what that means is that implementing the call scripting software to “improve efficiency” and “introduce better control” cost the business 20% more to run than not having that software.
When you have an annual salary bill running into the tens of millions each year, a 20% saving on that is not to be sniffed at.
And that’s what I mean about the Exponential Cost Curve. We used the rest of our CRM system and it worked just fine, but the call scripting software was in that zone where, despite the theoretically attractive business case, it cost us more to run than the benefits it brought to the business.
We had reached the point where a relatively small additional spend to bring in and integrate an extra piece of software had a huge negative RoI, not just on that element of our investment, but on the business as a whole.
That’s what an Exponential Cost Curve does to your business.
And the thing is, it’s usually hard to spot in advance. But the common factors I’ve come across are either in the desire to achieve some sort of perfection (however defined) or as part of the business wanting to exert control over the nth level of detail in its operations – especially when real-life human beings are involved, as they tend to be more random than tech companies think they are.
The hidden benefits
For the business I ran, there was a very real hidden benefit in switching off the rigid approach to customer service – customers enjoyed their interactions with us a lot more. We offered a fast, customer-centric process which sorted out their problem on the spot 95%+ of the time.
By the standards of most people’s customer experiences, then as now, this itself is pretty exceptional.
We won a slew of industry awards on the back of this idea, and others we implemented over the years. And that made it easier for us to attract more business. When you offer a really good service, word has a way of getting out about that.
And if all your competitors are offering a drab, robotic service, frankly you don’t need to try all that hard to be vastly better than your competition. So we really stood out from the crowd.
Now, you may not run a call centre, but I can virtually guarantee you that someone inside your business…perhaps even you…is currently in the middle of a project to either achieve some theoretical level of perfection and/or to improve control, and thereby efficiency, in your business.
I’m not trying to discourage that. We all want to make our businesses as good as they can be.
But what I am saying is that the Exponential Cost Curve – when incremental spend makes the whole business worse – is a very real concept. And it’s particularly real when either perfection or control is being pursued to the nth degree, because it’s in those last couple of percent of implementing total perfection and/or control that you’re more likely to come across the Exponential Cost Curve.
It was very obvious to us in a business where salary costs were such a significant factor.
But it’s not always that obvious.
Maybe you’re just absorbing much higher technology costs than you need to.
Or maybe the inflexibility you introduce into your systems is either increasing business risk to the extent that it’s going to backfire on your business badly one day, or it’s cheesing off your customers to such an extent that they take their business elsewhere.
Rigidity in systems and processes, when carried to extremes, often increases costs dramatically, no matter what the people selling you technology systems designed to implement that rigidity tell you.
Your challenge, should you choose to accept it, is to curb your enthusiasm for the last few % of perfection or control. Often that’s where the biggest negative RoIs are hiding.