Bob Sutton, at Work Matters, outlines a strategy for encouraging innovation. The most notable aspect: awarding kill fees for bad projects.

Sutton cites evidence showing that creative geniuses are notorious for leaving long strings of failures in their wakes. However, their failure rates (their batting averages, if you will), are no higher than yours or mine.

[There is] little evidence that creative geniuses have a higher success rate than their more ordinary counterparts; they just take more swings at the ball … The most creative people — and companies — don’t have lower failure rates, they fail faster and cheaper, and perhaps learn more from their setbacks, than their competitors.

One barrier to the (ultimately effective practice) of failing quickly, is the “escalating commitment to a failing course of action.” We’ve all seen this: companies become so heavily invested in a project that killing it begins to seem impossible - even if they know that it might be the right thing to do.

Merck pharmaceutical has gone so far as to institute “Kill fees, [which] pay out serious dollars to scientists who pull the plug on failing projects.”

Ultimately, Sutton puts forth my favorite line: “reward success and failure, punish inaction.”

Reminds me of another favorite quote: “I’d rather get fired for something I did, than something I didn’t do.”

It’s doesn’t surprise me any more when “project success” checklists fail to include change management, training, and documentation. So, when they make even the bottom of the list, it feels like cause for celebration. Michael Krigsman at the Project Failure blog puts forth 6 tips to reduce IT project failures. Last, but not least, among them:

6. Change management, documentation, and training are important. To be successful, users must understand the project’s goals, status, and impact on their jobs. Many projects pay too little attention to training and documentation, especially when the project starts to run over-budget. This oversight reduces productivity and can negatively impact the project ROI. In extreme cases, users simply don’t use the new software, bringing the effective ROI to zero.

So, the last few words in the last paragraph tell us about something that can “bring the effective ROI to zero.” If that’s the case, why is it so often at the bottom of the list? Or, as Michael states, ignored once the project starts to run over-budget?

One hypothesis I have: Project success for the software team isn’t measured on user adoption - or ROI of any kind. Instead, they’re measured on functioning screens and transactions. It’s up to the business to actually use the stuff.

Reminds me of a health club membership; just spending a lot of money on it doesn’t make you lose weight — you have to actually use it.

Here’s a great list of 101 ways to know your software project is doomed. From Codesqueeze.com via Michael Krigsman.

A few of my favorites:

#25. Project estimates magically match the budget
#35. Your manager thinks MS Project is the best management tool the market offers
#46. Your manager thinks being SOX compliant means not working on baseball nights
#50. Your manager spends his lunch hour crying in his car (true story)
#79. Budget for testing exists as “if we have time”
#100. You have been 90% complete 90% of the time

My suggestion for #102: Your manager believes the software salesperson who says, “Training’s included.”