In the energetic debate on SaaS and cloud computing, the spotlight often hovers on the technology itself versus the real benefits it brings, which sometimes becomes a distraction.
I agree with Phil Wainwright in his blog “Cloud Computing, so much more than multi-tenancy”.
I’m big believer that multi-tenancy is vitally important to the three key benefits that most people recognize for SaaS and cloud – improved speed of delivery, increased flexibility/agility to respond to changing needs and lower TCO.
However, the multi-tenant platform is just an enabler. How a company uses SaaS makes a material difference in the prize they ultimately earn.
Speed is the first thing that I hear business leaders jump on with SaaS. Is faster always better? Well, most of the time the answer is absolutely “yes”!
The ability to get started and to iterate in production is extremely attractive and indeed, in some cases essential depending upon the stability of the business processes in question. SaaS provides a unique ability to course-correct to drive higher user adoption and ultimately affect real behavioural change.
However, faster doesn’t always make sense at any cost. Several SaaS implementations have become unstuck when they launched without a sufficient user value proposition.
Users getting ‘turned off’ are obviously much harder to win back. The degree of success with SaaS depends a lot on the culture of an organization. The level of speed and agility of SaaS often correlates to how well different teams work together during a project.
The issue was brought home to me recently when talking to an IT leader as he reflected on his prior traditional on-premise implementation experience from over a year ago. He described a situation where deep frustration existed both within the Business and IT organisations.
The IT group having been burned by delays caused by ‘scope creep,’ was frustrated by the business audience who were constantly changing requirements.
The Business, on the other hand, was perplexed that the so-called changes couldn’t be accommodated given that they operate in the ‘real word’ where nothing stands still. Worse still is that when IT delivered the project, the Business was baffled that it wasn’t exactly what they wanted and they questioned how the time and money was spent.
When digging into the details, several ‘customizations’ were found to have sucked up much of the capacity of the IT delivery team. When the Business asked why that had happened, the IT group pointed to critical requirements that the Business had laid out.
The Business countered “well, if you’d have told me the implications to the capacity, then we would have adjusted our need.” It sounded ugly.
In contrast (thankfully), the IT leader shared a very different scenario with the current SaaS program that he has been sponsoring for the last 12 months. The stark difference is the new level of collaboration between the Business and IT groups.
When asked how SaaS facilitated the shift, he talked passionately about the increased transparency in the SaaS systems development lifecycle to aid Business and IT decision-making. In what he described as ‘Conference Room Pilot sessions on Steroids’ throughout Design, Build and Test, there was a constant visibility to how the delivery capacity for the project was being used—enabled through SaaS.
The ‘real-time’ turnaround to understand the implications of business decisions on the delivery capacity was game-changing.
The Business felt much more control and ownership for their decisions – truly honing in on what they were agreeing for the solution. Also, as changes came up, it was a highly constructive discussion on the cost-benefit of using the capacity to accommodate changes in a more agile mode with SaaS.
Sure, I can plug Accenture for bringing the tools, processes, people, etc. but the profound change is the appetite of the Business and IT groups to work differently to exploit the new approach.
The client described the results as stunning—projects delivered on and ahead of time, on-budget and exceeding business expectations by accommodating market-critical changes and delivering on the promised business case.
Is this kind of approach truly unique for SaaS? Could the approach have been equally applicable to an on-premise implementation?
My view is that while several of these techniques can and have been applied to on-premise projects, the threshold for fast-turnaround for design/build implications is much greater for SaaS; for a critical mass of design/build work, the longer on-premise turnaround time makes the implications for delivery capacity more opaque and the Business/IT collaboration suffers as a result.
As odd as it sounds, a more “cloudy” approach to systems development may address this opaque issue and bring clarity to deeper collaboration—the real prize.