Estimating with your Team
Estimating with Your TeamWhy doesn't this technique work?
A reader wrote in: "Estimating with your team members is really easy. There is no sense asking them how long a task will take, all they'll do is pad the estimate to build in a little vacation time at work. No, the best way to do estimating is in three steps:
1. Tell them when they have to be done which you figure out by counting backward from when the sponsor told you to be done.
2. Tell them all the bad things that will happen if they're late.
3. Repeat the due date louder."
What's wrong with this approach?


8 Comments:
I believe its unrealistic to provide "true" estimates instead of what the sponser will accept. Some middle ground must be found to avoid the Top Down approach. Ask each sequential team member for his/her "best time" given perfection of prior activity timing. Ask for detailed support WBS.
It's not a question of 'what's wrong?' but 'what's right?' and the answer is - nothing. Trust within the team may not as yet be established as so the issue of padding estimates will not go away. I always show the impact on the schedule when these padded tasks come in 'early'. I show how that 'saved' time is actually lost and benefits noone. Then I ask for their most realistic estimates.
Try using the triangualar estimation approach.
How?
Ask an estimate to a pessimist an optimist an a realist then use a wheighted average calculation
((1 x pessimist est.) + (4 x realistic est.) + (1 x optimistic est.) ) / 6
You can change the weights if you think the probability of the estimates are different
I do not pretend that this is the magical formula to have perfect estimates, but at least all opinions are accounted for.
Anonymous is on the right track. I've used that triangular estimating technique myself. It works really well with team members of different experience levels too.
Further to the discussion on triangular estimating, there is a reasonable treatment of using triangular estimating leading toward inherent risk of the estimate ranges at
software.isixsigma.com/library/content/c030514a.asp
The mathematics are not that onerous and there are a number of both commercial software products and contributed templates available at various places across the web.
Knowing the inherent risk in a range of estimates can give the PM good insight into the estimates being provided by team members and can lead to inferences about the state of definition of a work product.
Maybe further definition of the required result or communication with the team member is in order?
As a member of a project team, I can honestly say that it would be a nice change to have some input on the estimates. I can't even remember the last time a PM asked me how long I thought a task would take. I think I would try to be as accurate as possible, hoping the PM would ask again in the future.
The technique of the subject mentioned doesn't work because it is too abrupt. Indefinite. All projects, when estimating, cannot have the same approach. There is no constistent step per project. Maybe frame of work but not approach. Projects should be discussed openly and thoughtfully and be true to the estimates. After all, estimates are relied upon, more so the information and communication of the estimate.
I've also used a variation of the triangualar estimation approach and found it reasonably accurate.
And when I'm a team member given a drop dead date, I've learned not to allow it to upset me or change my schedule - I just explain the Level of Effort and the date requirement will change the cost. (E.g. if a task takes 80 hours to coplete and the due date given me is one week, I explain the 80 hour requirement combined with the 40 hour due date will incur increased resource expenses - either OT or an additional Full Time Equivalent doing the work.)
Post a Comment
Links to this post:
Create a Link
<< Home