To Succeed, Embrace Failure

We all know that enterprise IT projects are hugely expensive. Through my 20 years of Australian Enterprise IT I’ve seen implementation projects that cost more that development of the original software. Furthermore, many of those projects either fail or deliver marginal improvement over the processes that existed before the project.

This phenomenon used to have only marginal impact on the performance of major enterprises for several reasons. When say a financial services enterprise is employing a lot of flesh-and-blood people sitting in brick-and-mortar branches, the cost of software they implement doesn’t make much difference. Similarly, superior software was hardly a factor in competition.

However, “for the times they are a-changin’”:

• More and more operations are moved to the Internet, reducing “brick-and-mortar” costs and making software projects visible.
• Industries are moving towards Enterprise-as-a-Platform model where competitors may source human effort from the same workforce providers or subcontractors, thus making processes and software that enables them the key differentiators.
• Responding to popular frustration, governments increase pressure on removing barriers for competition and breaking long-term holds on customers. At the same time, new entrants are trying to break in.
• Software plays more and more critical role in an enterprise. What was a data storage/retrieval tool replacing physical retrieval of folders from cabinets only 20 years ago, is now the skeleton of an enterprise. Business processes used to be in the heads of trained staff, they are now coded in the software.

To survive and prosper, enterprise should learn to implement innovative software quickly and on a budget.

The main problem is fear of failure. An enterprise project would not “fail forward fast”. It must succeed. There is no enterprise analogue of “validated learning” promoted by “The Lean Startup”. An enterprise IT project is not supposed to learn by trying and failing. Instead, the project should eliminate chances of failure by selecting reputable partners and vendors, building consensus among and whenever possible following the road well travelled.

However, these steps that do sounds reasonable are the major contributors to enterprise IT woes.

1. By trying to ensure that all necessary parties are consulted and signed on, the existing processes are preserved, as complicated processes are most effective defensive devices for middle level management, and they are all given seats at the table to protect them. Not surprising many processes still presume the files are made of cardboard.
2. They will engage top-tier consultancy to do the work, and chose for a solution that was done before. Big vendors’ business is about margins, and in such a protected market they naturally fluctuate to providing a lot of inexpensive (inexperienced or mediocre) developers.
3. Customization of a mature solution (as mandated by “2″) is much more expensive than developing that many features from the scratch and “1″ ensures a lot of customization requirements. This alone is enough to make a project hugely expensive
4. A large and mediocre team makes proper use of advanced tools and methods highly unlikely. Some teams are good against all odds, it’s a pleasure to train them. Some managers have enough will to impose discipline that makes following guidelines possible. Training and mentoring those teams is hard, but then they do stay course. In many cases it neither.
5. Getting more people involved and more people accommodated have disproportional impact on costs. If you doubled the size of a meeting, the cost of meeting is doubled, the productivity is halved, so you need twice more meetings. Then everyone has less time to execute on the outcome of the meetings. So you need more people. Some of them will be invited to join the meetings…
6. After you eliminated challenges by eliminating chances of failure and by settling on quantity, the chances to keep the best people are low. Anyone with brains is fast-tracked to Lead Architect role.
7. By that time, management bandwidth is exhausted, so some decisions will go wrong way. Some activities gets created that have no customers, people producing specifications that nobody will read.

What is the solution to this calamity? Embrace limited risk to avoid massive and very expensive mediocrity that fails often. Treat innovative projects as “Lean Startups”.

I’ll cover that in details in the next post.