In-Depth
Getting Application Development Back on Track with SaaS
Why traditional enterprise software is in disarray, and what technology can be of greatest assistance.
By Joe Ruck
It is no secret that traditional enterprise software is in disarray. Established vendors have had their revenues and market capitalizations slashed. CEO's are openly dismissive of large scale IT projects and spending. With a pre-built system requiring no implementation as such, SaaS projects have been some of the few to prosper in this environment.
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.
If vendors exist purely to sell, then IT departments sometimes act as though their purpose is purely to buy. 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.
Unfortunately, problems start as soon as the project is initiated. It is not unusual to discover that functional capabilities either do not exist or are unusable -- perhaps functionality added solely with the intent of being able to "check the box" with little practical consideration for its use. Then, the project inevitably takes longer than expected, as bugs in the software are uncovered. Some of these will be fixed by the vendor, others will simply have to be worked around, but all will add to the schedule. Finally, after the project is rolled out, many organizations discover that usage is much less than anticipated, and in extreme situations may lead to the application turning into shelf ware.
Taking 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. Many CRM implementations are, in fact, used only as simple shared contact databases, since that is what addresses the principal pain point of the user. More sophisticated functionality that in principle sounds attractive, can in practice simply be too complex to warrant the investment in training to master.
No rational team would start a CRM project unless its members believed they had some "secret sauce" that sets them apart from the herd. This is rather like saying "There is only one most beautiful baby in the world, and every mother has it." Although there are undoubtedly some exceptional implementations, the only consistent message from the market is that there is no "secret sauce."
In Figure 1 we illustrate the relationship between implemented and used functionality over time. Starting from the top left, vendors have no shortage of promises and a rapid flurry of new functionality announced with every press release. What actually gets implemented is always somewhat less than this for a couple of reasons. First, what is announced is often unavailable or what might be termed "checkbox" functionality, designed to look good on paper, but not expected to be used in anger.
Second, it always takes longer than expected to implement, due to the inevitable range of bugs. In some cases a fix may be found, but in most cases, it's more expeditious to simply work around the bug. However, both situations end up taking both time and resource to delay the implementation. Finally, what actually gets used is usually only a fraction of what is available.
Many of these problems stem from the myth of functional requirements -- that users can adequately articulate what they want or need in advance of actually seeing it. In practice they can't, and any project that depends on a significant amount of upfront analysis will be severely impacted as a result. Management has 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 both lack the imagination to see how things could be done differently. The only approach that consistently works is to show users a working system and then get direct feedback. Users simply don't know what they want until they see it.
Perhaps the most peculiar feature of enterprise software is the fact that this sad state of affairs has continued for so long. I imagine that few people want to admit to spending several million dollars on a failed project, so its not surprising that a project is rarely publicly declared a failure.
This is the enterprise software fiction -- the promise of business transformation, the reality of multiple project failures, and (until recently, at least) both vendors and customers participating in the fiction, with an ever-increasing amount of software ending up as shelf ware.
SaaS neatly side-steps this, as the model is built around a premise of "what you see is what you get." In the event this proves inadequate, then the subscription can be cancelled. There is no huge sunk cost to try and recover or cover up. Conversely, the fact that the SaaS vendor needs to sell his or her product every day means that good service becomes a differentiator and the vendor's success is well aligned with the project's success.
In our CRM example, Yankee Group have specifically cited SaaS as a success factor in implementation. My own previous experience of zero success with enterprise CRM in three separate companies and one success out of one attempt with SaaS CRM, is an experience shared by many.
SaaS isn't the perfect solution to every software project, but for many it is and SaaS remains the one type of IT project you can walk away from with your budget intact if it all goes wrong.
Joe Ruck is the CEO of BoardVantage. You can reach the author at jruck@boardvantage.com.