Will SaaS Save Enterprise Software?

Untitled Document It is no revelation that the traditional enterprise software business has changed significantly over the last several years. Established vendors have had their revenues and market capitalizations slashed. And we have witnessed a wave of acquisitions -- with industry giants gobbling up very large rivals, including the hostile take-over of PeopleSoft and Siebel by Oracle and the friendlier buy-outs of Cognos and Business Objects by IBM and SAP respectively.

Many remaining independent players have seen their stock prices stagnate. In the startup scene, most VCs avoid the on-premise software model and are throwing their weight behind Software-as-a-Service (SaaS). Although every industry has its ups and downs, the time has come for customers to ask if enterprise software will still give them the good return on investment they have come to count on.

Take CRM as an example. Gartner reports that 55 percent of projects fail to meet expectations and Butler Group reported a whopping 70 percent of projects failed. With those industry statistics well understood, no rational person should even start a CRM project unless they believe they have some "secret sauce" that sets them apart from the herd. While there are undoubtedly some exceptional implementations, the only consistent message from the market is that there is no "secret sauce."

IT departments sometimes act like their primary function is buying. Status and salary are functions of headcount and budget, and the more work there is to do, the more headcount and budget follow. This leads to a desire to undertake big projects and vendors are more than happy to push bigger and more complex boxes of Legos to drive this addiction.

Having been involved in countless implementations, I have found that on typical projects, problems arise the moment implementation starts. It is not unusual to discover that presumed capabilities are unusable -- perhaps it was functionality which was added solely for the purpose of being able to "check the box." Two or three of those are enough to badly throw a project off-track. And, often after roll-out is complete, many organizations discover that the actual user experience is so different than expected that usage itself is much less than anticipated, or that the system goes entirely unused. It is factors like these that lead to project failure rates of 50 percent or more.

Who to blame for this mess?

Most commentators have taken the view that this is primarily a failure of IT project management. There is a belief that just one more round of weekly progress meetings, hiring a big-shot project manager, outsourcing, or some consultant's new-fangled methodology will fix the problem. Personally, I believe the heart of the issue lies not purely within IT, but with the vendor and their sometimes unhealthy relationship with IT.

Clearly the vendor makes an inviting target, but most vendors work hard to gather requirements, only to be disappointed that the feature set they built on the basis of customer input does not meet the industry demands.

There are certain unspoken assumptions around requirement gathering -- that end users will adequately articulate what they want or need in advance of actually seeing it. Experience shows that in fact they struggle to do so and in many cases plainly can't. Users simply don't know what they want until they see it.

Also, management tends to have a rosy but inaccurate view of their business processes, because employees are reluctant to explain the ugly workarounds that are in fact central to the process, and collectively they lack the imagination to see how things could be done differently. This means that projects that depend on any significant amount of upfront analysis have a high likelihood of failing. The only way to avoid that is to take a radically different approach, which is to show the end users a working system and then tune that system on the basis of the customer feedback.

Perhaps the most curious aspect of enterprise software is that this state of affairs has continued for so many years. Maybe it has to do with the fact that few people want to admit to spending six or seven figures on a failed project, so not surprisingly, few projects are ever publicly declared as failures. Failures may be blamed on individual vendors or individual team members, but rarely is the basic premise or the fundamental approach questioned.

Perhaps in a time of greater humility, where the fundamental wisdom and sustainability of countless institutional practices have come under scrutiny, we can now ask a similar set of fundamental questions about long-held practices in the software business -- many of them grossly wasteful as the statistics above indicate, but which somehow have managed to survive for years. How does enterprise software reconcile the promise of business transformation with the reality of multiple project failures? And, why do we accept with both vendors and customers participating in the fiction, an every increasing amount of software ending up as "shelfware?"

With SaaS this problem goes away entirely because the old principle of "what you see is what you get" is directly applicable so that functionality can be immediately verified. And if somehow the service doesn't live up to its billing, the subscription can be readily cancelled. There is no huge sunk cost to try and recover. Conversely, the fact that the SaaS vendor needs to sell his or her product every day to the user means that service now becomes a differentiator. The beauty behind the SaaS model is that the vendor's success is well-aligned with the project success -- there can be no "shelfware."

SaaS isn't the perfect solution to every software project, but for many it is the one type of IT project you can walk away from with your budget intact if it doesn't go as planned.

About the Author

Joe Ruck is president and CEO of BoardVantage. He has led many high-technology companies through successful growth to IPO or acquisition. Prior to joining BoardVantage, Ruck was senior vice president of marketing at Interwoven and part of the team that drove the company through one of the most successful IPOs of 1999. Previously, he held sales, marketing, and executive positions at Sun Microsystems, Network Appliance, and Genesys Telecommunications, subsequently acquired by Alcatel. Ruck holds a BS in engineering from Oregon State University and an MBA from Santa Clara University.

More by Joe Ruck