The Realities of SaaS Delivery

One of the major selling points of SaaS is ‘faster ROI‘. But do SaaS projects really offer faster project delivery timelines? 


Every project has the following steps: business requirements analysis, design, build, test and deploy. Yes, the steps can be mixed and matched and ‘agiled’, but for our purpose, let’s keep it simple.  Let’s take a look at each of these steps and see if a SaaS delivery is going to have a major impact on the project timescales.


Business requirements analysis usually takes the same amount of time, regardless of whether the solution is on-demand or on-premise. We need to define what business problem needs to be solved and break it down. In most part this is largely independent from technology.


However, the design phase is likely to be shorter on a SaaS project for one major reason; the ability to drive design through a solution prototype. Of course this is not a new concept, and it has been done with on-premise apps. However, on-premise solutions tend to face tougher challenges, environments are often not ready, configuration takes too long, etc. It is just a pain. So, what we have with SaaS is less time spent messing around with revisions of screen mock-ups and drawings; the concept is to dive in and show the client the application in action from day one. Prototypes give users a real idea of how the solution will look and feel.


The build phase is also significantly faster, where out of the box configuration is used to create the solution. SaaS environments tend to be more stable, and a lot of complexity is abstracted away resulting in rapid configuration which generally ‘works first time’. The prototype created during design can be leveraged as a ‘quick start’.  However, the magic disappears where custom development (coding) is concerned. This usually takes as long in the SaaS world as it does in on-premise.


Test runs of the solution functionality can take just as long in a SaaS solution as it would in an on-premise solution.  This is because there will be the same number of scenarios which need to be tested to cover user processes.  However, where an issue/error is uncovered, the time taken to make the correction is likely to be significantly lower, owing to the ease of change on SaaS applications.  Also, there is less ‘banging head against brick wall’ instances due to errors caused by  ‘server down’ issues or failing components, which tend to occur in a new and shaky on-premise infrastructure.


Deployment in SaaS tends to be far more straight-forward than on-premise, as most products do not require any form of installation, just access via a web browser.  SaaS really comes into its own where the application is to be delivered to users spread across multiple locations. Remember that in theory all a user needs to access a SaaS application is an internet connection and sufficient security credentials at their location.  There is no system infrastructure for the customer to support.


So all in all, SaaS implementations are usually delivered in shorter timescales than on-premise implementations.  Timescales can become extended where the solution becomes highly customised, but where possible these customisations should be kept to a minimum to allow for rapid delivery, as well as ease of maintenance down the line for the organisation.  Also, and this can be the big ‘gotcha’, data migration and integration timelines will not differ too much between SaaS and on-premise projects. The same old issues around cleansing/mapping/connecting occur, regardless, which tend to beef up timescales no end. But on balance, the time savings with SaaS make this a preferred option if comparing ‘apples with apples’ functionality wise. So what are you waiting for?

Calum Murray is Head of SaaS Practice at Capgemini UK