Ok, in eXtreme/Agile it states that you don’t set deadlines or you’re project is doomed (ok, so that is VERY paraphrased, but the point is there so read on…) If project success is measured by success of achieving features by set dates than at least 99% of all projects fail, if not every single one to have existed. Sadly, in many surveys this is proven to be true.
The first step towards setting a date is predetermining that a project will achieve X features, then setting arbitrary dates for the completion of those features. The reason I write arbitrary dates is because anything further than a few minutes to a few hours is a HIGH RISK estimate. No matter how many books, theories, facts, surveys, and other information is provided it seems this is still done.
What do we end up with? We end up with projects that fail, over and over again, to achieve their stated goals. Of course a lot of these projects do achieve some type of success, but rarely defined by their originally stated schedules and goals.
Microsoft Windows, everything from 2000 to XP, and now Vista have all done the same thing. They’ve failed based on their original stated goals. But seriously, could they be considered failures, really? They’ve succeeded in generating billions upon billions of dollars for Microsoft, I would NOT call that failure.
So this perception though, regardless of the money made, is that scheduling is a failure. The perception of Microsoft is that of failure after failure to deliver. Meanwhile, we have another company who has not achieved anywhere near the level of revenue, Apple. Does Apple have this dilemma of being seen as a failure? Does Apple deliver on its respective promises?
No. Apple is considered successful!
One of the main reasons is because they don’t over promise and then under deliver based on hyped feature lists and arbitrary schedule deadlines! This practice is one of the most misunderstood yet probably the simplest approach to features and scheduling out there.
Either set a date and deliver something by then OR set certain features and then deliver them when they’re ready. One or the other, anything else dictates failure, the perception of failure, or the cold hard reality of zero revenue failure! There have been enough companies in the last decade, even more in the last two decades, that have proven this to be absolutely true.
So with that in mind, when I read Close Curtain Development at Microsoft, I thought immediately after reading, “Yes, this is absolutely a good policy!” Microsoft shouldn’t be spilling their guts about every single little feature they “want” to get into an application as they have in the past. It has done horrible things for their reputation and should stick to the approach as I’ve stated. It will do better for the consumer, it will do better for Microsoft, and when the features are ready they can be released – gasp – WORKING!
