01 Mar
Photo by Simone Venturini from Pexels
We’ve briefly discussed ballpark estimation in a previous post, but today I would like to cover the topic in more detail.
Why do you need a ballpark quote anyway?
In my experience, ballpark estimation is usually used in the sales process, when bidding, and during other “client onboarding” moments. Sometimes it’s also used for ongoing projects, but that isn’t what we are going to focus on today. A ballpark figure is also called a “rough estimation” – it is a figure that omits a lot of details, doesn’t consider all the problems that may appear, and doesn’t focus on any technological aspect. The goal is to provide a general idea of the cost so the client can make a decision.
This is where the problem with ballpark estimation starts. If the idea behind asking for a rough estimation is to obtain a general idea of the cost of the project, then how can ballpark estimation help? The received answer will never be accurate, and it may even be so inaccurate that the estimated cost will have nothing to do with the final cost.
Requests for a rough estimation usually come from prospects who are looking to compare quotes from different vendors. They are often budget-aware and looking for the cheapest option available. If you are working with sales or with sales people, you probably know that most often, when prospects are looking for ballpark quotes, they don’t end up hiring your services.
The misunderstanding, in my experience, comes from the fact that people who are asking for quotes are not always aware of how software development works. There are too many factors to consider when creating a product and many moving pieces, no one is able to provide a quote that’s even 50% accurate.
That’s why my approach has changed recently – I’ve stopped giving ballpark figures. Firstly, because they don’t make any sense. Trying to guess how much a complicated project will cost is like reading tea leaves. And secondly, if the prospect is not willing to engage into the process of preparing a Scope of Work, then it’s almost certain that a project for such a client will never start.
But of course you’ll always have prospects who really need – or want – to get a ballpark figure from you. To deal with these scenarios, I will share with you my “magninute” idea.
Something better than a ballpark estimation
This is a new concept I am still working on – the basic idea is to provide a magnitude of the project cost instead of a ballpark figure or range. It works with a scale that outlines the following levels:
- Magnitude 1- small item, enhancement
- Magnitude 2 – a story, set of enhancements
- Magnitude 3 – a mini project
- Magnitude 4 – a small project, ideally to be delivered within a 3-month window
- Magnitude 5 – a project that will take up to 6 months
- Magnitude 6 – a project that will take up to 12 months
- Magnitude 7 – a project that will take around 2 years to deliver
- Magnitude 8 – well, I don’t do such projects, but you get the idea
Once I have identified the magnitude of the requested items, I can let the client now how many figures we’re talking for the cost, depending on the magnitude, for example:
- Magnitude 1 – the cost will be a 3- to 4-figure number
- Magnitude 2 – low 4 figures
- Magnitude 3 – low to mid 4 figures
- Magnitude 4 – 4 figures
- Magnitude 5 – 5 figures
What I am trying to achieve here is to paint a picture of the possible cost of the requested requirement without giving an actual number. This way, when a proper estimation is delivered, the client will not be surprised by a final cost that is way different from the initial ballpark figure.
The method still provides useful information – for decision makers, knowing if the cost will be a 3-, 4-, or 5-figure number should be enough to know whether they can secure the budget. If they can’t make a decision based on that, then they need to invest in proper estimation. This will save you asking colleagues in the team about yet another set of the requirements that will never receive a budget.
Of course, this concept is also fragile and prone to errors, yet I do find it easy to use, and it provides good results in terms of talking to prospects.
Share your ideas
If you have any thoughts on ballpark estimation, how to avoid it and how to justify the initial costs with prospects – please leave a comment!
Piotr Pozniak is the co-founder of The Beaverhead, a business process optimisation company, and the brains behind The Estimation blog. Before establishing The Beaverhead, Piotr worked as a software developer creating high-end products for the aviation industry. He saw how enterprise software is built, what the challenges are and how it works, and he wanted to provide that quality to smaller businesses and entrepreneurs. Over the years, Piotr has worked towards becoming a software cost estimation expert, and today he shares his knowledge through The Estimation blog.
Piotr Pozniak