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

[dr-tectonic.livejournal.com]

Yeah, he definitely said that the target you commit to is not the estimate when you think it'll be done. I don't have the handout in front of me, but the way he does it, I think you put the target at about +2 sigma from the mean, and then you can rerun the estimate halfway through the project and move the target closer if things are going well.

See some of the other comments, also. Part of the idea is that if you're doing it this way, people shouldn't need to sandbag, because the safety margins have been taken care of explicitly.

I guess the question is, why are the managers trying to squeeze the extra out? Their part of the project came in early and under budget -- isn't that good? Do they want to increase the odds of having late penalties associated with their work?

[nehrlich.livejournal.com]

Coming in early and under budget is often not considered good in Dilbert-land. Early means your people were sandbagging their estimates, and that next time you should arbitrarily take their estimate and cut it down by the same amount. Under budget is often also bad, because it means that your project will be given less money next time since it's been shown you won't need it.

Sadly, I have often found it is to my benefit to goof around to use up my cushion rather than turn in work early because I might need that cushion next time and my employers don't understand the uncertainties associated with scheduling. My favorite example was when the MBA running one project asked us to give her a precise estimate on when we would make what was basically a scientific breakthrough. She needed it for her Gantt chart. We tried to explain to her that we didn't know when we'd figure it out; it would depend on how the experiments went. She wouldn't budge. We made up a number; it was easier than arguing.

There are also often business pressures that are swept out of sight and treated as assertions e.g. "It must be done by Date X, and it must include all of these features or we won't be successful". In an open, honest work environment, there could be a rational discussion where the realistic estimates of what it takes to accommodate those features would be balanced with the business cases for each feature. Unfortunately, most work environments are not like that. Instead, the communication is happening through a game of Telephone such that that discussion can't take place.

[dr-tectonic.livejournal.com]

Yeah, I sorta think the next big socio-technology that we need to develop is a way to shoot people's careers in the head when they follow that particular path of unreason.

[nehrlich.livejournal.com]

I think we're slowly moving in that direction because of the increase in employee mobility, especially in the realm of high-tech workers like developers. If they feel ignored and Dilbert-ized, they will move on until they get someplace where they don't. The places that do honest schedules will not only get better developers, but I'd like to believe they will do better as businesses since they will be less likely to miss their targets.

Our prof said last night that a recent survey of IT projects showed that 22% were completed within the original estimate, 52% were late by an average of 100% (double the original estimate), and 26% never finished. And developers wonder why their estimates have no credibility. Admittedly, many of those estimates were poorly constructed because of management pressures, etc., but there's definitely a competitive advantage to being able to deliver on time repeatedly.

Then again, most people don't want to hear how long a software project will actually take. "It's just software! Why does it take that long?!" So even if you give them realistic estimates, they don't believe them.

I am full of cynicism and bitterness. Can you tell?

[nehrlich.livejournal.com]

Oh, I also meant to say that the bit where you rerun the estimate and update it throughout the project is a great idea. I really liked Steve McConnell's description of that process in his Software Project Survival Guide. Or maybe it was in Scott Berkun's Art of Project Management. Iterations are much better for scheduling and for dealing with a fast-changing environment than trying to do everything at once.

[hapaxeslegomena.livejournal.com]

Forgive the ignorance, but: What’s a “sigma”?

Now that they’ve reorged our company and gotten rid of all the project managers, it falls on me (as the QA guy) to give daily reports to the CFO about why the IT projects aren’t on schedule.

So I feel like maybe I should find out what the Hell you guys are talking about in this thread.

[dr-tectonic.livejournal.com]

No worries!

If you've got something that follows a normal distribution (aka Gaussian distribution or bell curve), the variability of the distribution (the standard deviation) is customarily represented by the letter sigma. It's a measure of how wide the curve is.

The useful thing is that about 2/3 of the area under the curve is between (mean+sigma) and (mean-sigma). If you go out to 2 sigma on either side of the peak/center, you've got 95% of the area, and 3 sigma gets you to about 99%.

So if I do an estimate the way this guy described and it tells me that, on average, my project will take 20 weeks, with a standard deviation of 3 weeks, I know that I can come in under deadline 97.5% of the time if I commit to doing it in 26 weeks (+2 sigma). [That's assuming that the estimate is accurate, of course.]