We make successful products for our clients by maintaining flexibility in our process, folding in what we discover and learn as we build. We make projects successful for our clients by delivering consistently, on-time and on-budget. We can only deliver predictably if we’re good at helping clients set a responsible budget in the first place.
Software is never finished, in the sense that a bridge is finished. Besides maintenance, like a bridge, there are always more features that could be added, interfaces to polish, workflow to simplify or extend, integrations to be made, etc. For this reason, it’s hard to be sure, at the start of a project, exactly what the right thing to build is. This poses challenges for determining the cost of a custom software project.
Software and budgeting
The nature of software product development should heavily influence budgeting. Projects which are strongly undercapitalized are nothing but a waste of money, and a recipe for disappointment and anger. Setting the budget before starting the project—something that’s almost always necessary—should take into consideration the fact that you can’t know everything at this point in time. Budgeting happens at the point of maximum ignorance.
In sixteen years of working with clients, I’ve never met one who had more money than ideas. Of course not all ideas are equally valuable. Our role is to help create the best possible software application, constrained by a responsibly set budget.
Budgeting for software development needs to take the nature of custom software into consideration and set everyone—the project, the team, and the client—up for success.
Everyone needs good budgeting
Our client’s business needs a realistic budget they can count on so they can confidently analyze whether a project is worth doing. Will it provide a reasonable return on the investment in the desired time frame? Tough to answer that question if you don’t know what the costs will be.
Our client, that is the person we work directly with and who approves our invoices, needs a credible budget so they can get approval for the project, or so they can raise funds. Again, you can’t raise capital without having a good idea of what you’re going to spend.
Finally, our teams need a good budget. One of our brand promises is predictability in time and budget. It’s hard to meet an expectation that’s never formalized. No team likes disappointing a client, so a realistic budget is critical for team success. Teams use a budget to force themselves and the client to make choices about feature breadth and polish. In a situation of more ideas than money, a fixed budget forces a healthy discussion around the prioritization of work.
I’ve learned over the years that budgeting isn’t about determining the definitive, proven answer to the question, “How much will my application cost?” Rather, it’s determining a responsible budget for a project and using cost as a constraint on the project. The fundamental question is, “Can the team and client find success within this budget?”
Cost as constraint
Budgeting is one of the most difficult and stressful things for makers and consultancies. More commonly referred to as estimating, it’s often the least favorite aspect of their jobs. Few of us enjoy it or feel confident with it.
It makes sense to me that developers struggle with estimation and budgeting. There are many considerations, some not readily quantified. There are unknowables. Answers are hard to validate (unlike software itself). Like any creative activity, software, and hence the cost of software, is heavily influenced by the people involved. It’s no wonder estimation and budgeting skills aren’t common.
Unscrupulous consultancies will intentionally manipulate estimates to win projects. But even well-intentioned developers may not give budgeting the time and effort it requires and deserves.
Determining the amount of the budget to constrain a project is hugely important, but within a certain range, also somewhat arbitrary.
We like to involve our clients in the decision of setting the budget. Together, we are choosing a constraint, not determining some definitive correct answer to the cost question. We help by doing the thoughtful work to determine a responsible budget range for a project.
An effective software development process supports discovery, learning, feedback, and adaptation. Jointly determining the budget with clients helps them understand that success comes from working together, using budget as a constraint on an inherently open-ended process. The shared goal is to define and build an application that will at least satisfy, if not delight, its intended users, and create a business success for the client.
With the inherent ambiguity around new product development, and the malleability and unconstrained nature of software, treating cost as a constraint is not only vital to project predictability, but also the best product development approach.
How Atomic budgets
We distinguish between budgeting and estimation. Estimation of a feature set is only one consideration for us in determining a responsible project budget.
Feature estimation is a valuable exercise in thinking through the application to be built. It can be a substantial investment of time, but through investigation and conversation with the client, it helps us understand what the client’s goals are, and what should be built. The act of feature estimation lets us bring our own experience and ideas into the conversation. We often influence substantially the nature of the final product.
Estimation involves decomposing the application to be built into high-level features or subsystems. Decomposition, breaking a big thing into small constituent parts, is a powerful method used widely in computer science and project management. For estimation, we use our experience to assign low and high estimates to each feature.
For each feature, we use the spread between low and high estimates as an indication of uncertainty. We compute a buffer for the entire feature set estimation based on those spreads. The buffer places the feature set estimate somewhere between the sums of the low and high estimates of all features. High degrees of uncertainty mean the final estimate is closer to the sum of the highs; lower uncertainty lands you closer to the sum of the lows. This post on buffering describes the details.
Feature estimation isn’t a budget or project plan. Some features that are estimated may in fact never be built. Some important things that eventually are built may be missed. Investing this time is still valuable, even when done at the point of maximum ignorance, for the conversation and understanding it engenders.
Since feature set estimation isn’t sufficient to set a responsible budget, we use many other sources to inform our budgeting process:
- analysis of business needs and goals
- comparable projects we’ve done
- time invested in prior versions of the same application
- team size, composition, and experience
- evaluation of client’s prior software development experience and capabilities
- power and maturity of relevant technologies
- environmental factors such as regulatory requirements and deployment process
- number, diversity and degree of alignment of project stakeholders
- integrations with external systems
- number of technology domains (e.g. web, mobile, desktop, embedded) involved
- migration needs from prior production versions
- criticality to business operations
- likelihood of hidden requirements
- likelihood of emerging requirements
- how well-understood the need and market is by the client
Of course not every source is useful for every project budgeting exercise, but an experienced team draws on many sources of knowledge and insights.
Starting the relationship off right
We often find that our budgeting work helps clients better understand their projects. Investing the time for feature estimation, and considering many different aspects for the budget, helps clients compare proposals from multiple vendors. It also starts the critical task of building trust between the client and the team.
Clients who aren’t themselves experts in software development can find the entire process opaque and intimidating. It’s no surprise they may feel vulnerable to being taken advantage of. Being thorough, transparent, and collaborative in setting the budget helps address their legitimate needs and fears.
It’s said that the best way to predict the future is to invent it. Setting a budget informed by a diligent investigation process, and working with a team that knows how to use budget as an effective constraint, applies this advice to the seemingly perplexing question, “How much will this cost?” The answer becomes easy: “What we budget.”
The post Software project budgeting is more than estimating appeared first on Great Not Big.
