Outcome-based fees: Yet another reason why it’s hard to make them work in practice

Regular readers of this blog will know that there’s a disconnect between what clients and consultants say about outcome-based payment methods and what happens in practice. In essence: lots of talk distils down into a very small percentage of fees being genuinely at stake. One of the reasons why value-based pricing is so difficult is that we don’t know enough about the value clients are looking for when they hire consultants.

But I was recently talking to an Australian client who made a rather different point. Stripped of its rather colourful language—I’ve never known an Aussie interviewee to hold back—his argument boiled down to the perception that, where outcome-based payments are concerned, he’s effectively being asked to create an incentive for consultants to simply do their job. If he’s hired a firm to implement new technology by a certain time, then that’s what he’s paying for. Rewarding consultants for doing what they’ve said they can do doesn’t make economic sense. Instead, bonus payments should be based on doing something more—delivering a better solution, or the same solution more quickly, or perhaps even a combination of the two.

There’s clearly a mismatch between how clients (or at least, this client) and consultants define the job in hand. Clients assume that consultants will, indeed, implement the new technology. But consultants know that projects are never straightforward, that their job is to deal with the unexpected problems that will inevitably arise and that they’d like the additional effort they have put in to be recognised and, ideally, paid for. Consultants are, in effect, trying to inject an element of flexibility into a fixed-price contract—and, not surprisingly, clients don’t like it. For outcome-based pricing to work from a clients’ point of view, consulting firms have to offer something more: A better or faster solution; an easier transition; or a more guaranteed solution—all of which being things that clients mention when they talk about the value consultants add and discussed in our recent report about value. If consulting firms think that they are delivering more than the client expects—dealing with those unexpected glitches, for instance—then they need to do a better job of articulating that.

However, it’s also clear that clients and consultants use the terms “value” and “outcomes” in different ways. When a consulting firm successfully installs new technology it may be contributing, directly or indirectly, to a business outcome sought by the client—reducing costs, for example. It therefore seems not unreasonable for a firm to try and tie at least some of its fees to those outcomes, a percentage of money saved being the archetypal example. But in this example a client who hires a firm to deliver the new system isn’t hiring them to cut costs. Cutting costs may be a useful context for the consultants to understand, but it’s not objective of the work they’ve been brought in to do, which is deliver a new system that will help the client reduce its costs. This sounds like hair-splitting of the first order, but it’s not: A consulting project where the aim is to deliver an IT system is very different to a project where the aim is to cut costs. In the first, the focus will obviously be putting the system in; in the second, it will be to cut costs, and if the new system doesn’t deliver that, then there’s no point installing it. A client who’s hired a consultant to install new technology isn’t going to pay them a bonus for cutting costs, but one who’s hired consultants to cut costs might. Outcome and value aren’t always the same thing.

Again, the solution lies in everyone having a clearer understanding of what they’re doing. If a consulting firm has been hired to put a new system in, then that’s what they should do. If they think that the process of doing this will be far more costly and complicated than the client thinks, then they need to explain that and agree an appropriate reward. If they want to be paid for adding value, then they have to—well—add it.

Related reports