Uncertainty

[dr_tectonic]

Just went to a neat seminar about project management and estimating how much time a project will take.

The interesting thing about it is that the hardest part of managing uncertainty is getting people to admit, even to themselves, that things are as likely to come in above the mean as they are under the mean. Once you've overcome that psychological barrier, thinking rationally about it is pretty easy, folks are just really loathe to acknowledge the possibility -- the likelihood, even -- that things will go wrong.

Comments

[backrubbear.livejournal.com]

There's an unfortunate circle of death involved in the whole project estimation process. I'm sure you're aware of it, but I'm always curious how other people deal with it.

Most people who are wise will "Scotty" their answers. Their Scotty-factor may be a percentage (15%, 50%) or it might be a whole multiple.

The unwise people give a best-faith estimate to their managers. There are usually a lot of factors the person giving the estimate is unaware of, so their number is low through no fault of their own.

Management often doesn't have well defined requirements. This means that no estimate can be good.

Management also knows that their people often Scotty their numbers. They can either add their own padding, or subtract it.

Bad management will simply pick a fixed date with no regards to any estimates.

IMO, there's plenty of blame to pass around. :-)

[dr-tectonic.livejournal.com]

The Scotty-factor on my latest project was x4, and it's coming in slightly over -- which really says more about my own estimation abilities than anything, and is one of the reasons I padded it so much.

Yeah, he actually talked about how meaningful estimation depends on being able to have an adult discussion about uncertainty with your Darth Vader manager. If you say that you honestly think it'll take 5 months, but could shift a month either way depending on how things go, and the manager says "do it in 2", the problem is not estimation.

The stuff he presented is also entirely orthogonal to padding for things like how much time you lose each day to required activity that isn't working on the project. This was all just uncertainty related to the amount of staff-days of work needed, not actual calendar time, which is kinda neat.

[backrubbear.livejournal.com]

"Overhead" is a concept a lot of programmer folk have difficulty wrapping their minds around. :-)

[dr-tectonic.livejournal.com]

Overhead! That's the word I was trying to think of! I think my brain refused to suggest it because when we talk about overhead here at work, it's always in a financial context.

"Overhead" is a concept a lot of programmer folk have difficulty wrapping their minds around.

That surprises me. Just about every resource on a computer has overhead, so it's hardly a foreign concept...

[backrubbear.livejournal.com]

While programmers readily understand overhead, they usually don't apply it to themselves.

I suggest going around and chatting with yours. Ask them how many hours of the day they think they're productive in each of their tasks that would be reflected in a project plan. I'd bet you a drink that they'll overestimate by at least an hour or two.

[dr-tectonic.livejournal.com]

Heh. "My programmers" consists of me.

And I have no illusions about my own (in)efficiency.

Fortunately, when I am doing something productive, my output rate is usually pretty high, so it all works out in the long run...