Estimating the duration of a task can be difficult. Doing this for a project can be gargantuan. It is not surprising that project estimation is one of the top reasons for failure. Your stakeholders are expecting some tangible deliverable on a pre-defined date you promised hence delivering anytime after that (no matter how complete the project is with all the bells and whistles) is regarded as a failure.
I personally use a three point technique when it comes to project/task estimation. I call it a three point technique because I taken in three estimates :
I also include a variable 'p' which is defined as my productivity ratio on that resource. Now each resource has a different and unique productivity ratio based on their knowledge, skill, and amount of time they can contribute to the project.
E.g. As a Project Manager, my productivity ratio is less when compared to say a Software Engineer or Software Tester. Why? Well probably because I spent an average of 30-40% of the week in meetings, conference calls, or delegating issues within my team. Whereas my Software Engineer can focus on the task itself as they are rarely required to attend meetings.
Now I do have a thumb rule when it comes to task estimation. If an estimate is more than 2 day (16 hours), the task must be broken down. Any task that would take more than 16 hours of work is regarded as complex and needs to be broken down and made granular.
How is this all put together?
Say I have a task to migrate a database from one location to another. I would sit down with my software engineer and we would hash out the details on what would be the work item we would need to do and be aware of when it comes to database migration. Say the first task is to create two new virtual environments that would house our new database (one for test environment and the other for production).
My Software Engineer who has ample experience creating virtual environments comments that this should take him only 1 hour. This is what I would classify as a gut estimate. When we sit and go through the details on what is actually required to be done to create these two environments, he changes his estimate to most likely taking him 2 hours. This is what I would classify as the best estimate. For the worst estimate, we would go through what could possible go wrong and if it did how long would it take. My Software Engineer figures that if things go wrong, it would take him close to one full day (8 hours) to get the two new environment set up - this would most cover setting up a new server and setting up permissions, etc, before creating an environment where he can host VMs. So from here we have identified values for our three variables:
Gut Estimate = 1h
Best Estimate = 2h
Worst Estimate = 8h
The equation I use to get the average duration for this task is:
(Best Estimate + 2xGut Estimate + Worst Estimate)/4 = (2+2*1+8)/4=3h
I take this value and divide it by the productivity ratio of my Software Engineer. To get this productivity ratio, I have to be aware of the following:
From this, I found my Engineer's productivity ratio is 75% and hence I take my 3h/(0.75)=4h
I have found using this technique gives me a more true representation of the actual time my team takes to complete a project. Now it is fair to say that not everything will go according to plan - human and technology are the two huge variables you cannot predict in projects but using this technique will help you get a good average for the entire project.
If you find that your project finished far earlier or later than you predicted, you need to review two items: - task estimates and productivity ratio. It is important to have some consistency in your estimation and document on your reasoning behind the estimates. This can help you in future projects and in post-mortem analysis.
What estimation technique do you use in Software Project Management? How has that worked for you?
Post can also be found at Bluepixel