In my last post, I shared my thoughts about how bugs in a software are different and how they need to be handled based on their type.
No project that involves developing software is ever plain sailing, am I right? Grossly underestimated budgets, poorly defined scopes, crossed wires and misaligned objectives: just a few of the usual suspects that can make things go wrong. It’s quite astonishing, however, when a single project ticks all of these boxes. That’s exactly what happened in the now infamous Queensland Health payroll system fiasco. What started out as a $6.19 million contract between the State of Queensland and IBM Australia to replace their legacy payroll platform resulted in a whopping 35,000 payroll anomalies, ultimately costing taxpayers $1.25 billion and simply labelled “the worst failure of public administration” by the parliament’s reviewing commission. A rather embarrassing 264-page report found fault at every single stage of the project, from procurement through scheduling to delivery. Which brings us to the age-old question: who to blame – and who to charge – when a software needs fixing?
Who is responsible for the bug?
Culprit-wise, there sure are some classic scenarios here.
- It’s not you, it’s me: Keeping it real, we’ve had our fair share of failed products. A few years back, we were busy working on a huge development project that we left in charge of a newly-minted project manager. As brilliant as he was, this was way over his head. So we brought a vendor on board to save the day. Long story short: they didn’t. We ended up underwhelmed and over budget. Just like our client.
- It’s not me, it’s you: The customer might always be right, but their legacy systems can sure be all kinds of wrong. Even if your shiny new app could work wonders, outdated or simply incompatible client-side infrastructure can be a real headache for the development team. And a very real threat to budget calculations.
- It’s not us, it’s them: Let’s say you’ve built the app. You love it. The client loves it. Users love it. Your competitors hate you for it. And then Google decides to change a Google Map API that practically renders it unusable. Or SimplePay is down and payments won’t go through. That’s right, third-party solutions can also be a liability. And then things can get really messy, really fast.
Now guess what all these problems have in common. Ultimately, the client pays for fixing them, that’s what. Sounds unfair? It doesn’t have to be. If you get it right, that is.
3 ways to pay for bug fixing
- Golden hours: One way to go is take the agency’s hourly rate and top it off with a handsome margin to cover the costs of handling potential debugging requests. Now the operative word here is potential. What if there are much fewer bugs to fix than expected? There’s a fine line between built-in bug fixing and overcharging the client, even if that’s the furthest thing in anyone’s mind.
- A question of time and material: Then of course there’s always the option to ask the client to simply pay for the extra time and energy the developers put into polishing the product. As foolproof as it sounds, it’s anything but. This method works best if the quality assurance game is on point to ensure that products go live as smoothly and bug-free as possible, no matter how much testing it takes.
- Fix project pricing: Or simply put: Built-In Bug Fixing 2.0. Much like in the first case, the client is charged a fixed price for the estimated costs of bug fixing. Only this time it won’t be part of the hourly fee but the cost calculation for the entire project, from start to finish. And unless someone has a crystal ball to rely on, it pretty much raises the same question as option no.1: what if the actual costs are a far cry from what you’ve budgeted?
Food for thought: who and how should pay for bug fixes? Share your experiences and I’ll tell you how our agency does it so we don’t lose either clients or sleep.