SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Why is R&D so Slow for Conventional Enterprise Vendors?

Posted by Bob Warfield on June 24, 2008

Eventually the Enterprise Irregular discussion I posted about earlier wound its way around to asking, “Why must this development be so slow for conventional enterprise vendors?”

One Irregular opined as how it was due to wasteful R&D. That waste being due to:

– Too much emphasis on derivative products

– Continuing old assumptions/processes even though newer technologies exist

– Continuing to re-invent the (stone) wheel instead of challenging all of the old assumptions.

– Doing development only at the margins. Adding a tenth method of allocating a general ledger balance will not re-order the competitive landscape for anyone.

– Thinking that R&D spending should be tied to market size, market share or some other proxy that is irrelevant. The effort should be one that is relevant to the effort being planned and must be one that shareholders will get value from.

These are all classical problems for large company product development that I quite agree with. Just to amplify on a couple of the points:

I recently took a new position but interviewed with many firms that were firmly stuck some ways back in the technology world. These included extremely large organizations for whom C++ was a relatively new and not yet often used tool. Needless to say, most of the problems there are self-inflicted, and given the proclivities and mass, are so institutionalized as to have ossified into a nearly impenetrable mass.

Reinventing the same wheel is extremely common. Even among SaaS companies, most are focused on doing the same thing their client server predecessors had done only via SaaS. Relatively few have innovated very much on that theme.

Doing development at the margins is a common outcome once the visionaries have been separated from the project (if there ever were any). Momentum and sales coupled with a lack of imagination compells these organizations to continually poll customers for ideas (or simply copy the competition), and grind them out until applications sport a porcupine’s coat of random disparately connected features.

But there are some other key issues as well that are particularly insidious for the non-SaaS world.

Consider the issues of supporting multiple platforms and versions of the software. I’ve chatted on several occassions with peers of mine who’ve done duty for both SaaS and conventional product development organizations. We’ve tried to estimate what the cost of supporting multiple platforms and versions is for the typical Enterprise Software R&D budget. The results are surprising. I routinely hear 30-40% of cycles are expended in these areas.

Imagine boiling off 40% of your available cycles for innovation just supporting old releases and doing platform work. SaaS companies do neither.

First, there are not multiple platforms for SaaS. It all runs in the SaaS company’s data center on their preferred platform. No ports, no additional testing, no maintenance, no architectural workarounds for deficiencies in one platform or another. In addition, SaaS companies can focus their talent and experience base around one platform, so resources become more fungible and a larger community of experts can be built.

Second, customers run the latest release as soon as it becomes available. I’ve polled Technical Support professionals in the past and gotten them to reach into their trouble ticket databases to answer a key question:

How many trouble tickets involve problems that would have been fixed if the customer ran the latest release?

The numbers I got back ranged from a low of 40% to a high of 70%. That represents a huge number of fire drills, hot patches, and customer satisfaction angst that just simply does not occur for SaaS companies.

Is it any wonder they’re more nimble?

Last point is the release cycle time. Many large members of the Old School are used to release cycles of a year or more. This is simply not very agile. What are the chances the assumptions that drove a particular release cycle are still just as valid in the year it takes to release as they were when the cycle was begun? Are they still valid 18 months later? Some vendors take two or more years for a major release. At what point are you building software that just won’t matter to the market when you do finally release it? And how much of that sloth has to do with customer reluctance to accept the new release anyway?

SaaS companies take care of the burden for customers, speed their own development cycles to more like one or two quarters, and wind up with happier customers in general.

4 Responses to “Why is R&D so Slow for Conventional Enterprise Vendors?”

  1. […] to value and how software evolves. Bob Warfield takes the bleak view that: Reinventing the same wheel is extremely common. Even among SaaS companies, most are focused on […]

  2. […] Warfield has a really interesting post that details some of the same challenges I listed (which just about anyone who’s been in […]

  3. I was called in because a mid-tier supply chain company made the big switch to SAP SCN. They were having problems making it work with smaller partners. I was bidding to de-funk it by decommissioning the SAP solutions and replace with an amalgam of SAAS services and lightweight SOA / REST stuff glued together for a set of simple to use commerce hub functions.

    Every presentation had the SAP vendor in the room with another 20 or so hangers on that had nothing to do with the implementation.

    I had already submitted my draft quote, so I but my lip and said, “you guys are never going to get anything done with this many people having to sign off on every change – you need to tighten up”.

    THe SAP vendor said, “we need to keep all ‘stakeholders” in the loop.”

    Me: “You cant even get your own solution working for the 500k?”

  4. smoothspan said

    Alan, welcome!

    The truth of Enterprise software is it’s very hard to try before you buy. The experience of having everyone involved in the decision right down to the competing vendor is reflective that all the customer has to hang on to are the relationships. In this case, evidently had convinced them they could help safely navigate this hazardous journey. The customer wanted to be led and nobody wanted to take ownership because of too much percieved risk.

    Optimal business strategy? Definitely not!

    Common scenario? Absolutely!

    The best SaaS solutions make it so easy that the customer feels it is simpler just to get going with it and back out later if things don’t work.



%d bloggers like this: