Automate your Failure Process

“The end result is a … new system that, if actually deployed, will leave our country more vulnerable than the existing yet flawed system in operation today”

Dept. Homeland Security, August 2008
Project name: Railhead
Cost:$500M

Most IT projects don’t assume the terrifying scope or budget of “Railhead.” And not all failures are as catastrophic, but the failure rate for everyday software and IT projects is shockingly high.

Why?

IT Projects are Special

These projects solve problems for a wide variety of systems, architectures and users. Since a lot can go wrong, success requires having at least the best tech and the best technicians.

But if having the right tools and smiths were all that it took, then IT would fail at the same rates as other infrastructure projects and the solutions would be the same –smarter sourcing, and tighter scheduling and budgeting. Smarter workers would shrink timelines. Better tech would expand the scope. And project management could forecast accurately.

IT Projects may focus too much on IT, not the Project

As this joint Mckinsey-Oxford study notes, IT projects seem to decay, or at least diverge from forecast, over long time intervals:

“After comparing budgets, schedules, and predicted performance benefits with the actual costs and results, we found that these IT projects, in total, had a cost overrun of $66 billion, more than the GDP of Luxembourg. We also found that the longer a project is scheduled to last, the more likely it is that it will run over time and budget, with every additional year spent on the project increasing cost overruns by 15 percent.”

The study suggests that focusing too much on IT infrastructure “perfectionism” can often be a problem:

“One common pitfall occurs when teams focus disproportionately on technology issues and targets. A bank wanted…to overcome inconsistencies that occurred among its business-unit finance data…However, the project team focused purely on developing the IT-architecture solution for the data warehouse instead of addressing the end goal, which was to handle information inconsistencies. As a result, the project budget ballooned as the team pursued architectural “perfection.”

Automate the Failure Process

So long as you are working in a flexible IT environment like CloudShare, failure is a good thing. It means you learned what didn’t work with no cost to the user or your infrastructure. You can revert to a safe image, triage the bug and move on. If more of these failures reach development and testing sandboxes, fewer failures will reach end users.

This means infrastructure is never a bottleneck, and the project is not a “Railhead.” To learn more on how CloudShare can help you save your assets, read this blog post.