I like the Bruce Henry / LiquidPlanner approach to estimation. It makes good sense.

Regards,
Rick Cogley
Tokyo

As far as ranges go, as I said, I agree with that too, however in our business environment a ‘range’ estimate is 100% unacceptable to the business unit. It’s fast-paced, there’s not a lot of slack in the project plans allowed, and once you commit to a deadline, you must achieve it.

A strong developer who is an effective estimator should by all means be allowed to give more broad estimates. My experience is that not all quality developers are also quality estimators- there’s a difference. Some of them are excellent at it and should be granted latitude as a result. One of our best developers is frankly a horrible estimator.

For those that are not good at estimating, while they may rail against this method, their estimates get much better when it is used. Taking the time to break down tasks gives me better estimates, helps them plan their work, and for some of our team it has actuall made them faster and more accurate at their jobs. If your staff is of quality that longer estimates are reliable, than by all means go with that.

That’s a lot of what this methodology is about. It is definitely not for all shops and skill levels. It is aimed at the shop without the senior, experienced staff that is always right on their deadlines. It’s aimed at the shops where the deadlines can’t be missed and precision matters.

As for whether or not it is micromanagement, that to me is as much about attitude as it is about level of detail. I am currently following up with my development team, and the rest of my project team, on a daily basis, and they are responding well to it. Part of what I do is not only ask them where they’re at; I bring them information from other team members, I find out if there’s anything I can do for them, etc. There’s another manager in our offices who is considered to be a horrible micro-manager and is much hated for it, even though that person tends to follow up with people only once or twice a week. Whether or not you are micromanaging is, to me, about whether or not you are helping them or getting in their way, not how often you communicate.

Since adopting these methods, we’ve seen a huge increase in the pace at which our project team is moving, attitudes are generally better, and we’re hitting deadlines more effectively. A lot of people even stop by and give me follow-ups on their own in person now, just to check on the latest project news while they’re there. It makes my job much easier and keeps people engaged and communicating.

I certainly acknowledge that there’s situations where this methodology would be a dismal failure, it works for us.

I would be interested to know what course of action you would recommend when a “1 day” task is not completed? Is it wise to assume that all estimates for 1 day need revising to be 2 days? Or is it better to break down the task into further sub-tasks at this point? I’m not sure.

In my experience strong developers (the most productive and often most critical to the success of your project) will resent tracking a plan at this level of detail. Killing the motivation of your most valuable team members does not make sense to me. I have found it is better to allow strong developers a significant amount of freedom for how they estimate, track and report on tasks that they are responsible. I would reserve “micro management” for those who struggle to be productive without it. I would say that this is a textbook case of a management/leadership trade-off (see my post on the subject at http://outofthetriangle.wordpress.com/2007/07/16/management-and-leadership/).

That is an important key, I think- what is your company’s culture? What is your business owner’s goals?

I think it’s the old “cost, time, or quality” thing. You can give good estimates, hit your date exactly, and hit your budget exactly, or you can move fast and give up some accuracy. This is good food for thought about estimates. I’ll ponder that during my trip to DC tomorrow; look to see another post on this subject soon.

Those high level estimates are what often are so wrong (as you pointed out). I think that one of the biggest reasons is that as project team members we’re giving estimates like “2 weeks”. “2 weeks” isn’t really an estimate, it’s a guess, a prediction.

An estimate is something like “1-4 weeks” or “3-5 days”. It really should be a range. One big downside of single-point guesses is that the guess is likely to be treated like a promise. On the other hand, giving a ranged estimate opens the discussion of what could happen (risks) that would push the effort towards the worst case end of the estimate or bring it in towards the best case end.

One of the primary problems is that project managers need a single number to plug into MS Project (or any number of similar tools). That coupled with the observation that these single-point guesses (especially at the high-level) are treated as promises pretty much make a person want to give up on high-level estimation altogether.

If you always give all of your estimates in ranges (e.g. 4-6 person weeks, 1-3 days, 6-9 staff months, etc) it is quite clear that it is an estimate, not a prediction or a promise. Giving a range opens the discussion of what could happen (risks) that would push the effort towards the worst case end of the estimate or bring it in towards the best case end.

Another nice thing about ranged estimates is that when you are asked to estimate something with poorly defined requirements you can give wide ranges to communicate the uncertainty. Well defined, believable requirements get estimates like 5-7 weeks whereas poorly defined, nebulous requirements get estimates like 4-20 weeks. This is especially true when giving high-level estimates.

There’s pretty much no way to get around doing high-level estimates. Your business needs some idea of the investment required to complete a project in order to make trade-offs. Hopefully this happens before your development team spends a bunch of time doing detailed estimates. Also folks in other departments (e.g. marketing, operations, manufacturing,…) need some idea of when they are likely to take delivery of the software. A team that can accurately (not precisely) give high-level estimates for these things gives their company a real competitive advantage.

So while it is frustrating, there are ways to do it and retain your sanity.