On estimates and budgets in software
Towards the end of a planning meeting at the office last week, a colleague lamented the fact that developers are reluctant to give estimates. He went on to express frustration that speaking in terms of budgets seems to go more easily when, in fact, a budget is the same thing as an estimate. I tried to explain the difference between estimates and budgets and why that difference matters to developers.
It’s true that budgets and estimates can play similar roles in the context of planning; both provide a means to tell a story about the future (i.e. make a plan) upon which consensus can be built and other, downstream decisions can be made.
This act of planning forward and coordinating the conversion of various benefits into profitable activity is core to any business beyond a certain size or level of maturity, and the basic questions of planning are really quite reasonable:
- What am I going to get?
- When will I get it?
- How much will it cost me?
The core difference between estimates and budgets that is relevant to developers, however, is that estimates are something that we give to the business while budgets are something that we receive from the business.
This may appear like a subtle distinction that is pure semantics, but think about it from our point of view.
The act of giving an estimate exposes us, makes us vulnerable. We might be wrong, and frequently are. An estimate is, after all, only a guess. An educated guess, we hope, but still, only a guess. We are often asked to give estimates on problems or solutions that we don’t fully understand. We are often asked to give estimates without understanding the business context in which those estimates will be evaluated, or without any idea of what the customer things is reasonable.
Receiving a budget, however, is much more comfortable; it clarifies what the business expects of the development team and is basically a goal with a set of constraints.
We developers, problem-solvers by nature, practice, and training that we are, love nothing more than to figure out how to achieve a goal within (and despite) a set of constraints.
That’s what we do.
Give us a goal and some constraints and our brains immediately start thinking through possible solutions, exploring different possibilities, sifting out the promising from the futile, and generally solving the problem.
I like to look at estimates and budgets as two sides of an ongoing conversation between a delivery team (of software developers) and a business/management team (e.g. a project manager or department head):
- Business stakeholder
- How long will it take to build this awesome feature?
- Developer
- About 2 weeks, provided A, B, and C assumptions hold true.
- Business stakeholder
- Okay, given my other priorities and what I know is happening in the market, I need this in 1 week tops, and I can't gauruntee B.
- Developer
- Well, let's try this other approach, then we won't need B or C and we should be able to have it done this week.
- Business stakeholder
- Okay, no B or C and you have 1 week to complete the feature.
- Developer
- (Works to deliver within the budget)
Notice the back-and-forth nature of this conversation.
Notice how the estimates are context that the development team provides to the business, but the business still takes responsibilty for planning.
Postscript
After spinning out this line of thought, what I’d really like to leave you with is the observation that all of this appears to matter much less in environments with a high degree of trust.