Estimates, Quotes and Budgets… Oh My!

Having trouble with estimates? One of the biggest challenges we face as consultants is how to talk about money. In this post, I will share some of the wisdom our team has collected along the way and a glossary of estimate terms to help.

The work we do is hard. We invent new systems where often a problem or simply a lack of solution exists. We inherit old, poorly designed databases, gnarly spreadsheets, or outdated tools. We get wish lists instead of specs. We work with folks who often don’t understand software development. As outsiders, we frequently need to learn new businesses.

Digital Transformation… This Way!

In all of that, we sell ourselves as consultants, ready and able to lead the way. Digital transformation is just a signed service agreement away!

In all cases, there’s a lot we don’t know. Even if we do know it, it often needs to change along the way. Budgets are tough to nail down.

And so then comes the dreaded question at the end of a brief introduction… “Given what we’ve told you, how much will the project cost?

You can’t give hard estimates for soft ware

I once had a team member tell me (pleased with how cleverly he was making his point), “You can’t give hard estimates for soft ware.” Well, fair enough. He was right – the only thing any of us really know about an estimate is that it will be wrong.

That said, we can’t simply refuse to provide information. As a business owner myself and having worked with literally hundreds of clients over the years, one can’t embark on a software initiative without any sense of budget and value. It’s a rare client that accepts, “Hey, I’m an expert… trust me, I’ll do the right thing.”

It’s totally reasonable that a stakeholder expects to know a project’s cost before embarking on it.

There’s a lot of discussion in our community about value-billing, agile project management methodologies versus waterfall, and so on. I’ll avoid the temptation to go down those particular paths in this post.

The basic premise here stands: in order to buy something, one needs clarity on what it is one is buying. It’s a foundational problem in our industry.

Estimate Glossary

I’ve noticed that often people conflate the terms, “quote”, “estimate”, “budget”, and so on. I’m really trying to fight that.

Entire books have been written on project management, risk mitigation, and software development. To help my team and my clients with these conversations, I’ve focused first on language.

The following are four terms we use as uniquely distinct. If you work with or for Codence, you’ll see them in our proposals, project documentation, and more. We’re careful in how we use them, and we devote time in new client relationships explaining what they mean.

Ballpark

A ballpark is a guess. We often express it as a very wide range – for example, “Given a project of roughly this scope, based on work we’ve done with other clients, I’d guess we’re looking at a ballpark of $45K to $90K.”

Note that this guess uses at least a 2x range, is expressed in very round numbers, and comes with the proviso of what assumptions (prior similar work) led to it.

We also will provide small ballparks for specific tasks, using a small, medium, large t-shirt size mechanism, like so: “The TPS Report you’re describing is probably a medium-size task of a few days of work.”

Again, note the lack of precision – “a few days” and “medium-size”.

We use ballparks as decision-making tools early in the process. They’re crude but allow our clients to choose if something is feasible or not, or if something should be a priority.

Estimate

Estimating, at least at Codence, is something we do internally. We don’t share estimates with clients. We have found that estimates are often confused with prices – two totally different things – and that they can often be taken out of context.

Further, in order to estimate something – as opposed to providing a ballpark guess – one needs to have crafted most of the requirements necessary. We view requirements as an integral part of the ongoing work we do, and estimates go hand in hand.

There is no “estimating stage”. We estimate all the time, throughout a project, just as we also document, write code, test, and so on.

We use estimates to measure development effort and to steer, over time, the trajectory of our project.

Estimates come from developers like so, “The import function defined in task ACME-123 is estimated at 3 story points.” You could just as well provide an estimate in hours. We find simpler is better, so we opt for single-point estimates, but ranges could serve as well.

Investment

Our first version of this list early on used the word “budget” here, but we’ve opted instead for the term “investment”.

You wouldn’t, most likely, think of investing in a pair of shoes. You would invest in property. You would certainly invest in a business. The term investment hints at where custom software leads – you’re investing in digital transformation in order to make your team or business more efficient, more competitive, more resilient, more capable.

Investments are informed by estimates, by a stakeholder or client’s objectives, and by a healthy dollop of project management conservatism.

An investment for us is a dollar amount, but it is one set by the client. It is not a range, but rather a specific, concrete, unambiguous number: “Sprint Three (with the attached task list) is planned for an investment of $22,500.”

Commitment

This set of terms wouldn’t do much for us were it not for this most-important last one. Ballparks, Estimates, and Investments are all factors that lead to the thing we’re all trying to do: make decisions. They’re informative. They help to steer and define a project.

Once informed, we face a choice together with our clients: can we commit to a body of work, on an agreed-upon schedule, for a given investment?

The goal of our work in defining requirements, investigating issues, exploring ideas is to bring a plan together to which we and our clients can agree.

Clarity Drives Trust

By using clear terms and following the practice of defining and making good commitments, we build trust with our clients, we root out uncertainty, and we recognize (mutually) that we cannot predict the future. We give our clients the best information we can, then we allow them to control what they invest. We make specific commitments that are then unambiguous.

By beginning our relationships discussing these terms, we give all of us a framework in which talking about money isn’t adversarial, isn’t awkward, and isn’t dangerous. These terms allow us to make decisions together.