How many software projects have you launched? Well, if you have reached the second one or more, you already know that estimation is a rather vague thing by itself. Neither the software company nor the client can exactly know how much time will be required and whether the budget is enough – of course if we stay away from mythic huge budgets, which can cover everything but virtually don’t exist.
Both parties can be exposed to the dangers of ”under-estimates”, although they are nothing new:
• the client runs the risks of losing on the quality of the product and deadlines of delivery;
• the company runs the risks of not delivering the promised results.
Many business people search for the estimates they’d like to see. But only with experience does this definition come close to the word ‘realistic’. It’s easy here to make a wrong decision, especially if you don’t know what to expect. And naturally you’ll start with comparing.
Figure Out The Most Realistic Estimations By Comparing
Differences in estimates are dictated by the peculiarities of each software company. If you give the same information to several potential contractors, you’ll receive a span of estimates. One will be suspiciously little, another will take too long, and several will have a moderate amount of time, and generally resemble each other. The latter responses usually come from experienced companies, and they tend to be the closest to the truth.
You don’t have to hire one company in favor of another just because of an estimate that ”promises” faster delivery of the finished product. First off, estimates don’t promise anything without a comprehensive specification and unchanged requirements. The latter is not the case with custom software development as we know it. There are much more important factors that will define your work with the company, such as attitude or flexibility.
The expertise of the team in your particular field matters, but it doesn’t mean that you must dismiss a developer who hasn’t dealt with this API and that library before. Such little things boost the estimates a little, but they don’t show anything bad about this developer. The team is oriented at solving problems and delivering results. They will include risks into the estimates, first on the developer level, then quality assurance and project management.
Which Estimates Should You Believe?
You could notice that it’s been all about adding: add planning, add design, add QA, add risks for unique features and non-standard logic, add management. Does it mean that companies boost estimates for the sake of getting more money? We don’t believe so. It’s rather a bad company would try to get a client by offering lowered estimates and then just let it go on with the flow. They would even expose themselves to risks of not delivering what’s been promised, having to redo everything to finally make a finished product. But even if they do it for their own cost, the software owner loses precious time, which in modern mobile world is more harmful than losses in budget.
Believe the reasonable estimates, based on facts and risks which can be explained. Even if you are new into the world of custom development, the company will provide you with substantiation. Every good company has an established process of making estimations on different levels. They are based not solely on experience, they depend a lot on the available documentation.
• Developers calculate the required time, relying on their own experience, vision of possible problems and complex features; they also add time for bugfixing and polishing.
• Since developers tend to be extremely ”optimistic” in their calculations, project managers do the rest: prepare a more realistic estimate that considers all possible risks; all of them are discussed in detail with the client.
• Remember that more or less precise estimates can be based on the approved design that’s been examined by developers. Everything preceding is as approximate as can be.
Limited Budget / Strict Deadlines
A client often comes to the company with a certain budget that cannot be exceeded. Therefore the team gets acquainted with the project and available requirements, decides whether it’s possible to build a viable product, and discusses the outcome with the software owner.
The other side is strict deadlines, which can as well be analyzed for getting the answer to ”Can the project be done until then?”, and if not, ”What exactly can be done until then?” – meaning a working product, of course – but probably without a couple of secondary features that can be left out until the next update. Let alone the fact that such deadlines can quickly consume the budget – more developers will be needed to accomplish the task, but hiring more people than it’s necessary might not do the trick. Maybe it would be better to reconsider the deadlines to make the work more consistent and receive high-quality product in the end.