In Built to Fail: How companies like Google, IDEO, and 37signals build failure-tolerant systems for anything, Andrew Chen makes some great points. Specifically, he discusses how and why some organizations are simply better than others at handling IT and system failures.

I have a few thoughts. To be sure, failure is probably more tolerated at companies such as Google and IDEO than at other organizations. I’m less familiar with IDEO but have read a great deal about Google. (Who hasn’t?) I have also had many conversations with a friend of mine, an ex-Google employee. The interesting question seems to be:

Why does Google seem fail “better” than other organizations?

First and foremost, consider Google’s culture and business model. The company must have hundreds of projects in different stages of development at any given point. Add to this Google’s 20 percent policy allowing (forcing?) employees to work on other projects that may very well not pan out. In a way, Google bakes failure into its culture. As a result, relative to other companies, at Google there doesn’t appear to be the blamed placed on those who tried and failed.

People will ultimately determine whether these projects fail much more than any methodology or technology.

Second, consider Google’s products. Its apps are so widely used in many cases that problems will be discovered and fixed relatively quickly. A problem with a Okrut or Google Maps might be inconvenient, but it will hardly tarnish Google’s brand. In other words, Google’s projects seem to lack the same big bangs related to large IT projects:

Consider a large organization in the middle of a massive IT project affecting suppliers, employees, or vendors. In this case, failure is less acceptable and its consequences much more severe. A botched project will affect employee paychecks, corporate security, the accuracy of financial reports, and the like. This is particularly pronounced in development efforts that follow the Waterfall method.

All else being equal, methodologies like Agile software development should decrease IT project failure rates. Of course, people will ultimately determine whether these projects fail much more than any methodology or technology.