Learning from failure in IT
IT projects have a reputation for extremely high failure rates, with one survey finding 68% of attempts getting a failing grade. While pundits are quick to provide plausible reasons for this astonishing statistic, it is clear that IT projects in general are subject to numerous technical and organizational factors that combine to produce a perfect storm of barriers to completion. The complexity of human and business systems means that as much as we would like a perfect system of IT implementation neatly laid out in checklist points, that is unlikely to happen. IT projects have been failing for years now without such a magic bullet emerging. The true problem is that every organization and project is different, so there is simply no one-size-fits-all solution.
Fail for learning
What is going on here? Perhaps we need to look at failure differently. In business, a project fails if results don't meet expectations, so either the expectations were wrong or the implementation was wrong. Corporations have been managing this way for decades, naming success only as that which fit parameters identified in advance. This tight definition misses all the yearning, burning and learning that was a part of the failed project, which has intrinsic value. Once these peripheral successes are named and claimed, every project starts to look like a big step forward in corporate education.
Structural problems
Traditional organizations with hierarchical management find it hard to learn from any kind of failure. In these systems, it is every man/woman for himself/herself, so it is prudent to distance oneself from trouble. The “golden boy/girl” gets promoted, the one who gets things done without rocking the boat. The push is to just keep moving forward, using results-based management to identify problems and notice winners. These companies tend to look for the next big initiative, hoping that this time the solution they have bought, or pricey consulting firm they have hired, will accomplish what the last one failed to do.
Fail, then fail better
Besides placing unrealistic expectations on every new IT project, this ignores the real need to analyze what went wrong last time. Some organizations, particularly those with a collaborative or scientific culture, intuitively understand how failures eventually lead to success by illuminating or eliminating possibilities for the next attempt. They understand that experimentation cannot be confined to the research and development department, but must be embraced by all. Keep the costs of these experiments low, and employees can try and fail their own ideas, instead of waiting for directives from the executive suit.
Failure is an event, not a person
The effort to get employees to fail intelligently on IT projects in service of corporate learning won't work if it is a thinly veiled witch-hunt. People must be unafraid to try weird ideas, be honest and tell senior personnel uncomfortable truths. There must be a sincere attempt to understand what limits the failed project faced and brainstorm ways to get around them if they show up next time. The people with the best knowledge of what went wrong are the day-to-day workers who spent the most time working on the project. Their insight can be incredibly valuable and should be supported and rewarded.
