Analysis

The benefits of on-demand software

Bob Tarzey By: Bob Tarzey, Service Director, Quocirca
Published: 8th December 2006
Copyright Quocirca © 2006
 Logo for Quocirca

In a study last year Quocirca looked at the degree to which organisations were wasting time and effort on badly planned, procured and implemented on-premise (as opposed to on-demand) business applications. One particular area looked into was the prevalence of shelf-ware; that is software that is purchased but never used.

As it transpired, the problem did not seem to be too bad. Of the 200 UK enterprises covered by the survey, none said that shelf-ware was a worrying problem and the majority said they had none or very little of it. Taken alone this could be a pointer to efficient spending on packaged business applications, although it should be considered that buying shelf-ware is not something some organisations would want to admit to.

When it comes to procurement it may well be the case; it would seem that these days purchasing departments have got wise to the wily ways of some software vendors and are better predicting the number of licences that will be required for a given deployment and not over-purchasing. But if, on the surface at least, the procurement teams are now getting it right the deployment teams still have plenty of room for improvement.

Only 20% of the respondents claimed never to have started a project which failed to deliver or was abandoned. For well over a third of respondents the failure rate ran at over 10% of all projects or higher. Having asked respondents about packaged applications in general the survey went on to look at a single recent successful implementation their organisation had carried out.

About 50% chose to report on a CRM implementation, others selecting ERP, supply chain and financial applications in about equal measure. Given that these were supposed to have been successful deployments an awful lot of them were not sure the whole effort had been worthwhile, especially when it came to CRM, where over 65% agreed they deployment was “better than we had before, but not sure the cost time and effort were worth it”.

Reasons for this were varied but one overwhelming reason came through; the more money being spent the more likely it was that the result would be disappointing. Of those who were disappointed 40% were in the £2M+ budget category, as opposed to just 15% for the satisfied category. That adds up to a staggering amount being spent on business application deployments that were not considered worth the effort.

Lower cost projects are likely to succeed because they are smaller and it is easier to stay in touch with the stakeholders and change direction when required. Bigger projects take longer to implement so there is more time for the project deliverables to drift from the business requirements, which will be changing at the same time.

But there is another reason: procurement teams may be able to pride themselves on not over-purchasing software but the very fact that software is all procured upfront can lead to failure. The way many software vendors prefer to work is to get big upfront payments in return for big discounts. Bigger projects lead to more desperation for the software vendor to win and therefore bigger upfront discounts. The problem with this is that the software vendor is not financially linked in to the on-going success of the software project.

Last month in this column Quocirca reported that the on-demand model for purchasing software was not always the cheapest. But one benefit it undoubtedly has is that the on-demand vendor is tied into the success of the deployment for as long as the subscription is maintained.

A disappointing or failed on-premise deployment can see millions wasted, whereas a failed on-demand deployment could see as little as a few months subscription lost. And, to be on the safe side, with on-demand shelf-ware is simply not possible.

Reader Comments

Sorry, we are no longer accepting comments on this item. We suggest trying to contact the author directly.

8th December 2006: 'Dale Vile' said:

I think there is a danger of confusing things here.

Larger packaged application implementations – the big 2m plus projects you refer to – are invariably implemented by a third party, typically one of the big SI’s or consulting houses. While it is helpful to have the support of the software vendor, it doesn’t actually have that much impact on the outcome of a project being implemented by one of the big professional services firms, who very much like to stay in charge. The upshot is that it is very unlikely that up front licencing/discount discussions would have a significant bearing on success or failure.

Related to this, when you get to this level of large project, all of the time, expense and risk is associated with the implementation piece – configuration, integration/interfacing, customisation, and so on. Even if you subscribed to the underlying software on a price per month per user SaaS basis, this would not change (neither would the requirements to use third party implementation houses), so there is no inherent reason why the choice of SaaS or traditional licencing would have an effect on success or failure, in fact it is arguable that the SaaS approach introduces some additional complications and risks as integration needs to take place across different jurisdictions. Yes, if the project crashes and burns completely to the point where it is actually abandoned, you are stuck with some licences that you can no longer use, but that happens so rarely, and if it does, the money wasted on licences is probably the least of your worries.

While there are some interesting observations here, I am not sure it adds much to the discussion about the rationale for SaaS, particularly in the higher end of the market.

What would be really interesting, would be to investigate success/failure, abandonment rates, etc with larger scale SaaS adoption. The research you have referenced here is pretty long in the tooth now and a lot has happened in the interim in the SaaS camp, e.g. salesforce.com trying to play on the big boys’ turf – Oracle/Siebel, SAP, etc. I don’t personally have a feel for how well the SaaS players are doing here, but I guess today, there would be more experience out there compared to two years ago.

Meanwhile, I remain am a huge fan of SaaS, especially for commodity/utility stuff and for smaller projects where the time and expense of sorting out and managing the physical bits are disproportionately high compared to larger more complex application environments. I just think we need to be careful about over positioning its benefits at the higher end.

In any event, we are still not picking up huge demand for SaaS, though my feeling is that it will come, but that’s another discussion.

Reply to Dale Vile?

8th December 2006: 'Mark Sheldon' said:

There is also a subtle difference between outright failure where the system literally dosn't work and failure to produce Return On Investment. An American study quoted in the HBR suggested that over 50% of IT projects fail to produce ROI i.e. they cause a financial loss in the business.

On demand services present new opportunities and threats for capital expenditure.

Reply to Mark Sheldon?

8th December 2006: 'Dale Vile' said:

Absolutely right Mark, the statistics are generally bad, but while there is a lot of room for improvement in many IT shops, getting every project to 100% of planned contribution is unrealistic, so the trick is to think at the next level up.

A group of us have been researching for a book and have interviewed quite a few CIOs on exactly this issue from around the world. Best practice seems to be to take a portfolio-driven approach to managing IT investments, a kind of extended version of the portfolio managagement ideas advocated by vendors with that label (who are moving in the right direction, but are not quite there yet).

Reply to Dale Vile?

The messages above were all contributed by IT-Director.com readers. Whilst we take care to remove any posts deemed inappropriate, we can take no responsibility for these comments. If you would like a comment removed please contact our editorial team.