Project failure risk - cloud vs on-premise

This is a big topic, and sadly there aren't enough case studies comparing traditional versus SaaS implementation in a like for like way.  We come at this from a background of over 30 years of implementing different kinds of manufacturing, ERP and finance systems in many different sizes of company.  We moved from traditional software and started implementing SaaS solutions when we set up D2C in 2004, so we've now had over 5 years of experience implementing different SaaS and Cloud applications (and by the way, the old rules of project management and project success still apply).

One of the significant factors that provide better total cost of ownership for  SaaS solutions compared to traditional on-premise solutions is the cost and time of implementation.  SaaS solutions are characterised by their ease of implementation and quicker time to market or value with deployments (depending on the application) generally requiring up to three months compared to six to 18 months with traditional software.  Customers do not have to spend time and money  installing or maintaining servers, networking equipment, security products, or other hardware.  SaaS providers generally offer a free trial period , but in any case the pay as you go pricing lends itself to a small pilot with a few users that can start almost immediately to prove the system.  You might do a pilot with traditional software, but it will be much bigger than 1 or 2 users, and cost more in terms of time and set up costs.  The SaaS approach changes the focus of the overall deployment to end-user training and acceptance.  Once the trial proves a success the implementation becomes a roll-out to more and more users.  Based on our experience so far, depending on the complexity of the applications involved, the implementation consultancy for a SaaS solution can be anything from 50% to 10% of the consulting expected for a traditional software implementation.   In my experience, the smaller the project in terms of time, the more easy to control and get success rather than failure.

Later today I'll see if I can find some source material, case studies and anything on SaaS project failures.
David Terrar
www.d2c.org.uk and www.twinfield.co.uk 
 

Are we comparing like with like and by this I mean the difference reasons for implementing a project

There are probably two distinct markets

• projects initiated in a similar manner to most of the current crop of SaaS providers; developed & written by themselves with the end result of having a product which is saleable to many users
• projects initiated by companies for 'internal' consumption

So on the one hand Cloud systems are being written for sale and on the other for own use

(we are not talking about implementing exisiting solutions on new client premises - but writing new systems from scratch)

This difference makes an enormous impact on how the projects are approached and the realtionship with the developer. Furthermore, as David says, the latter (3rd party developing) is probably still in its infancy and case studies will therefore be in short supply.

Also very specific requirements are associated with 3rd Party developing

• Why is the 3rd party choosing the SaaS route (in vogue, access anywhere ...)
• Why are their own networks inadequate for the solution
• Why are VPN, Citrix, T/s etc not suitable

So perhaps the real issue they need to address at the outset, is to determine their ultimate goals before even choosing a hosted option.

One suspects that in a great many cases a Cloud development project for a 3rd party may not be the correct approach

@JC - I think you are taking us in a whole new direction.  I thought Chris was after comparing risk/reward of SaaS projects with an equivalent on-premise implementation.  Salesforce CRM vs Siebel (or Sage CRM or Goldmine), or maybe NetSuite vs SAP B1 (or Epicor or Aggresso), e-conomic vs CODA (or COA, or Sun Accounts)... that kind of thing.   

David Terrar
www.d2c.org.uk and www.twinfield.co.uk