One of the most difficult challenges in software development is to come up with proper estimations related to a project.
In traditional Engineering, you are aware of the steps required to finish a road, building or a bridge and the estimations should be more or less correct than what you would find in Software Development.
Software Development is not engineering in its truest sense because it is still a growing field and there is still not an established methodology to come up with Software Engineering Techniques. Also, the client requirements keep changing at each cycle (or sprint or whatever you term it as) and makes the task even more difficult!
A decent starting point can be to break down the tasks and requirements of the projects to the bare minimum directing you to the path of good estimations of deadlines and milestones.
But before that, you need to come up with a proper initial spec - preparing which is a very difficult skill to master.
After the spec preparation, from a developer's point of view:
- First you can run a basic scan of the spec and break down the hours.
- Any tasks which appears to be greater than 5 to 8 hours in your view, you have to break down in subtasks or maybe depending upon the project any tasks greater than 12-15 hours, you break it down to sub tasks.
- Then, you have to judge the experience and skill of the assigned person, and then again re-evaluate the hours and go to step ii) again.
- Now, you add some buffer to the estimated hours (estimating risks and possible new requests to attend to which you are not prepared for) and then recalculate the hours for the final time - unless you are too much of a perfectionist to start from step i) again
The testing and debugging hours must also fall under the subtasks and has to be carefully measured so that their hours are not over estimated.
And last but not least, if you are the project manager, then atleast multiply the estimations provided by the developer by a factor of 1.5 (better if you can multiply by 2 or even better 3) - and submit to the client.
Actual factors will depend on what part of the development is using reusable code, proven APIs and least innovations (of course developer efficiency and proficiency as well). Also, there is a factor of over-committed personnel which might get you into trouble in the later stages. Sometimes, the developer assigned to the project can be too confident of his abilities and set unattainable goals for himself or the team he leads.
All projects have their own uniqueness which factors into the estimation. It is not just the deliverables but also the client psych, his concept, his pocket and his tolerance. We all want to make the best deliverables using the optimum resources, time and adequate QA. But the reality is that there are bindings we need to contend with which all of you know by experience (or will find out soon).
There can be many modules which require proof of concepts that have to be factored in. In such cases, you can do SWAG (Scientific WILD ASS GUESSING) technique. But this is beyond the scope of this article.
All said and done, given the growing nature of the Software Industry, estimations of projects can still be considered more of an art work than science and in many cases, there is no guarantee you would come with proper estimations and deadlines even after giving your best shot!
A bit of disclaimer here - the views presented by the author are solely based on his experience only and are not applicable for every situation.
