The 3% solution

Banks, at least in the old days of the 1980s, did not want all of their customers to pay their credit card bills. They wanted a default rate of something greater than zero. Banks wanted about three percent of their credit card customers to default -- to make no payments.

Their logic was as follows: The bank could enact strict credit checks and lend money to only those customers who would pay them back. But doing so would reduce the number of customers with credit cards, and thereby reduce the profits from credit cards. If banks loosened the rules and allowed more customers to get credit cards, some would default -- but only a small number of customers. Many of the "new" customers would pay, even though their credit rating was not so great. More customers would repay loans than would default, and the bank would earn more profits overall. Allowing for some failure increased the total profits.

In software development, we strive to reduce the number of defects in software. In the management of software development projects, we strive to control the cost, the delivery schedule, the features delivered, and the quality. These are all good objectives, but sometimes we can focus too much on the process and lose sight of the end goal.

Organizations enact policies to control projects. Some organizations have informal policies; others have stringent policies. Some projects (such as control systems for atomic energy plants) need very specific policies. But not every project requires such minute specification and control.

Yet some organizations push for (and carry out) very specific procedures, in an attempt to eliminate all variations from the project plan. This is equivalent to a bank limiting credit cards and loans to only those customers with the best credit scores. The process can work, but it reduces your effectiveness. For the bank, it shuts out a large number of customers (some of whom will default). For the software development effort, it limits the project to those features that are guaranteed to succeed. In both arenas, the organization achieves less than it could.

As I see it, the best strategy is to allow for failure -- a small number of failures -- with a process to recover and correct after a failure. Attempting to implement twenty features and succeeding with sixteen (failing with four) is better than attempting (and succeeding with) a more conservative feature set of ten.

If your goal is to avoid failure, then the best strategy is to change nothing. If your goal is to advance, then you must accept some risk of failure. The important thing is not to avoid failure but to recover from failure.