The project delivery date based bonus plan (which should be called the "Psychic Powers Bonus") is the stepmother of all bad ideas. Here is how it goes: the CEO gives a big presentation and rallies the troops to really focus on this next release as it is critical to the future of the company (so far so good). To make it clear just how important this is, we're going to give everyone a 15% bonus if we deliver on time! The wheels have just fallen off. Regardless of the amount, its structure, or if it's a trip to Fiji (and yes that has been done) the CEO has just made a big mistake.
Why exactly is this kind of bonus so appealing to managers? The answer is that superficially it appears to meet the "you get what you measure" criteria which is an offshoot of the notion that your bonuses should drive useful behaviors. The truth is, it does absolutely nothing of the kind. The appearance is purely on the surface.
Consider what you are measuring when you bonus based on completion dates: our ability to predict the future. This is a great idea for stock traders, but an amazingly bad one for engineers. This is true even if the dates were formed by the engineers themselves (which they frequently were not). The resultant behavior (if the system is fully inwardly controlled) is that engineers learn to give ridiculously long estimates which they can easily make. I seriously doubt this is the behavior any manager wants to drive.
If the system is not inwardly controlled and the dates, features, etc are driven externally (by managers, customers, etc) we are still giving bonuses based on psychic powers, but the psychics we are using are no longer the ones getting the bonus (or not getting it) . One outcome can be that hard work takes place followed by no reward (or even punishment) thereby ecouraging employees not to work hard in the future. This is called "beating the team with a carrot." It's also possible that the team will not work hard and get the bonus anyway in which case the bonus is no different than just giving them an across the board raise. Lastly, we can have the case where the goal was properly set, but the atmosphere of panicked rushing created by the bonus produces tunnel-vision that keeps the team from making its goal.
This last case is worth some additional explanation. When incentives to think only about the current release are too high all sorts of bad behaviors creep in. People throw continuous refactoring and unit testing and documentation and design review and code review and quality and usability out the door faster than a hummingbird on cocaine. I will do this myself given the right motives (like the company going out of business or losing 50% of its market share to a competitor) so that's not a condemnation, just a reality. When we have a choice between incurring technical debt and a "hard" deadline the definitional right answer is to incur debt. Bonuses should not drive short term behaviors like this over long-term corporate health unless there is a very specific short term reason to do so.
The one argument I get the most about this is that every employee needs pressure to get their job done and this kind of bonus gives them pressure to perform faster. While the "every employee" part is not true, I have found that a certain amount of release pressure can be a healthy thing. I have also found that even ridiculous schedules can be met (doing some of the things I mentioned and a few others that cannot be described in polite company) but you will be sorry for it later. Applying constant pressure in the manner that this bonus approach does has the very well documented affect of creating a Big Ball of Mud that cannot be maintained and that drives the best people out of the company. I've seen this happen so often that I have long ago become skeptical of the value that this pressure brings.
Ultimately people who favor deadline bonuses fall back on the old "well there are no perfect solutions and something is better than nothing." I suggest they go back and try blood-letting or arsenic to treat headaches under the theory that it was the best medical solution available at the time. In this case nothing IS better than the something in question.
There is one way to give effective bonuses to people for predicting release dates, and that is to have people not directly doing the work or managing it get a bonus based on their ability to guess the actual release date. This is like giving stock brokers money for predicting the market. If knowing when the product will actually go out has value enough to support such a position then sure, at least you will be paying people for what you want them to do. It won't get the product built faster, but that's a different goal.
Ultimately, people may ask what kind of bonus companies should give. For startups I recommend just giving options according to market principles. For big companies don't give anything and just pay them more or, if you like lotteries, let their bonus be based on overall corporate goals. They'll realize they can't really affect it and just treat it as a lottery they get to win every once in a while (cynicismLevel == 8).
I really do think there must be something better but in all honesty the only bonuses I've seen that are truly effective in development organizations are either small private ones (given to a person for a truly outstanding effort) or options. If you've got something better, let me know I'm all ears.
