5

There is a team and a PM. Unfortunately, the PM does not have very strong technical skills, therefore he has no basis for estimation of the time and costs which are required for each part of project.

In this situation other personnel (e.g. Programmers' Team Lead) must provide the estimation. But, what will happen if these personnel provide an incorrect estimation? For example, padding the estimates to reduce pressure on delivery timescales?

What can PM do to find the right estimates?

  • Hire better people. – Andrew Clear Jun 18 '15 at 20:44
  • 1
    It is interesting you used "padding" as an example. In most cases, we generally suffer from optimism bias and most of our projects are under estimated. If a PM who doesn't have a lot of domain knowledge thinks padding is an issue, it is most likely the bias of THAT PM that needs addressed. Statistically speaking, we do not pad enough. – David Espina Jun 22 '15 at 10:55
  • Just some cents: 1) Ask someone who knows, 2) trust the team and simply accept their suggestion 3) ask them a two-level deeper schedule estimation, and the risks involved with each estimation. – Gürkan Çetin Jun 28 '15 at 9:17
11

First, remember that an estimate is highly unlikely to be 100% correct, so do the best you can with the information that is available to you.

Second, break down the tasks as far as you reasonably can, and get figures for similar low level tasks from other projects that have been done in the past. Don't worry if they are not identical, as long as they are broadly similar.

Third, get a consensus. Don't just ask one person. Get a few people in a room and ask them for their best estimates. Debate, discuss, argue, and then choose a value that most people will accept.

Fourth, ask questions. If it feels wrong, you either don't understand the problem, or someone else doesn't. Ask them to explain why they gave their estimate, and do this (nicely) in public, so that others can also provide their input and challenge the estimate.

Fifth, learn from what has gone before. Learn whose judgement you can trust, and whose you cannot. Learn from your mistakes, and also from your successes.

Sixth, Refine your estimates as the project goes on. You can change estimates. Just communicate the changes openly and honestly.

2

If the team members are constantly padding the estimation, it's either that they want to keep a comfortable pace of work, or they wish to cause harm to somebody above them in the hierarchy, or they are afraid of risks that will cause them a lot of pressure if happening.

Let's assume that they are not lazy or evil, so you can always ask them: 'i feel that this estimation is a bit too heavy, is there something you are afraid of? if so, can i help with it somehow?'

Sometimes they will simply explain it in details, but more often it is their way to prepare for unknown risks, and you can help with it most of the time.

2

There is a significant difference between an estimate and planning value and that difference is largely ignored. An estimate, provided by the people who do the work and based on historical data if you are lucky to have it, is a probabilistic range of results. A planning value, provided by the owners of the work, is a single value that lives somewhere in the estimated range, based on the degree of risk with which that project presents.

Therefore, this PM needs to collect estimates by way of a range of results. Use best, worst, and most likely cases, following Iain's advice above. The risk management process, the second step, will dictate what planning value the PM wishes to use to cost, schedule, and against which to measure performance.

2

so many good answers here... I'll try to give my two cents.

An estimation is incorrect by definition, that said it might happen that your team abnormally "inflates" their estimations, and there could be very different reasons for this, and more specifically:

  1. They previously missed a deadline and they've been blamed for that. Or their time is constantly checked and micromanaged (here is a somehow "illuminating" example)
  2. The thing they've been asked to implement is new to them, or has too many unknowns, or is too risky
  3. Their work depend on other people/systems/teams/whatever, whose behavior is somehow not entirely predictable. E.g. I have to connect to an external system and I assume that, by the time I start to develop, this system will be ready, available and its interface documented enough. Turns out my assumption is wrong and the overhead needed to make up for this situation falls on my estimate.

If your situation falls on case 1, do not blame it on your team, you'd better find the root cause and fix it as soon as possible.

Do not trust too much estimates made on case 2, do not look for "right estimates" because the only right figure you will have is the one that tells you how much time it has taken, and this you'll only have at the end of the project. In these cases there are approaches that can help the PM to better manage the intrinsic risk and be able to handle the unexpected. See for example How to assess, communicate and manage uncertainty and risk with Agility?

Bottom line is: if you're in an unstable environment, do not trust estimates made at the beginning (Iain9688 advise of continuously refining the estimates is actually one of the best and most underestimated) and do not assume you'll be able to make a detailed plan out of it.

1

I learned in my project management classes and related experience that the most accurate way of getting estimates is to ask the people who will be doing the work to estimate the work. They will know how long it will take them to do the work. Remember estimates are just a rough indicator. The critical path analysis is sometimes good here. See https://en.wikipedia.org/wiki/Critical_path_method. In addition to this I have always kept the philosophy that it is better to overestimate than to underestimate (This means you deliver within budget, while allowing for things to go wrong). Hope this helps.

0

I'd suggest doing a root-cause analysis with everyone involved, to understand why developers feel pressure to "pad" or add other compensations in their estimates. It will require some really open dialogue, but in my experience, doing anything else (like changing the process directly or involving other estimator) will only address the symptoms, probably frustrate the team even more, and you'll end up in a similar situation in a few months.

Example - http://blog.crisp.se/2009/09/29/henrikkniberg/1254176460000

And as others have suggested, aim to have the developers themselves do their own estimates, as it will go a long way towards building trust across the board.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.