SmoothSpan Blog

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.