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.
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:
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:
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.
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!