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

There are many standard ways in Waterfall, Agile or other models to do estimations that require involvement of a whole team (in most cases). However as a personal practice for getting better at doing rough estimations by looking at initial requirements, I followed certain techniques:

A decent starting point is to break down the tasks and requirements of the projects to the bare minimum which may enable you to calculate project deadlines and milestones more accurately.
But before that you need to come up with a proper initial spec.

After the spec preparation, if you are from a programming background (which I am), run the following steps.

i) First you can run a basic scan of the spec and break down the hours.

ii) Any tasks which appears to be greater than 5 to 8 hours. you have to break down
in sub-tasks.

iii)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.

iv) Estimate risks and anticipate possible new requests which you did not plan for and go to step ii) again.

v) Now you add some buffer to the estimated hours and then recalculate the hours for the final time.

The testing and debugging hours must also fall under the sub-tasks and has to be carefully measured so that their hours are properly estimated.

And last but not least, if you are the project manager, then multiply the estimations provided the developer by a factor of 1.5 (better if your 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 some of it depends on innovations you bring to the table. Developer efficiency is a crucial part in this. Also there is a factor of over-commitment which might get you into trouble in the later stages. Sometimes the developer assigned to the project can be too confident of his/her abilities and set unattainable goals or the team he/she leads.

All projects have their own uniqueness which factors into the estimation. It is not just the deliverable but also the client psych, concept, pocket and tolerance. We all want to come up with the best outcome 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 found out soon).

There can be many modules which require proof of concepts that that has 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. 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 is solely based on his experience only and is not applicable for every situation.