Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Tagged as

How to do your project estimations!

, 2 May 2013 CPOL
Rate this:
Please Sign up or sign in to vote.
How to do your project estimations!

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 Engineerin Techniques. Also the client requirements keep changing at each cycle (or sprint or whateever 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,
 
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 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.
 
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) 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 Smile | :)
 
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 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 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 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 and in many cases there is no gurantee 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. 

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Mukit, Ataul
Chief Technology Officer Rational Technologies
Bangladesh Bangladesh
C++ is not C with classes, JQuery is not Javascript, Google Search is not Learning, Design Patterns are not fashion, A code written in 2005 is not backdated just because it's 2015
Follow on   Twitter

Comments and Discussions

 
QuestionSoftware engineering is different to civil engineering PinmemberJohn Brett29-Apr-13 1:02 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.141223.1 | Last Updated 2 May 2013
Article Copyright 2013 by Mukit, Ataul
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid