I recently came across an organisation whose poor budgeting structure means their software costs are much higher than they should be. They could spend less, AND get better results, IF they changed the way they think about software.
Let me explain.
You can break down software projects into two parts: the initial development and launch, and then the on-going support and maintenance.
This particular company had totally separate budgets for the initial development and the on-going support.
What happens when budgets go bad?
Can you guess what happens if you budget like this? The initial development has to be done for a certain cost, or the first project manager gets a kicking. So the features that would make supporting the software a whole lot easier – or even possible vs impossible – just don’t get written. What are these features? Monitoring how the software is running, proactively alerting the right people when things go wrong, and giving visibility of what the software is actually doing behind-the-scenes.
The initial project manager delivers on-budget and everyone is happy… until something goes wrong.
The manager in charge of the on-going support is now in a much bleaker position. He has got to fix whatever problem has arisen, but he has nothing to go on. He didn’t know the software had gone wrong until somebody told him, so he’s playing catch-up right from the start. He can’t see whether the software is running properly. He can’t see where the errors have happened. He’s just going to have to take random guesses and blunder on until his team finds something and fixes it. Then how does he know it’s even properly fixed, when he still can’t see what the application is really doing? He can’t have confidence that the job has been done properly.
Then the next time a problem happens, he’s back to square one again.
In reality, what would probably happen here is that in a busy department the manager would get somebody to have a quick five-minute look, declare that the problem can’t be found, and ask the business team to prioritise fixing the problem versus working on all the other things that the team has to do. The fix won’t get done for a few months, everyone will forget about it, and the software will just stop working. Sometimes the only person who really knew what was going on will leave the company. Effectively the whole development effort has then been wasted. This happens a lot!
The root cause of the problem
So what’s really gone wrong here?
The budgeting process has made the initial development slightly cheaper, but has simply shifted the cost of support into the future – and now the cost has doubled, trebled, or worse! The software remains out of action for longer, possibly even permanently, because it cannot be quickly fixed and supported.
The budget didn’t help the project, it actively hurt it.
The solution: consider support and Total Cost of Ownership from the start
The solution to this problem is to set the budgets for software based on Total Cost of Ownership (TCO), looking at the whole lifetime of the software. You might think this is obvious, but in a surprisingly large number of companies it isn’t!
Rather than considering initial build and then maintenance as two separate activities, consider them as two parts of the same whole. It’s usually folly to save a little money up-front if it means much bigger costs – or total unavailability of the software – further into the future.
Getting managers to think like this can be difficult. If you put your project manager’s hat on, the ability to support and maintain the software is really part of Quality.
Quite often nobody ever asks the question, “How long will this software actually be in use?” In most cases, the software actually ends up being used for much longer than anyone predicted at the start of the project (I’ve seen six-month proof-of-concept software still in use ten years later!) And the longer the software is used, the more the costs of unsupportable software mount up.
Action points
Consider whether the way you budget your software projects is harming your ability to produce supportable and maintainable software , thus pushing up your costs.
When budgeting, consider prioritising Total Cost of Ownership over the whole lifetime of your software, rather than a cheap initial build followed by years of pain.
If you still need to split your software budgets into initial build and then on-going maintenance, ring-fence some budget in the initial build to make sure the software is supportable – think about support and maintenance in your requirements.
Look out for another article where I discuss supportable software in more depth.