Jamie Test, Step 8
Let team members estimate their own schedules
I really don't have much to say about this that Joel Spolsky and Erik Bethke and Steve McConnell didn't already cover.
I have a friend who has a friend who is working on a high-profile game who is afraid that they don't have enough programmer bandwidth to complete their feature set. I say to that friend: "A Hobbit Can Contend With The Will of Sauron." If you are at a company where they do not ask you to estimate your own schedule -- and in my opinion even asking something like "Do you think you can get this done by Friday?" counts as not asking, because programmers are notoriously underconfident in their estimating abilities and would rather pass the responsibility upstream -- then find some time, either on a weekend or when the boss is not looking, to write down a list of everything you have to do before you ship, and estimate how long each thing is going to take. Then add the various buffers Joel suggests in his article. (25% debugging, 10% unplanned features, etc.) Then compare your results to your project's "alpha" or "feature complete" date. You will probably find you're Not Going To Make It. Take those findings to your lead and ask to have features transferred from you to the other programmers. Recommend that you have the other programmers do the same thing, to make sure that they're going to make it. You will probably find that none of you are Going To Make It. At that point, reccomend that they ask their publisher for a) More Money, b) More Time, c) Less Features, or d) some combination of the above.
Your lead won't want to hear it. He may say something like, "How do *you* know this is how long it will take?" He may say something like, "I think you're just lazy!" Remember your people skills. Say things like "I'm concerned about the accuracy of our schedule" rather than "This is fucking bullshit!" (I'm not very good about this, myself. But I try to save the bullshit-calls for emergencies.) How you handle this conversation could mean the difference between saving the project and ruining it. If he's a Good Lead, he won't kill the messenger, and will take your advice, and possibly save the project. (Peter Drucker says good leaders are secure enough in their leadership that they foster disagreement among their 'followers'.) If he's a Bad Lead...then I don't know what to do next. Maybe you can go over his head, or maybe your team has a way you can give feedback anonymously.
I've never been in this exact situation myself. I have been in the situation where I was handed a project--I was the only programmer--and the first thing I did was come up with estimates and it turned out we didn't have enough time. I immediately told the producer, who happened to be a good friend of mine who got me the job in the first place. He asked me if I'd be willing to put in overtime and I said no. They accepted that and threw more money at the project. Later, when an unplanned feature cropped up, and the code I'd have to be dealing with was cryptic stuff from another dimension, I flatly refused to add the feature. The boss himself came by and asked me if I'd reconsider. Here I was more stubborn than I should have been: I didn't even give them an estimate. I said it was impossible. Honestly, given some amount of time, I could have solved the problem, and once I told them that amount, they probably would have agreed that the bang wasn't worth the buck. On another project with the same producer, we were in the last few weeks and I realized we weren't going to make it. They found another programmer and together we managed to break Brooks's Law and finish on time. And there have definitely been times were it seemed like upper management was trying to push my team around and I pushed back. (Probably could have handled those times better.)
The thing is, times were different then. Game programmers were in short supply or high demand, I'm not sure which. I didn't have to worry about finding another job. If I had to (and it never did come to that) I could have voted with my feet. These days, with the major publishers' ubiquitous mantra of "fewer better games" it may be tough to land that next job. So don't be as reckless as I would have been. Make a sincere effort to institute change, don't flip out, and, if your effort fails, send out your resume. (But be careful about it. There's only a few degrees of separation in our industry. There's a good chance that the person you send your resume to is friends with someone on your team! And your headhunter does not care! Very few people at Treyarch send out their resume without me finding out about it.)
A hobbit can contend with the will of Sauron.