Document Actions
on unrealistic schedules
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.
http://www.yuwantitwhen.com
What I think is really needed is some maturity and courage from the engineering management: not to say no but to help the sales and marketing organizations make the right decisions, and when they can't, don't make the decision worse by delivering a fragile product just to make a date. Nobody benefits from that: sales nor engineering.
A good engineering manager is able to strike the right balance between delivering on time (really close to on time because rarely does any delivery hit the schedule) and not impairing the underlying implementation such that it further impairs the teams ability to deliver more and quicker. Too many managers take the easy path and impair the future to make the current delivery. It's always a mistake.
What I always do, is make sure with every release I'm improving the teams ability to deliver more and faster and always with high quality. And if that means I have to go to managment and tell them the date needs to slip after making an earnest effort, that's what I do. It's never failed me and the sales and marketing teams are always greatful for it in the long run.
Dev, Sales, and Over-Commitment
The other downside is if you have a CTO or dev leader that's involved in Sales. They will commit thinking, "oh, I can code that in a day or so" and it ends up taking 5 people, 3 weeks to complete.
Sometimes, you just don't have the luxury. If you're in a start-up that hasn't got any revenue at all, and you need to add features to close deals (regardless of priority), you're going to face tremendous pressure from management and the board if you start saying "no" to everything.
The tricky thing is, don't let taking customer requests blind you from what's most important - listening to the market. Just because you are implementing things 1 or 2 customers want (based on Sales data), that doesn't mean you are market-driven.