Much has been said and written about the importance of estimating. How many hours will a particular project take? In other words, how much money and workforce do you need? Be sure, all these factors exert a great deal of influence on your relationship with clients, project management and, of course, venture success.
First and foremost, please note that there are four distinct common types of estimate:
- Ballpark figure
- Service estimate
- Feature estimate
- Componential estimate
What’s the difference? Why do all these types exist?
While the task of naming the anticipated cost for the project remains the same for all types, each of them approaches this task in a slightly different manner. Both clients and suppliers should discriminate between them, be aware of the pros & cons, and use them where appropriate.
Let's take a look at the main features of each type.
A ballpark figure is what is often called a “guesstimate”. It’s an approximate number or range that gives a general idea of cost and that may help a prospect decide whether they would like to take the discussion further.
It’s a definite boon for the software engineer, who doesn’t have to go into much detail and anticipate all the technologies and processes that would shape the project. The bane, however, is that this method won’t give you a clue about supplier’s qualification, quality of work or possible results of a project. And it's quite a risky strategy. Therefore, it would be a huge mistake to start working on a project only on the basis of this figure.
As common experience shows, the most reliable companies would give high ballpark figures (just because they understand all possible risks). So, if a prospect gave in to the temptation of the lowest ballpark price, he probably selected an unqualified, unprofessional company. As a result he gets bad value for money and possibly a damaged reputation. When is this type generally used?
We can use a ballpark method when a prospect needs an idea of an average cost (e.g., for budget planning) or for market segmentation (to feel the difference between large and small companies, decide who will be the best partner for their business: a freelancer, an outsourcing company etc).
Another two types – service and feature estimates - are very common, but they don’t come as highly recommended. Still, it’s good to be aware of their features.
Service estimate is based on the regular project stages. From this scheme you may understand what services a company provides by default. Service estimate reduces risks for both customer and supplier. This scheme is usually based on some particular patterns.
From a service estimate a prospect can get information about supplier’s services, and that’s about it. So, one should keep their eyes peeled when a supplier doesn't offer design, QA or other such services. Perhaps the reason is they just don’t have such in-house specialists?
What is more, a service estimate will not help you understand what features will be included in a software. Neither it will allow you to remove the features you don’t need. All in all, this type is quite flexible and useful while you are discussing the services.
The third type (feature estimate) is largely based on the software features. From it, a prospect can easily understand what features are included in a software but will have little idea about the services offered.
On the other hand, feature estimate allows you to easily remove or add any features to the list.
We would recommend neither service nor feature estimate. They are a kind of slapdash estimates and their applying indicates lack of professionalism (of the supplier company). The outcome of going ahead with a suppliers on the basis of such estimates is often unsatisfactory: misunderstandings, possibly conflicts, even as far as an abrupt end of collaboration.
What about the fourth type? Componential type of estimate is very flexible as it displays the range of supplier’s services in relation to a particular development project.
One can make use of componential type estimate for the whole development process. No need to re-estimate from scratch when you want to add, remove or replace features, services etc. You can easily remove a feature without affecting the accuracy - as you can see, this type is very flexible.
It’s as closest as one might get to the precise price estimate. With a clear componential estimate, a prospect will have full understanding of what they pay for.
The importance of clear prospect’s requirements cannot be underestimated. Indeed, the clearer the better:
If Michel Nostradamus were to estimate software projects, the numbers would be cast-iron risk-free. Now, once we accept that in most cases software project estimators have nothing to do with 16th century French quatrains, we acknowledge the undeniable risks of estimates being not as accurate as we want it to be.
Everyone understands that the fourth type of estimate (componential type) is the most risk free.
But what are the risks that come with software development estimating and can they be in any way reduced?
First comes overestimating. In case of overestimating, a customer will overpay, and who of sound body and mind would want to throw their money down the drain?
On the other hand, there is a risk of underestimating. When this happens, a customer will pay less than the actual cost of effort the supplier invests, which will undoubtedly leave the latter in the red. In most cases, this will lead to friction, conflicts and sadly enough, perhaps the end of a mutual collaboration.
The next risk is failure to meet the project's timeline. It’s very common, especially when you have no clear requirements or you haven't considered all possible details when discussing a project.
You may be surprised, but a total epic fail scenario may also unfold, which means a project won't be realised. Technological fails most definitely happen, especially when you have chosen the wrong supplier. “Wrong” often meas suspiciously cheap, since to win a prospect inexperienced companies usually go for low-balling. And then.. it just happens. You realise, that they haven’t got the skills they claimed to have to launch your project. Having lost time, perhaps money, and most definitely any bits of trust for software developers, the poor customer needs to start all over. And this time with a different company. However, the new supplier won’t be all too willing to take over where the old one left off. It’s easier to start from scratch, or to rework (but this may cost the customer a pretty penny).
Another risk is damaged reputation. When you don’t have enough experience and choose the wrong technology partner, you might end up with project timeline failure or even an epic fail. Remember that your reputation is at stake.
Now that you have learnt about types of estimates and possible risks, let’s try to put them in practice, as every case is specific.
For one, service and feature estimates are not recommended, as they are slapdash options mainly used to capture a customer. This seldom results in establishing long-term business partnership with a particular supplier.
Instead, you should try and search for a technology partner with relevant experience, examine ballpark figures and then devote time to examining componential estimate. A solid and fruitful customer-supplier relationship is usually shaped when customer follows these proven project stages:
- potential suppliers - compile a list of suppliers in the field of your project: mobile development, web development (never fail to check their portfolio and previous relevant experience)
- request a ballpark - get a cost indication (range) based on project nature and a high level specification from the selected suppliers to learn what kind of market players they are.
- supplier selection - select a supplier with the most relevant experience. Your choice should not depend solely on the price! Not as cheap as expected? A word to the wise - you get what you pay for (yes, the market rule applies). This doesn't mean you should opt for the highest price - consider all the factors (experience and professionalism, among other things). If you can't help seeing it all through the prism of money, you might want to think about external funding.
- discussion - this next stage could take a while. Bored already? You can go straight to the Contract phase and adopt the per hour basis scenario if you and your supplier have a history of mutual trust and reliance. Still insist on getting the exact price at the start? It's a good idea to hold several meetings or phone conferences to discuss and settle on project specification and details. The purpose of such discussions would be, of course, to make sure both you and the supplier are on the same page as far as the software concept is concerned, and such discussion won't be a success unless the supplier delivers to you a componential estimate in the end. Address all the supplier’s questions and insist on being provided a componential estimate.
- quote - as a result of fruitful discussion, you'll get a fairly exact cost.
- contract - what's left is to conclude your agreement with the supplier in black and white.
- discussion of the project and providing ballpark figures should just be steps well towards receiving componential estimate. That's the road to success for both: one more interesting project for the supplier and eventually one more happy customer.