Working on a fixed budget produces a couple of opposing incentives ...
Most clients want to know the costs up front. Who wouldn’t? It makes total sense to know what you’re spending before you agree to something like a web development project … until, of course, it doesn’t. Working within a fixed budget produces incentives that don’t always work well for the client – or the agency. Here, I outline what the problems might be …
Video transcription
In case you prefer to read than to watch … here’s a transcription!
Two things happen when you’re working on a fixed budget. First of all, the agency is incentivised to get the work done as quickly as possible. They’re getting paid whether it takes six months or one month to deliver it.
Secondly, the client is incentivised to cram as much into that project as possible. You end up with scope creep, you end up building features and functionality that you’d never considered before because you don’t want to say no to the client.
So these two incentives are opposing, they’re not working together, they’re working in direct opposition to each other. Agency wants to work done as quickly as possible, client wants to cram in as much as they can. What we try and do then is try and align our incentives and the incentive should always be to deliver the best work for the end user. Not always the client but for the end user.
And to do that you need to align your incentives. So if you can take money out of the equation and just say we will work in these sprints, we will work with whatever the budget is that you have and we will deliver work up to that point. Then the client can make decisions as to whether to carry on and to continue with that work.
Fixed price can work for really tightly defined projects that have clear deliverables. That might be a piece of UX research or it might be a discovery piece or it might even be a small web project whereas you know everyone’s really clear on what’s being delivered. But for longer projects fixed price isn’t helping anybody.