Common project management mistakes: Estimating tasks (part 2)
Hi there,
we were quite busy over the last weeks, so updates of our blog are currently reduced. We are only going to post once a week in the upcoming month, but this should improve the quality.
Today I will continue my project management series. In my first post I described the common mistakes which are often happening when estimating tasks:
- Mistake 1: Estimation is not done by the task owner
- Mistake 2: The task has no proper description
- Mistake 3: Estimation is done by averaging worst case with best case scenarios
- Mistake 4: The tasks are too big
- Mistake 5: The tasks have unclear dependencies
- Mistake 6: The owner puts some unknown buffer time into the estimation
Please check out the first part of this article to find viable solutions to those mistakes.
The mistakes I wrote about are not really specific to a single department; most of them are quite common problems. Unfortunately, there is one department where task estimation can be very difficult. It’s obviously the programming department that I have in mind. Estimating tasks with programmers is quite an awkward business.
You need lots of knowledge and experience to get numbers that are even close to realistic. As a project manager you may wonder why this is so complicated and why programmers’ estimates are so often unreliable. There are several reasons:
Mistake 7:
Taking the estimates of a rookie programmer as the final estimate
Solution:
Programmer performance varies by a factor of 10, which means a very good programmer can solve a given problem ten times faster than a bad one/rookie. No problem, you think: just let the slowest programmer estimate the task. That will unfortunately not solve your problem.
Young programmers tend to overrate their skills and dramatically underestimate tasks. So let the lead programmers, who are able to rate programmer performance as well as task difficulty, review the rookie’s estimate. The more experienced programmers check the estimate, the better it gets.
Mistake 8:
The buffer time for the programming tasks is the same as for any other task in the project plan
Solution:
This is nothing new and a lot of people have written about this problem, but unfortunately it’s still not accepted as an unalterable fact. Maybe it’s because of the certainty that there is no simple formula to determine the right buffer time.
It really completely depends on your programming team. You might have a 100% or even 200% buffer time and it’s not enough. Track real life data and your estimates, compare them, learn from them . Every programmer has his own speed and estimation techniques. Find out which ones are reliable and which are not and adjust your buffers accordingly.
Mistake 9:
Assuming that a programmer programs 8 hours a day
Solution:
If a programmer tells you he needs one day for the task, does that mean one real life day? It depends, again, on the programmer, but you should not ask how many days; instead you should ask “how many hours do you need?”. This is very important because a rookie programmer might not have realized yet that his effective programming time is only 4 to 5 hours a day.
Mistake 10:
Changing numbers in the project plan in order to change reality
Solution:
Project managers very often reduce the (massive) programming buffer times after estimation is complete, because it tightens the project schedule and seems to save lots of money.
Well you know the answer already: this does NOT change reality and you will not save a single cent. Instead it will cost you a lot of money! Never reduce programming buffer times unless you are absolutely sure it can be done faster. To put programmers into a crunch because you reduced their necessary buffer times will damage your reputation, and the team will not trust you anymore and will sneak their own buffer times in their upcoming estimations.
Next time I will talk about crunch, a very common technique to waste money and lose good employees.
That’s it for today, thanks for your time 
.
Cheers,
Matthias
Popularity: 16% [?]
I think it also helps greatly to limit the options for estimations. Sort of what Planning Poker does.
For a while now i’ve been sticking to 1, 2, 4, 8 and 16 hour estimations with nothing in between. With 16 hours mostly meaning “it won’t be finished today, probably sometime after the same time tomorrow”. There’s also a 0 hour estimation which is for tasks that i can work off in between tasks without sacrificing anything.
Longer tasks that haven’t been broken down or aren’t specified clearly are estimated in weekly increments. Estimations are mostly pure gut feeling mixed with experience and rounding up to the next nearest time.
Btw, in this case 8 hours means a work day, eg 8 “real” hours which are 4-6 “actual programming” hours.
If a task is matched with inexperience in the field i tend to grossly overestimate the time needed. It’s better that way and to positively surprise anyone than working your a– off and not getting close to being done in time.
I think the real art to planning a project is to know when people are using high estimations to push undesired tasks back or off the project completely, and vice versa using low estimations to be able to work on something they’re enthusiastic about. From my experience this happens all the time, more so if people find they have no say in the direction of the project or their line of work so they tend to factor that in by the estimations they give.
Project managers need to be inquisitive and demanding while not pissing people off or forcing them to “just work harder”. Not an easy job. One of the reasons why something like crunch exists, right?
Hey Steffen,
thanks a lot for your insights on this topic. I agree with most of your points.
Planning poker is a very nice technique to get good estimations, but its by far not the whole story. There is a lot of psychology happening when estimating tasks. So the project manager needs really good soft skills to squeeze out the right estimations and to add the necessary buffer. It is not impossible, but its very hard to do. What I have learned for planning poker is: do not let people estimate task which are held responsible when the project is delayed
. Those people tend to estimate always too low. Its not their fault, that just is a natural thing to do.
Longer tasks should really be broken down as fast as possible, because they bring a lot of risk into your planning. Sometimes a good thing to do is time boxing.
If you are not sure how long a task is going to take, because of inexperience or any other issue, time box that task to 8 or 16 hours. After that period you should normally be able to break it down and estimate it much better.
Very interesting point about pushing unloved task and pulling the favourites…
If people try those tricks, the project manger is clearly NOT doing a good job. He should be able to know what people like and don’t like. If the people act like this, they don’t trust their project manager anyway.
Project managers do need to be demanding while I don’t think they need to be inquisitive, because that will not help anybody. They need good communication skills and have to be very honest to their team, because they need the people’s trust, otherwise they will not be able to do their job.
Crunch does exist, and some of that is surely caused because of unskilled project managers, but there are many other reason why people have to crunch.
Matthias,
I have no comments on this subject, but hell man, I’ve been trying to find you for a long, long time.
No problems, just want to keep in touch.
Colin
Wuerzburg