Bill Miller writes about unrealistic schedules:
I often wonder why software teams always seem to be committing to unrealistic schedules. You know when the sales team signed a contract with a customer to deliver functionality on a date without ever asking the engineering team whether it were possible. Never mind the roadmaps identify an entirely different set of functionality than what was committed. And guess what? The product roadmaps can’t change either; the sales team has signed contracts on that functionality too.
Product managers, sales people, marketing departments, and executives make commitments all the time--and often they're unrealistic. We commit to a roadmap and then change it. We can't really commit to schedules when the feature-set keeps changing--but then we commit anyway. Yeesh. We have long advocated time-boxing as a method for balancing the schedule and commitments. Come to our Requirements That Work class to learn an agile approach to product planning.
Years ago, the president of a startup asked the product manager to commit to an aggressive date. The product manager discussed it with the dev lead and the whole team and agreed that, yes, they could make the date but it involved a fair amount of overtime. The team agreed to work Saturdays until the project was complete. When the president announced the decision that development would work Saturdays, he also committed the entire sales department to work Saturdays until the project was complete.
The moral: being a team-player means that the people making the commitments should have some skin in the game too.
