Even though it seems unscientific ("take your figure and triple it/raise it to the power of 2/add an extra zero etc.") I've seen that recommended both in academia, and in the real world, and seen the reasons for it pan out - programming has this insidious tendency towards underestimation of the time it will take, in everybody....and to overlook or underestimate critical details like testing, backup, migration, training or maintenance. You just need to know that, and act accordingly.
The book [ame=http://www.amazon.com/Waltzing-Bears-Managing-Software-Projects/dp/0932633609/ref=pd_bbs_1?ie=UTF8&s=books&qid=1217440604&sr=8-1]Walzing With Bears[/ame] should be required reading for anyone near the business of software development. If you want to know about how to get accurate projections, of which risk management is
key, with realistic projections, this is your book.
If you work in a business like mine where the guy who does the realistic projection and delivers on time is looked down on and fired while the guy who gives the great projections and is always late is lauded as a go getter and moves up the corporate ladder, probably not the book to read. I'm betting the developers gave a great estimate at a low cost, got the job, and then promptly took their money to the bank while WotC floundered over their trust of a group who gave an impossible estimate.
Note: If an estimate looks impossible, then it is! Go with the honest programming contractors, people! They might not tell you what you want to hear, but maybe what you want to hear isn't going to happen no matter how much optimism you have! Rushed projects not only have more bugs, but they also take
longer! Nobody wants to hear it, but thems the facts.
People keep saying in this very thread that Gleemax was a great idea with poor implementation. I totally disagree with that sentiment. The idea was made up almost entirely of scope creep. It was, by definition, in software terms a Bad Idea (tm). There were no clear cut goals, no realistic timetables for those goals, and no single driving force behind the development process. You can't go into a software project with a malleable, nebulous, undefined project scope. You. Will. Fail.
Gleemax was doomed from the beginning because they wanted it to be all things to all gamers. They should have started with a few key features, which they would work toward before anything else, with a very clear timetable for when each part would be rolled out based on factors which are totally predictable if one does the research.
Anyway, it saddens me that this could fail so badly when it didn't have to. Managing a software project is different than any other managerial task, with its own set of rules. Too many software projects fail. They don't have to. There's no reason they have to fail.