No one likes surprises, especially not when it comes to how much something costs. In custom software development, where projects tend to be 6- and 7-figure investments, communicating about costs is important. We’ve worked hard to improve our estimation process, be fully transparent with clients, and adapt our process to be flexible.
There are countless reasons why the cost of a software project could change after it's originally estimated, but leveraging industry best practices—such as building the most important features and functionality first—helps to ensure your project's success. Setting aside a contingency is another way of accommodating the unforeseen changes that will inevitably arise.
Ready to outsource custom software development?
Learn what to look for in a partner.
Budget Contingencies in Software Development
A budget contingency is an addition to the initial project estimate to allow leeway in dealing with unforeseen risks, scope additions, and project changes. Typically, the amount of the contingency is a percentage of the overall project budget.
At Far Reach, we add these contingencies to every new software development project or system enhancement. We generally recommend a 20% contingency on top of our development estimate. It’s important to note that they aren’t considered part of the budget. We go in to the project hoping not to use the extra funds, but they’re there just in case.
We consider contingencies an important part of budgeting for software development. It’s a conversation we have with every new client.
Why?
Because it allows us to be upfront with our clients and set realistic expectations from the beginning. Contingency budget funds also help us to be flexible as requirements of the project change between initial estimate and completion.
While they are not universally loved, and it’s easy to question the reason for them, contingencies are an earnest way to protect both the client and the outsourced development partner. It’s easy to think, “Why do I need a contingency if the project is estimated as-is?” Or, “If we have the funds, shouldn’t we just use it in the budget?” But specifying a contingency offers benefits that help account for human error, the fast pace of change in software development, and overall budget management. Keep reading to find out how.
How Contingencies Help Protect Your Investment in Custom Software Development
Contingencies are not the most exciting line item to see on a contract.
However, software development projects are notoriously unpredictable and it doesn’t benefit anyone to pretend that they aren’t. This is why fixed bids rarely work in this industry—they’re risky for clients, developers, and even entire projects.
There are three main components to planning any project:
- Time
- Cost (or budget)
- Scope
The problem? Changing one of these variables affects all of the others.
For example, if the scope increases, you will need to adjust your budget and your timeframe up as well. Or if you want the project completed sooner than the initial estimate, you will have to reduce complexity or scope.
In our experience, scope is the variable that changes most often. Once you’re into a software project, you usually find new features to add, unseen barriers to circumvent, and other surprises.
Without a budget contingency in place, you and your software development partner will have to navigate:
- Changing the feature backlog to keep a similar scope and budget—something that’s easier said than done
- Settling for the initial version of a feature, even if you’ve gotten feedback that would help improve it
- Choosing which features to deprioritize to stay on budget
- A not-previously-discussed budget increase
After a few decades in this field, we know very well that change during a custom software project is perfectly normal. In fact, our process (using agile/scrum methodologies) plans for change and keeps projects, well, agile.
A lot of things can come up during a project, and some of the most common surprises we see include:
- The client wanting to iterate on a critical feature. With fixed bid projects, this is called scope creep, but in agile projects, it’s iterating and it’s expected.
- Once they start using the system, the client realizing they need an additional feature or to rework an existing feature.
- Developers encountering unforeseen technical difficulties/implementation issues.
- Estimating is hard. We do the best we can, but humans are fallible. That’s why Hofstadter’s law, which says “a project always takes longer than expected,” exists.
Technology moves fast, and so do many of the industries we work in. Not being able to take advantage of a new opportunity during development is more costly than planning ahead for mid-project changes. We manage our backlog against the original budget, and we strive to ensure the client gets what they need within that budget.
With a contingency in place, you can get more out of your custom software. If you decide you want to add a feature that helps you be more competitive, you can do so without having to decide which features to sacrifice or finding additional budget. One more time, just to bring the point home…We don't treat the contingency as part of the client’s budget—the original, pre-contingency budget is the constraint we work against—the contingency just allows us to be flexible and to incorporate the things that perhaps couldn’t have been foreseen in advance.
Contingencies are especially important in bigger development projects that take several months (or even years) to complete. In these cases, you know that ideas change, and the scope evolves a lot. A contingency protects you from having to give up great ideas just so you can stick to an outdated plan.
What Happens If You Don’t Need the Contingency?
Ok, one last time, our goal is to not use the contingency! We want to build the software with the estimated budget as a constraint. However, as outlined above, having a contingency helps adjust and build better software. Contingencies are set aside for the “what-ifs” of software development.
Because we actually plan to not use the contingency budget, those funds are not set aside in our bank account. We don’t actually bill a contingency amount unless we get to the end of the original budget and the client decides to dip into it to get more value from the system we’re building. Planning for a contingency is just that: planning. It’s telling your decision-makers that the project has been estimated at $110,000 as it stands, and you also want to set aside an additional $20,000 for a contingency.
Some clients ask us: Can’t we forgo a contingency and just plan more initial features?
While that sounds appealing, it’s incredibly risky. We’ve been developing custom software for a long time, and contingencies have become non-negotiable for us. We believe in them and their purpose in custom software projects and their value has been proven over and over again. Our job is to protect your investment as best we can, and that involves planning for the unplanned.
Being flexible is important, and so is knowing that you don’t know everything. A software platform will change and evolve during the development process—that’s the point. Including a contingency allows that to happen without putting the project (and, frankly, the relationship) at risk.
After an initial project launch, many of our clients are happy to have set aside a contingency, even if they weren’t in the beginning. Through feature changes, user feedback, and an excitement around building the best platform possible, contingencies are there to make sure a system can make a positive impact and not just sit on the proverbial shelf.
When projects don’t use the contingency for the initial launch, clients are excited to have budget already set aside to keep building. Many clients roll their contingency over into budget for enhancing the system with features and functionality they uncovered during the development process or after launch.
The Bottom Line
Software development is unpredictable. And that’s perfectly alright because our process allows us to be flexible. Contingencies help you take advantage of that flexibility and ensure that you get a usable product as quickly as possible without compromising on functionality or features.
Want to discuss contingencies in software development projects in more depth? We’d love to chat.
Reach out!