SaaS failures are 'betrayals of trust' [podcast]

Software as a service (SaaS) deployments have become an increasingly significant part of the enterprise environment. Given this growing importance, it's time to examine IT failure in the SaaS world.

To explore this subject, I spoke with Phil Wainewright, fellow ZDNet blogger and one of the industry's most respected SaaS analysts. Phil shed light on differences between SaaS and on-premises enterprise software deployments from an IT failures perspective.

In describing differences between on-premise and SaaS implementations, Phil emphasized the ongoing customer relationship inherent in SaaS:

Once the software has gone live is where it really all changes. In software as a service, customer experience becomes much more important. I once likened this to the difference between marriage and casual sex in a relationship.

Traditional software implementations are very much a case of get it in, take the money and run, and let the customer sort out the mess afterward. With a software as a service relationship, the customer starts paying when the software goes live.

There's a very important economic incentive for software providers to make sure the software is meeting the customer's needs, which therefore brings a much more intense focus on the customer experience.

Phil elaborated on the critical go-live juncture and beyond:

With on-premises software, once the implementation is complete, the job is done, the consultants and vendor move elsewhere, and the "get the software running" relationship becomes a maintenance relationship.

[Technology] has let us move from the traditional batch approach to IT projects into a more continuous process of evolution. Software as a service is particularly amenable to this.

Given the central importance of relationship in the SaaS world, failure appears to customers as a betrayal of trust:

Failures look more like a breakdown of trust than a breakdown of delivery. For example:

• Customers reaching the point where something they took for granted from the provider doesn't work as expected;
• Prices going up at a point where the customer no longer finds it easy to move from that application to another application;
• Features not being delivered as promised; or
• Poor application performance due to data center problems.

There are important economic, technological, and workflow differences between SaaS and conventional enterprise software deployments. It's therefore no surprise that project failures look quite different in the two environments.

In fairness, on-premise vendors would probably take exception to some of Phil's comments; I'll pursue the on-premise perspective in a future post.