Hidden benefit of SaaS: Better investment psychology

A friend, who runs a software consultancy, and I were talking about Salesforce.com, its new Platform as a Service (PaaS) called Force.com and its Development as a Service (DaaS) environment called Apex.

I just came back from a "Tour de Force" seminar, and I must admit that I was slurping down the Kool-Aid. Salesforce has done a masterful job of implementing their CRM platform that can configured by anyone and programmed easily. I think of their concept as a 4GL for cloud computing. I know -- 4GL dates me. But there's not much new under the sun...

Anyway, my friend asked me why I thought Salesforce.com was more successful than Siebel, the dominant CRM platform for years that is sold primarily as licensed software. He described several Siebel implementations that were train wrecks, and he was curious as to whether I thought Salesforce.com would run into the same fate. After all, both are CRM platforms, and their designs (at least at the software object level) are not all that different. Yet, we have not heard of the same kinds of disastrous projects implemented using Salesforce.com.

After talking about it for a while, we stumbled upon an explanation for why there may be a disparity between Salesforce and Siebel -- a difference that has resulted in Salesforce's increasing success in the market.

The difference, I think, lies in what drives the cost of CRM initiatives, and the expectations that surround them.

To illustrate, let's consider two projects, each costing $10M over 3 years, with the following characteristics:

Project A

• Development life cycle: 18 months
• Time in use: 12 months
• Cost breakdown: $2.5M software license / maintenance; $5.0M customization and integration; $2.5M project management, requirements definition, etc.
• Number of users: 20,000

Project B

• Development life cycle: 6 months
• Time in use: 24 months
• Cost breakdown: $130/user/year; $0.250M customization and integration; $0.100 project management, requirements definition, etc.
• Number of users: Ramps up to 35,000 in year 3

Project A is a big project team working for a long time: at $150K/person-year, that brings the project in at about 50 person-years, about 15 person-years defining the system and managing the project, and another 35 person-years building and deploying it. That's a lot of time for a team to have on its hands. What kinds of expectations does one think there would be with that amount of resources? The temptation to add scope and complexity beyond the out-of-the-box solution is almost palpable. Sure the system can handle 20K users, but the real investment is in getting all the features the business can digest. Furthermore, the capital appropriation of $10M over 3 years means that we've paid for an asset, and most managers will expect that asset to have what they need from it -- again, irresistable urge for complexity.

Customizations and complexity increase project risk, however, so the failure rates of projects like Project A likely increase with the customizations and complexity -- driven by investor expectations of "value."

Project B, on the other hand, suggests about 2-3 person-years to make the project work. There are, then, much lower expectations regarding customizations and support for complexity beyond what the out-of-the-box package provides. Furthermore, the costs scale with the number of users, so the perception of value is per user. At $150 per user, there is not the same pressure or set of expectations as to what the software has to accomplish to deliver value to the organization. (In fact, more money is probably spent, per user, on training and effective use of the software than on the development and licensing / rental of the technology).

With lower customizations and complexity, the project risk for Project B would be substantially lower than for Project A that costs the same amount over 3 years. And, Project A folks, don't fool yourselves that the costs of Project A go down after year 3. If Project A succeeds, the next major version (including all those features that never made it into the solution) is just around the corner.

It would be nice to actually look at some data as to Siebel vs. Salesforce project success rates, but my friend's on-the-ground perspective seems to bear our this difference in outcomes. It is fascinating to me how the psychology of technology investing has so much to do with determining project success.

In any event, it seems that SaaS / PaaS / DaaS may have a hidden benefit to the sponsor of the initiative: by aligning investment cost with users, it may reduce the need for initiative sponsors to seek their returns in the investment in an asset (which investment, through complexity, increases risk).