It’s not rare to hear someone talk about a software project and say things like, “We blew through the budget six months into a one-year project,” or, “That project ended up at 150% of budget.” Historically, software is notorious for costing more than expected and being delivered late.
Luckily, and with a lot of persistence, software development processes—especially scrum—have come a long way in helping teams deliver working software in priority order within budget limits.
With older software development methodologies, particularly waterfall, scope would be fixed and budget and timeline would adjust until that scope was completed. Because of this, projects were set up to go over budget from the beginning. In contrast, agile scrum encourages fixed budget and timeline (at least within a range) and a flexible project scope.
Costs != Budget
Costs for features and functionality inevitably change throughout a project for a wide variety of reasons. After all, estimates provided are just that—estimates. They’re educated guesses based on limited information. The good news is that just because costs change doesn’t mean your budget has to change, too. Let me clarify:
Costs: The time and/or monetary investment required to build the desired features in a software system
Budget: The time and/or monetary investment actually made into the system to provide the desired value
Just because a system is estimated to cost $300,000 doesn’t mean you actually have to spend that. If the value to the business is only $250,000, you can build the system out, in priority order, until that budget is reached. So, when the cost of a feature doesn’t fall exactly on estimate, the budget for the project doesn’t have to change. And you still get the features that provide the most value.
Know When to Quit
By understanding the value of the software you’re building to your business (for example, this system will save us $150,000 in labor each year), you’re able to make better decisions more confidently about your project. You’re better able to prioritize features and functionality, based on the value they’ll provide, and balance their estimated costs against the project budget.
Without a value-based budget in mind, it’s easy to fall into the sunk cost fallacy, which is the human tendency to make forward-looking decisions about budget based on costs that have already been incurred. When scope drives a project, instead of value, we as humans tend to move forward, spending more and more, even if the additional features aren’t adding appropriate value.
By setting a budget based on the value the project provides, you can make better decisions, keep the project focused on priorities, and stay in that defined budget even when costs change.
Want to talk about your project’s value?
Reach out.