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.