What should the penalty/response for missing a deadline be?

Your first reaction should not be what to do in response to the missed deadline, but to analyse why you missed the deadline. The response to missing the deadline would then follow naturally from that as a consequence of the reason.

For instance, if everyone involved didn't do their job, fire them.

But if they did their job, and more, then why was it still missed? Too much other activities done by the same people? Too big a scope for the deadline (ie. unrealistic deadline). Or ... etc.

The top reason for missing a deadline in my experience is that people aren't allowed to work 100% on the project at hand, and thus any estimates you might have, although accurate on their own, aren't really useful at all. That, plus unrealistic estimates and deadlines.

Oh, man...

First of all, there are external deadlines and internal deadlines, and they should be different.

What happens with an internal deadline is the frequency of activity increases as the deadline approaches, reaches a peak at the deadline, and then falls off as the deadline recedes. So plan the external deadline to follow the internal deadline by a couple weeks at least.

Then, make sure the deadlines are realistic. Partly you do that by involving the developers in setting them, and in deciding what will be accomplished.

Finally, I've mostly been a developer, but once when I took a stab at management, I would never want to take the latest-and-greatest version into a conference or presentation. I would want to take a version that was at least a few weeks old and that I knew where the problems were and that I could be sure would not contain unpleasant surprises.

As others have mentioned, before talking about penalties, start with "how do we determine whether these deadlines are realistic"?

Or as my boss once said, "We'll be happy to work a plan when you give us a plan that works".

I still think that should be on a t-shirt.

Your question is inherently flawed: it assumes that punishment is the best way to manage people. In general, that people don't respond well to punishment or threats of punishment; it brings out the worst behaviors, make the motivation external, and distracts from internal motivation. Rewards and bribes (threats of reward) are the other side of the same coin, and do no better.

These forces are built in to work for hire, however, so you'll never get the best creative work out of your programmers, but you don't have to make it worse by punishing them when they miss a deadline.

Instead, meditate on the creative process, the chaos of multiple people doing creative work, and what tools are effective in managing chaos.

To manage any chaotic system, do lots of measurement and be ready to change course quickly. In the case of programming:

• Take the smallest steps possible. Don't "break the task in to small steps", as you'll waste a lot time planning steps that won't work out like you planned. Chaos, remember?

• Pick the smallest steps that deliver the most value.

• after a short period, reevaluate your plan based on what you've learned

• deliver working software to actual, real customers as soon as possible, so they can tell you what you should really be doing.

You may recognize this as the thinking behind SCRUM.

"Who does what by when" is a question that each project team member must provide a professional commitment/response to in any profession. As far as when a deadline is missed use that evidence to improve the estimating process and ask the individual to make a new commitment. This assumes that their was in fact a commitment made to the previous deadline. A great series on 'Who does what by when' is available at manager-tools.

Also, I would recommend that you distinguish between Estimates, Targets and Commitments. And manage the 'gap' or the risk between the estimate <--- gap ---> commitment. Look at Software Estimation: Demystifying the Black Art.