Unexpected success

George Lucas is know for the "Star Wars" movies, some of the most successful movies of all time.

Yet I suspect it started differently.

In 1977, Lucas had the movies "THX-1138" and "American Graffiti" behind him. "THX-1138" is an obscure movie, now most famous for being one of Lucas' creations. It is a decent movie, and respected by science fiction fans, but not known outside of fandom. "American Graffiti" was a successful movie: popular in its day but now more of a fond memory. (When was the last time you watched it?) There is nothing in either movie that says "genius movie maker".

I suspect that George Lucas made "Star Wars" and was hoping for a reasonable amount of success, and that he was not expecting the movie to become the foundation of a franchise and marketing empire.

I believe that Apple, with the first iPhone, was, like George Lucas, hoping for a reasonable amount of success. I also believe that the tremendous response far surpassed Apple's expectations. (I suspect it also surpassed AT&T's expectations, which conveniently explains the difficulties encountered by so many new iPhone customers when they activated their accounts.)

Their successes were due, in part, to the gambles that each made. Lucas used computers to control the models of X-wing fighters, selected classical music, and released in the summer. Apple created an elegant design quite different from contemporary cell phones, leveraged its "easy to install" ideas for apps from Mac OSX, and built an interface that was different from the traditional Windows (and even Mac) OS.

Lucas' work stamped itself onto our culture, with "The Force" and even the quote "I've got a bad feeling about this".

Apple's work changed the course of the industry, such that Microsoft Windows and the "windows, icons, mouse, and pointer" theme is no longer the design leader. Microsoft's introduction of Windows RT and the "Modern" UI shows the effect of the iPhone success.

All of which perhaps is evidence that success is something that cannot be planned, timed, or scheduled, and that success can come from taking risks and ignoring established ideas.

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.