Project Managers

The Project Management Social Network | Project Manager Jobs

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 :

  1. Gut Estimate - The most likely estimate
  2. Best Estimate - The most optimistic estimate (if all goes well and nothing goes wrong)
  3. 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 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

Views: 332


You need to be a member of Project Managers to add comments!

Join Project Managers

Comment by Safinaaz Rawji on September 22, 2010 at 1:20pm
This has worked for me in the past and I have not encountered an issue....yet.

Agreeds, using past metrics on resource performance is essential to get a better estimate on task/project duration. But I also look into the complexities of the previous tasks/projects and compare them to the current one.

Great comments/discussion everyone. You don't know how much I have gained from reading your comments.
Comment by David A MacLeod on September 22, 2010 at 4:10am
Bruce - I agree that following robust estimating methods is key to a reliable schedule. I'd be interested to hear more explanation of one of your comments - you say the detail of tasks comes after getting a good overall duration ... I don't follow that line of argument. As Safinaaz says, start with the task definition (in her example, creating two environments) to understand the effort required before it's possible to estimate overall duration. If you haven't got an explicit agreement on the task characteristics, how can you estimate duration?
Thanks, David
Comment by Indranil B on September 22, 2010 at 2:26am
Hi Safinaaz,

Thanks for the info that you have shared and it's really helpful, but do you think this type of analytical judgment can be made by mathematical implication!! I am in doubt after working almost 8 years in the field of Project/ Delivery Management. Please rectify me if I am wrong..
Comment by Bruce Benson on September 21, 2010 at 12:24pm
Getting the schedule right (i.e., the estimate right) I found to be the single biggest contributer to software project success.

I make extensive use of "past performance." This is where we look at recent completed past software projects and see how long things took for them to complete their project.

In just about every case where we helped an organization move from late and buggy software delivery to on time with good quality, the core change they made was finally getting a good estimate for how long the project would take. Note, this was getting a good "overall" duration first. Filling in the details for milestones and tasks was of secondary importance (and changed often during the actual 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" --Using past performance necessarily includes the range of typical things that go right and go wrong. This technique then essentially handles all but the most catastrophic of events and so does "predict" well all those seemingly unpredictable events.

For more details on this approach, see:

Good article and discussion.


Bruce Benson
Twitter: BruceWBenson
Comment by Safinaaz Rawji on September 20, 2010 at 12:57pm
Hi Dina
Yes I do share the productivity ratio with my team and my manager. This is great for planning future projects and identifying what we can manage and when do we need to look into adding additional resource(s) to our team...
Comment by Safinaaz Rawji on September 20, 2010 at 12:54pm
Hi Indrani
Productivity Ratio is measured with how many hours a week does the resource actually work (this is minus the coffee breaks, meetings, personal arrands etc). The first estimate on my resources productivity ratio comes from taking this into account from looking back anywhere from one month to six months of history. From there, I slowly fine tune the ratio.
E.g. My developer spend a max. of four hours a week in meetings and close to four hours a week in coffee breaks, bathroom visits, etc. This gives me thirty-two hours a week on solid work. I found along the way that though he/she may spend 80% of their time doing actual work on a project (development work), they spend an average of two hours a week doing something outside of work (reading blogs, magazines, etc) as a method to relax themselves and get their head out of the box and escape the task so they can potentially getting a different prespective. Because of this, I found their productivity ratio is around 75%.
That being said, I have two productivity ratio's on the same resource - each dependent on the technology at hand. E.g. if my developer is working using C#, their ratio tends to be higher than say if they were working using Shell Scripts...
I found this second ratio when I noticed they required more time to work on tasks where the technology used was shell scripts because they spent more time investigating and troubleshooting. For tasks using this technology, I would have a higher worst estimate.
Hope this helps
Comment by Indranil B on September 20, 2010 at 7:30am
Nice calculation made, but still in doubt about 'productivity ratio', as that also depends on 3 factors like,
* 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)?

Can you please specify the exact way to measure above ratio value, as it plays a key role in Practical Project Development Life Cycle.
Comment by Dina Garfinkel on September 12, 2010 at 11:05am
Great post! I agree completely with your technique and like your use of productivity ratio. I actually just wrote a (what I hope is entertaining) post about what I am calling the "Distraction Factor"...very similar to your productivity ratio:

Curious, do you share that ratio with your team members?

Also, when using this method, LiquidPlanner can be a very helpful tool since it will do all of that math for you, it is designed to take estimates in ranges. Will save you a lot of time and help improve your own productivity ratio! :) (
Comment by Vivekanandan M on September 9, 2010 at 5:36pm

There are 2 Software Project Estimation done, one while bidding for the project and the other is the actual project plan for the execution.

a. Project estimate while bidding for the project is generally done using Function point analysis or based on gut estimate by an architect.

b. Project estimates for the execution of the project is generally done using PERT model.

Best Regards,
Vivekanandan M
Comment by Safinaaz Rawji on August 29, 2010 at 8:38pm
David A MacLeod
I'm going to try and see if your method works in one of my upcoming projects along side with my method.
I call it 'gut' estimate because in numerous tasks, the first number my developer would give me is what he/she defines as their 'gut' value. This number usually comes from experience and with minimal analysis.
Most times, this number is close to the optimistic case (in my experience it tends to deviate close to 20%).

David Espina
Monte Carlo Simulation, going to read up on this - thanks for the share !

© 2017   Created by Mike.   Powered by

Badges  |  Report an Issue  |  Terms of Service