Product Operations Program ManagerBarcelona, Cataluña, Spain
First of all, I would ask about his reasons. Often they are reluctant to provide estimates because they fear to be made accountable in case the project is delayed. Things I would do:
- if the activity is too large to provide an estimate, break it down further. The smaller the activity, the easier and more accurate estimates.
- use the PERT technique.
- if available, use estimations from previous similar activities and work with those instead of starting from zero. Saving Changes...
As Eduard says, always start with WHY before moving to action.
Beyond fear of consequences of giving a "bad" estimate, it could also be that they are missing information needed to provide the estimate. There may also be an explicit or implicit expectation that someone else would be approving their estimate before it is provided to you.
Good input above on understanding why, breaking down the activity, and using historical data.
Sometimes, for whatever reason, groups avoid providing duration estimates, or the timeline for their personal milestones. They sometimes spend more effort avoiding the input request than it would take to do the work.
In that case, I use an approach I adapted from Sun-tzu, and assign them a duration, which puts them in a defensive position. Their escape route (their own plan) is my end-game.
My answer is inevitably not the way the plan will play out, but then they either have to provide a counter-proposal, or they are stuck with mine. I create these "straw horse" plans in a variety of situations where people are reluctant to provide their own input. They will of course criticize my plan in excruciating detail, but I can use that input to elicit their plan from their critique of turn my straw horse.
You need a bit of thick skin to put up with the complaints, but it gets the plan unstuck, and at the end, I get their estimate. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Joshua,
some ideas:
Find out why they do not give an estimate.
Is the estimate seen as a commitment (a threat) or just an expert input? Or have you hurt their trust before (find out if previous behaviour of yourself creates this reaction) - then rebuild trust.
Anyhow, building a relationship, being empathic is a prereq for changing perspectives and behaviour.
Ask other experts, which is a good idea anyhow (Delphi method, independent estimates).
Work on a team charter and include 'giving estimates' as an expected behaviour (by the team), maybe build on general openness, transparency, honesty values. Saving Changes...
1. Prioritise and focus on what they can do in the next iteration (e.g. this week or next)
2. Ask for a relative estimate (points, not duration) instead. In my field of software and data, relative estimates are much more useful than absolute estimates. Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Joshua,
From a going-forward, future projects perspective: I think @Thomas is correct, “charter it,” whether it be from a team and/or project perspective. The demand/expectation will create the accountability structure needed, and force (well, maybe not “force”) any concerns on this subject to occur before initiation of development activities.
Every developer I have worked with in my four decades of software development has been “estimate adverse.” It’s in our human nature not to be held accountable for estimates, as ambiguities are the norm, let-alone the historical patterns of “unknowns” that developers recognize in a given functional/technical relationship.
My approach is to empathetically agree with the developers concerns, but yet require their due-diligence nonetheless. I then invite their written disclaimers and concerns regarding the estimate, which validates them and also provides good information regarding “gaps” in the portrayed requirement.
On a related note:
I recognize the apparent logical validity of the no-accountability #NoEstimates movement, in general and in light of agile-based practices. For instance, these points are often stated (I’ve seen them in my in-box).
- Accurate estimates are impossible; hence they have no place in the process.
- Estimates create undo pressures on a team.
- The time put towards estimates could be better used somewhere else.
When #NoEstimates (whether referenced or not as the motivation) is executed, that is, the developers do not supply an estimate for their work packages; the misnomer is that estimates are not occurring. This couldn’t be further from the truth, as I would estimate that 95%+ of the time that estimates are still occurring at “some level” (even under agile-based approaches).
So, are we helping developers by conceding to the #NoEstimates mantra. Where have we collectively gone wrong; where “feelings of accountability” are seen as a negative to be avoided at all cost? In my experience, “feelings of accountability” create better products and a better working environment – am I wrong? Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I put her/him out of my project except the people that have the top decision will assume that there will not be a date of completion on activities under that person accountability or responsibility. I faced this lot of times. Saving Changes...
Community Champion
