Fred Brooks’ law says, that what one programmer can do in one month, two programmers can do in two months. That’s why the spread between estimations can be enormous – it takes into consideration hundreds of variables, trying to predict the effort of the developers, where the path is all covered in mist.
At 4soft we believe that the basic price estimation for a software project should always be free. You share a basic list of features, descriptions, and you get a ballpark cost range. Sometimes they can say a thing like “60-80 developer mandays,” while in other case you can get “60-120 developer mandays” range. What does it depend on? And what does it take to get a detailed estimation?
Estimation of software effort is an extremely responsible job
It’s similar to anesthesiologist work: you have to estimate the amount of anesthetics based on your experience, assumptions, statistics, and a few bits of given information on the patient. If you either underestimate or overestimate it – you will have a big problem later on. I’ve seen a number of software houses dragged down under the surface due to a bad estimation policy.
Estimation is basically a problem of communication and experience
The precision of an estimation highly depends on the input. Based on our experience, the data sent by the client is rarely precise enough to prepare an estimation right away. That’s why we have so many questions about the details. One small element underestimated during this stage can grow later on into an enormous variable sucking up your resources.
If someone prepares the estimation for you and doesn’t bring up those detailed questions – that’s a warning sign. It probably won’t be precise enough.
The estimation should be based on the previous projects. The more experience the software house and the analyst collected, the closer to the real value the result will get, especially when we consider projects similar to the previous works of the same vendor.
How a proper software project estimation should look like?
To get the desired precision of the estimation, you can use various methods, including expert judgement, analogy, and parametric cost modeling. Based on our experience, the most precise results give a resultant of expert estimation and work breakdown structure.
Such an approach takes time – for a rather simple project, it takes the whole day of a business analyst to discuss the details with the client, break down the project, analyse it, consult with tech leads and form the results into a clear report.
Such an estimation is a valuable asset, combining the experience accumulated within the company and work of an expert analyst, and prepare a basic architecture of your project. That’s why we charge for it.
And it is simply worth it – most of the estimations fail due to poor expertise, and cause a ripple that can undermine the whole project and challenge your budget.
But if you are up for a shallow estimation, take into consideration Hofstadter’s Law: “[The project] always takes longer than you expect, even when you take into account Hofstadter’s Law.” Poor preparation at this stage end up with projects that are over-budget, delivered late, and fall short of user’s expectations.
Want to estimate your software project?
Talk to our experts.
