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 :
- Gut Estimate – The most likely estimate
- Best Estimate – The most optimistic estimate (if all goes well and nothing goes wrong)
- Worst Estimate – The pessimistic estimate (if all hell breaks loose)
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:
- How many hours a week (average) does he attend meetings?
- How many hours a day does he actually work?
- Does he take any breaks (coffee, bathroom, dentist visits, etc)?
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 can not 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?
Graduate with B.A.Sc with a formal academic background in Electrical Engineering. I like trying on different hats - from Software Developer, Hardware Engineer, Software Testing to my fav Technical Program Manager. Most recent project was helping the smooth on boarding of Skype into Microsoft!
I have a great passion for technology and am always searching for what new things we can expect in the next wave. 
I find it interesting that you weigh the initial “gut” estimate twice as heavy as either of the other 2. Even though the experienced engineer realized his initial gut estimate was a bit optimistic, why even count it at all? I’d stick with his re-thought “most likely”, and count it double against the worst case.
I take in the gut estimate because I have found that sometimes the gut estimate (before they break down the task) tends to help in the overall estimation. This gut estimate comes from experience of working on a similar task.
As for why I multiply it by factor of ’2′ – When I was experimenting with my teams in calculating project estimation I knew I had to identify 3 constant factors (one for gut estimate, one for best, and one for worst). I found from numerous trials that using 2,1,1 worked giving me the closest estimate. Leaving it as 1,1,1 – on numerous occaions (+75%) I found it gave me an overestimate.
I personally don’t see much point of time estimates unless you are (a) trying to please bosses and upper management, (b) notifying marketing for their campaigns, and (c) satisfying investors’ greed. However, setting deadlines are great tool for moving things forward. Two great tools can be used to complete milestones to progress quickly without being overwhelmed by what you perceive as essential elements of a project (or what should be worked on a given time allotment):
This video (http://www.youtube.com/watch?v=2O6p80xuUyw) summarizes the two tactics of applying Pareto Principle and Parkinson’s Law very well. You may think many items are essential and that you have no idea to tell which ones aren’t. But then again, if Pareto Principle analysis is exercised regularly (every day, week, month, etc.), in my personal experience, there aren’t a whole lot of factors in a project that do not matter (i.e. not sufficiently contributing to the completion, performance, profit, sales, etc.). From that semi-retrospective perspective, elements that matter are more predictable than one may perceive.
The team would stretch the work time, interruptions and tasks to fill up allotted time. So the psychology can be manipulated to be so short that you’re forced to apply the Pareto Principle to gut the elements that do not ultimately to at least the 80% of the outcome. In summary, by imposing insanely short deadlines on tasks, one is forced to focus on the essentials to acquire the outcomes (or most of them).
We use Function Points Analysis Estimates. We have a Quality Assurance area that collects lots of data and we use this data to find productivity factor for each professional profile (and even individual productivity if needed).
We have adjust tables for each kind of project we’re willing to manage at this level (some projects aren’t worth so much precise techniques, as a matter of fact).
Recently we’re introducing Use Case Points for projects related to web, mobile and client/server platforms. I’m not involved, but I think the things are going as well.