Random Acts of IT Project Management

Project Management for Information Technology

Stupid Estimate Mistakes

Posted by iammarchhare on 22 June 2009

Or, rather how to avoid them.  Project management is largely about estimates and hitting them, after all.  TechRepulic did an article on the “10 ways to avoid stupid project estimates” (PDF format).  I particularly like #9:

Penalize the bad estimate, not that a task estimate is too long. When estimates are shortened, it’s generally because that shorter number is what’s expected. That is where the “If all goes well, it will take…” comes from. Be serious. When was the last time “all went well”? There’s nothing wrong with qualifying an estimate, but adding an unrealistic assumption as a way to give a bad estimate only hurts the project.

My experience has been that IT folk, but especially programmers, are an optimistic lot.  The fresher they are out of school, the more optimistic they tend to be.  Why?  In school, the programming assignments were always the type that made it easy to hit the target.  They were geared towards the topic being learned, and often the answer was spoon-fed to them.  Note, I am NOT criticizing the fact that students are not hit over the head with a huge reality stick!  However, it does shade their perceptions when they graduate.  Unfortunately, by the time their estimates get good, they tend to move into more senior non-programming roles.

Some additional methods to getting more accurate estimates:

The best case amount of time, most likely amount of time and worst case time estimates.  You know the drill here: Estimate =  (Best case + 4 x most likely + worst case) / 6.  Problem?  Many view this as a time consuming way to get estimates.  Some senior or more experienced developers may even view this as a waste of time.

Group sanity check.  If you have a mix of experienced and inexperienced developers, it might be handy to have a meeting to go over the proposed schedule before it is presented outside of a developer team.  I have seen this done twice, and I wish more organizations took the time to do this.  You have to give enough time for reviewing the schedule beforehand and create an atmosphere that encourages questions.  Problem?  It will not work correctly if management has a target date and effort already in mind, unless developers or team leads are willing to defend any deviation.

The TechRepulic paper really identifies that “reward and penalize” is one of the keys (#9).  That is, hold people accountable for estimates.  To do this, you also have to give feedback (#8).  Even at that, you won’t do any good unless you develop a culture of continuous improvement (similar to point #10).  Unless people are motivated to improve, they will not!


Sorry, the comment form is closed at this time.

%d bloggers like this: