Preventing Budget Blowouts in Software Development
What causes budget overruns?
In our experience, budget blowouts for software projects happen because of these 5 things:
- Over-promising and under-delivering
- Underestimating effort related to non-programming tasks
- Scope creep
- Misunderstanding of key elements of a project
- Miscommunication during 'discovery' phase
Mitigating these risks requires forethought, skill and experience. Forethought to recognise that things don't always go to plan, skill to navigate the problems effectively, and experience to ask the right questions up front before a single key is typed by the engineering team.
Above all, the key to ensuring a software project is delivered on time and within budget is communication. And it starts by recognising that the cost in building a piece of software is not development time alone.
At the end of the day, budget overruns occur because the budget hasn't been defined properly up front - so let's try and sort that out first, people!
It's more than just development.
We've seen a number of software projects go over budget because adequate time hadn't been considered for things such as testing and project management. We've seen instances where project managers or developers will quote a client for a software project with that quote being development time alone. Every single project will incur more time than development alone.
The project needs to be tested, which takes time. There will be items discovered during testing which will need to be rectified or tweaked, which takes time. The act of managing and communicating between the client and the development team takes time, and if these items haven't been considered when you receive "the cost", then we guarantee your project will go over budget.
Making sure your development team has included time for testing, tweaking and project management then there will be less financial stress on the project right from the start - and much less chance of your budget blowing out.
Software engineers love a good spec doc! If there's a specification document to work to that accurately describes the project requirements it means the engineers can just code and they won't need to talk to anyone. Great!
But not really... In order to work out what a project is going to cost, it's important to do leg work up front. You will always benefit from a form of specification document, and having a budget in mind when your software team are drafting a specification document will ensure the process is well thought through.
The spec will set the rules and give all stakeholders an understanding (hopefully) of what the outcome of the project will be, along with a roadmap of how to get there. And it's a great way of getting a more accurate idea of what the cost of the project will be.
However - we've worked on countless software projects and we've yet to be involved in a project that required no changes during the development process!
Change is a reality, but how you deal with the changes and how your development team communicates those changes is important.
Experience tells us that change will happen during a project, and so we always make sure that we build into our estimates a contingency for such change. More importantly, when changes are requested there needs to be clear communication with the client about the impact of the change on the project.
Changes will almost always delay the project due to re-work of existing features required to support the change, additional testing to ensure the change doesn't result in breaking other areas of the project and just understanding the change and communicating that change to the development team can be a challenge on its own.
If there's a delay in the project, that almost always equates to an increase in the cost of the project, too.
Understanding the impact the change will have on the project overall is extremely important. Often there's a flow-on effect to even the smallest change requests during software development. And if the change isn't thought through fully, then those impacts will raise their head further on in the development or testing process. And what's the impact of those gremlins appearing when you least expect it? You guessed it - additional cost.
A key part of the scoping phase, is the "understanding the business" phase. Global Office engineers custom software for clients across a broad range of industries and we've been in that space for a long time, but for each new client we take on there is a learning process that we have to go through every time. We have to understand their business (including the nuances between clients in the same industry), and get to know their processes, too.
Knowing the right questions to ask, and ensuring that our clients don't leave out any valuable information is quite challenging. Often during this process, we find that we get into a situation where the client hasn't provided us with all the information.
For example, the client’s business might undertake a particular process for each and every order they dispatch, but because it happens for every order the client doesn’t think to mention that process because everyone in the company knows about it. It's taken for granted. However, from an outside software engineering firm looking in, that information is entirely foreign to us, and can sometimes be important.
Making sure your development team takes the time to discover this sort of information ensures that the initial estimate (that the budget is likely based on) is sound.
What if I have a fixed budget, but want more than I can afford?
You can have the project delivered fast, cheap, well - you can pick two of the three.
This is something we regularly have to explain to new clients in initial meetings. Client's often have a budget in mind, and when presented with the actual cost of building the software solution that has been scoped, may baulk at the difference between their idea of budget and the reality of the budget.
In these situations, some clients have said, “Well, I only have $x what can we do?”
This is where Agile Development can come into play. If you trust your software development team (perhaps you've worked with them before, or they have a really good sales guy!) then an Agile approach to development might be worth considering.
You broadly define their requirements up front and those requirements are prioritised. The development is broken down into bite-sized chunks with the detail of each requirement fleshed out just before development starts. Development of that requirement then takes place over the course of a "sprint" which may be one or two weeks, at which point the development is reviewed and signed off.
The benefit of Agile Development is that requirements can change right up until the development starts, the development cycles are small and a "finished feature" is provided at the end of each development.
You can iterate this process until the money runs out, with the idea being that at the end of the budget you will have quality working software, and the most important features will have been completed first.
To take away
If you want to effectively manage a budget for a software project the best thing is to try and make sure your development team is realistic about what the budget for completing the project is actually likely to be, before committing to the job.
If there is an unrealistic budget set at the start then it's only going to end in that big bad budget blowout that everyone undertaking a software project is already dreading or has experienced before.
Sometimes it's better to say no to starting a project than, it is to get promised the world when the funds won't be available to see the project through.