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

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I have been involved with building SAAS applications for nearly a decade and really enjoyed your post. Too few people take into account a key aspect, which you point out here:

"Business requirements analysis usually takes the same amount of time,..."

Too many people think that SAAS eliminates this need and completely underestimate what they are getting into.


Excellent write-up. I just wanted to add to your discussion on the design phase and custom coding.

In my experience, SaaS is best suited for companies that are looking for a standardized software package. As an example, take accounting software. Accounting follows a certain set of standards. When going through the motions of an accounting process on paper, most companies will follow a relatively standard business flow that translates into design requirements for software. Hence, the out of the box configuration generally works without further customization. There are many other examples, but going into them is beyond the scope of this article.

Customization is the tricky part. As soon as a single line of customization code is introduced, I think it complicates things quite significantly. As you already mentioned, customization requires a design phase that adds to the costs. But more importantly, once customized code is introduced into a companies SaaS implementation, maintenance becomes an issue. You no longer have a single code-base in which patches and updates are applied to. Each customized implementation will need to go through an additional testing phase on a "per customer" basis. Multiply that by the 1000s and you can see where I'm going with this.

I am a firm believer that SaaS will eventually dominate the software industry. But kinks like this will need to be solved through creative solutions.

Vincent Ray

Service Management Link

MHelpdesk, Service Management Software

John, thanks for your post and apologies for the delay in my reply, although we only became aware of your comments yesterday.

However, to your point, I think the “underestimation” is a result of the fact that to date many SaaS projects have been sold under the radar of the IT Department and CIO, directly to departmental heads. Of course this has occurred because often the business has become increasingly frustrated with the apparent lack of progress and seemingly inexorable delays with the delivery of past IT projects and so they have done their own thing.

Of course many of these department heads are business focused, they need a solution and they need it quick and most will have never encountered a structured IT delivery methodology, which despite its flaws also ensures some key principles are adhered to, namely a clear and agreed set of business requirements.

I only wish more of your contemporaries in the SaaS market followed our view, too often we still hear off highly respected SaaS companies effectively espousing a JFDI approach which in our view simply stores up problems for later – particularly when they want to integrate or migrate the solution to a different platform


Many thanks for your comments and apologies for not responding sooner, rather exciting week at Cloudforce.

As you have correctly stated, customisations do add a level of complexity to customer solutions. It is though worth noting that there are already a number of innovative solutions in use today, which help alleviate the “customisation maintenance overhead”. Take for example, they guarantee that your customisations will continue to work after they have upgraded your application(s) to the latest platform version, as long as you follow some key rules.

In particular, when you develop customisations using APEX code, you must also write test cases which touch at least 75% of the developed code. Without this test case coverage, the customised code cannot be deployed to the live environment.

By applying this seemingly odd rule, when do upgrade their platform they run these same test cases against the new platform version, and as a result Salesforce will not perform the platform upgrade until every test case for every customer passes. This means that, as a customer, assuming you have provided test cases which passed at the time you developed your code, ensures that these test cases pass on all future patches and upgrades. Essentially, the maintenance headache has been shifted from the customer and placed squarely at the feet of the SaaS provider so actually alleviating the headache of system upgrades, yet another advantage of SaaS! That said good practice (and one which I would endorse) would be that clients should complete at least some regression testing, if nothing else to satisfy themselves that the “code” works with the new functionality as expected. So when selecting a SaaS solution ensures you include a Sandpit environment in your service, but that’s the subject of a whole new blog entry…..

Anyway, the above is one example of how SaaS providers protect your investment and admittedly while not every SaaS provider will have this custom development structure in place, this will be just a matter of time. With the speed and agility that the SaaS world moves in, we could be seeing this on a larger scale sooner rather than later.

Hope this helps and thanks again for your response.