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 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 - 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 :)
 
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/herself or the team he/she 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.
 
signing off,
Mukit
 

View the RSS Feed in

Comments

That's not to say that we can't plan software engineering. But it's isn't the same as civil engineering.

The fact that client requirements change all the time simply has to be built into the planning process, and the client needs to understand the consequences of changing requirements.
But this is all for the good - often no-one knows what is actually required until you start work on it, and there's no point in stressing about preparing the perfect spec in advance because that doesn't work.
Instead, start with prototypes/PoCs and progressively refine them until you have what the client wants. Likewise, the estimate should progressively refine itself during the development cycle. I describe this as having a fuzzy view of the project schedule at the beginning (e.g. 10 weeks +/- 4 weeks), but progressively coming into focus during the process (until you can say, "we'll release tomorrow!").

The more you try to do up-front planning in software development, the more precise your estimate will be, and the less accurate.
Precise, because you'll keep breaking down the original assumptions until you have a set of fixed tasks to implement with an exact time allocated to each, but less accurate because you're constantly refining all of the original mistakes, assumptions and redundant tasks from the original assumptions.
The perfect illustration of this is your suggestion of multiplying the developer's estimate by some arbitrary fixed ratio. What this actually tells you is that the developer's estimate is wrong and unhelpful. Probably because:
a) it omits all of the tasks that you haven't told the developer about; because you forgot, the customer forgot, or because they'll be discovered only during actual development
b) it omits the boring integration/testing/release process that developers don't think about because it's boring
c) the spec will change, and the workload will change accordingly.
d) developers do over-estimate how long it takes them to do the work

Use of proper agile processes will give you a far more realistic view of your project.

John

Architect, emapsite

United Kingdom

Recent News and Updates

  • Rational Technologies introduces WebRTC in Bangladesh and is a pioneer in research related to browser based video conferencing
  • Rational Technologies has been chosen as a Strategic Partner for IT of Rangs Group which is one of the biggest Groups in Bangladesh. Rational is now involved with various aspects of Social Marketing for the Group.
Go to top