Preventing budget blowouts in software development

The most important question in your new project, is always the hardest to answer. How much is it going to cost me? In this blog, we give tips and tricks on how you can prevent a budget blowout.

Science and technology
Data and analytics

Whilst the first question potential new customers want to know is usually the most obvious, it’s also the most difficult to answer. How much is it going to cost me?

Managing a budget for a software project can be a difficult task, but providing you adhere to a few key things, then effectively managing a budget becomes a whole lot easier.

What causes budget overruns?

In our experience, budget blowouts for software projects happen because of these five 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.

Managing change

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.

Miscommunication

A key part of the scoping phase, is the "understanding the business" phase. Global 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.

Do you want to talk about your software development project with a team who knows the pitfalls of our industry?

Discover more