Tolstoi’s Anna Karenina opens with this powerful, infinitely quotable statement:

All happy families are alike; each unhappy family is unhappy in its own way.

It’s not a universal truth, it may not even be empirically stable observation, but it sure feels relatable.

We can learn from this, reasoning by analogy.

I want to introduce to you the Anna Karenina principle of software failure.

All successful software projects are alike; each failed software project has failed in its own way.

You will definitely have encountered a headline like “Why Software Projects Fail” in books, reports, conference talks and presentations, or project post-mortems.

When it comes to big failures in the industry, we usually talk about government-funded projects for new software (or worse: rewrites). There, it makes sense to spend the effort to attempt a formal analysis because tax payer money was involved.

Software rewrites that fail for private companies hit differently than UK’s FiReControl failure (~US$730). There’s a whole list of known large software failures.

Apart from becoming a data point for statistics for which percentage of software projects fail, I’m not sure we learn that much from these.

Investigating why a project failed means to teach us how to avoid failure.

But I believe we cannot learn that much from failure as reasons to fail are too unique, as are software projects. Once the failure reasons have been sufficiently generalized to re-apply to your situation, the reasons to fail become mere clichés.

Instead, we should to investigate how to succeed.

Success is not merely “don’t do anything from this list of failures.”

(Unlike the Tolstoi quote, success, of course, is not that uniform either: an Open Source project in a particular niche succeeds differently than NASA space craft controls.)

Not only can it be true at the same time that a failed project and a successful project share an observable metric that is associated with higher risk and failure, the successful project succeeds in spite of e.g. bad decision-making and technical difficulties along the way. “Avoid technical difficulties and bad decisions” won’t help you there.

But figuring out how the successful project weathered their storms may.