An MD’s guide to successfully deploying a ‘Software as a Service’ project by Roger Marks, Managing Director, Aeromark
Table of contents
SaaS – just another buzz word?
- Certainly not. Deploying a Software-as-a-Service (SaaS) solution greatly reduces capital expenditure and has the potential to slash overall systems costs over its lifetime, which is why it is so attractive to so many businesses. It effectively allows organisations to pay for the use of an online system, rather than having to buy additional hardware, software licenses and other infrastructure components. That’s not to say they simply buy a subscription to a website and log on when they like, it’s slightly more complicated than that.
- The IT industry seems to have acknowledged that ‘cloud-based’ computing, and in particular Software-as-a-Service (SaaS), is the future for many enterprise applications. The implementation of these new business systems and their associated projects may, however, represent uncharted water for most IT and project managers.
What is SaaS?
- This has led to some confusion about what actually constitutes SaaS. Some enterprise system vendors have simply made their traditional software available through a web browser and offered a hosted server environment to run the system. Such back engineering is not delivering true SaaS and people should not be misled.
- On the contrary, SaaS is not a minor relocation and tweak of legacy software. It is a complete transformation in the way applications are developed, funded, sold, implemented, trained, supported and upgraded. Because the mindset is so different, it is often extremely difficult for a traditional enterprise vendor to successfully change to this model. By way of a simple illustration, you could consider the change as being similar to the transformation from 35mm to digital cameras.
A huge leap forward
- Traditional server-based systems have historically involved a large upfront investment to purchase things like: software; server hardware; additional infrastructure for business continuity and disaster recovery; a detailed business requirements specification against which the system was delivered; and following deployment, a support contract and costs for change at high professional services rates.
- The principle behind SaaS is significantly different to this model. The effectiveness of the system depends on multi-tenant architecture where all customers (usually) share the same application. This enables easy horizontal scalability, and therefore computing resources to be optimised and shared.
- By designing a system in this way the customer should benefit from: much faster delivery; more stable applications; better support; increased agility, significantly lower initial investment on hardware or infrastructure; automatic updates when new features become available; lower cost of change and overall ownership over a five year period (as SaaS is normally charged on a per user per month basis).
We’ve had a system in for years that does the job, why would we go through the pain of change?
- Most senior managers will be aware of the well publicised and catastrophic failures of large IT projects, particularly in the public sector. They will almost certainly be less aware of the failures that occur every day within smaller commercial organisations – maybe even their own. This is primarily due to the spin used by project managers responsible for the procurement and installation of these projects, as well as other stakeholders, who often position a weak outcome as a success.
- Enterprise systems are, however, at the heart of almost every business and especially those that employ a mobile workforce. The damage that an inadequate system can have on the profitability of a business is almost always under-estimated and conversely, the potential improvement to the bottom line that a good fitting system can bring is enormous.
- An ill-fitting system results in compound inefficiencies, increased staffing levels to cover these inefficiencies and increased cost of failure. It is therefore imperative that these systems are identified and acknowledged at the earliest possible opportunity.
- There are many cases where companies have invested more than £1m in a server-based enterprise system, only to spend subsequent years unsuccessfully attempting to make it work properly. Despite knowing that the system was a bad fit, in these cases there was always a reluctance to accept the fact it was not fit for purpose, based on the investment made and the internal political requirement for it to be seen to succeed. It is painfully clear that persisting with such fundamentally ill-fitting systems serves only to increase the damage being done to a business that can’t see or admit that it has made a poor decision.
- The many surveys of traditional IT/development project failures cite unrealistic delivery timescales and expectations, combined with gross underestimations of the task as the largest causes of project failure. It therefore makes sense that SaaS systems, by design: reduce the implementation time and complexity; bring dividends and reduce this risk accordingly.
The real difference with SaaS is the ability to change
- Expanding on the digital camera analogy above; with a 35mm camera/traditional IT procurement you decide what you want, point, and once you press the button that’s what you’re stuck with. With a digital camera/SaaS you can take, examine, retake and adjust until what you have in front of you meets your exact requirements.
- Likewise, with a good SaaS service provider it should be less important to draft lengthy and detailed requirement specifications, because the ability to change and alter aspects during and after the implementation project allows the finer detail to be defined as an ongoing process. This will make the difference between a system that fits and one that doesn’t. It also makes selecting the most suitable supplier of the utmost importance.
- Most company requirements mean that a SaaS service provider should be able to deliver 80% of the final solution off-the-shelf, and develop the remaining 20% to make the new system a perfect fit. Unless the business requirement is unique, the 20% development that is required should be viewed as a product enhancement by the provider, as they will be able to offer it to other customers in the future. As such, if the enhancement is generic the buyer should not expect to pay for this development. Likewise, you should expect to benefit from other customers’ improvements in the future. A true win-win.
What to look for in a supplier
- Data stored in a third party cloud is at risk from security breaches. Many software suppliers are reliant on third party data centres which are certified to ISO27001:2013 ( Information Security ). On the face of it this might seem reassuring, but it also can potentially obscure the majority of significant risk, as the application level security is not being covered by the data centre at all. Therefore, to ensure that your company data is protected it is vital that you choose a supplier that is certified to ISO27001 covering their entire business scope; from staff hiring to development of the software and not just their third party data centre. It’s important that the certification is UKAS accredited and it’s worth checking out the scope on their certificate.
- It’s also a really good idea to find a supplier that is certified to ISO22301 ( Business Continuity ) as this ensures that systems will be available in case of a disaster.
- The effectiveness of the process can be greatly reduced, or even eliminated entirely, if the service provider uses third parties to deliver any of the core components: such as PDA software, vehicle tracking, scheduling and the like. Integrated multiple-supplier technologies always significantly increase the potential for failure, so a single supplier that will deliver all aspects of a system will act to mitigate that risk.
- It is also vitally important that the supplier is financially stable with an established reputation. After all, its application will be running your business. Perversely, if the organisation you choose is too large, you risk inflexibility, longer timescales and possibly loss of ability to actually make the 20% changes that are required.
The Best Approach
- Most projects are initiated with some key business requirements or major issues to solve. The task of solving these issues is allocated and the process of designing the solution to the problems begins. The new system requirements are built and a wish list of features created. This is normally the first fundamental mistake. Every decision about how best to achieve the objectives have been made without reference to the expertise that’s freely available.
- The best approach is to present your key business requirements to a number of service providers and let them propose the best way of delivering the results using their systems. Have an open mind. This advice should be free and will be based on a previous track record of achieving similar objectives.
- Chose the one that can demonstrate the track record and feels like the right long-term partner.
Project management is king
- Like the traditional model, no matter how big or small the company, the role of the project manager (PM) is pivotal. For an effective project there must be a PM allocated by both the customer and the supplier that is empowered to demand any internal resources required to deliver on-time and on-budget. For most deployments the position of PM should be a full-time role, and have a direct reporting line to the board if possible. The hands-on type, who is prepared to get into the detail, is always best.
- There are two things a PM needs to have a firm idea of from the start: timescales and functionality. With respect to timescales, as a guideline, if you have specified delivery in less than six months under pressure to get the deal done, even if the supplier has agreed to your demands, then you should stop and think again. Setting these timescale expectations will be the project killer. All projects are, of course, different, but for most SaaS enterprise wide projects somewhere between six and nine months is the industry standard timescale.
- In terms of functionality, the biggest and most common mistake is for one member of the management team to start a list of requirements, circulate it to other managers (that inevitably make minor additions that will affect their area), hold a meeting to agree that they have the required functionality agreed, and then pass this list to the procurement department to buy an appropriate system at the lowest possible cost. Sound familiar? Neither the new systems’ end users nor potential suppliers have been involved anywhere in this process, and as such the PM will be pulled from pillar to post, and the project will be very difficult indeed.
The Golden Rules of Successful SaaS Deployment
- In order to reduce risk you should review your systems fit annually with your technology partner. Your business will change over time and your systems should reflect that change. If change is necessary, your first action should be to get your senior management team to draft a non-detailed list of high level key business objectives and then to have your solutions partner propose how its systems will deliver those benefits.
- You should choose and involve a solutions partner at the earliest possible opportunity, specifically looking for SaaS suppliers that do everything you need without using or reselling third party technology. You should also get a feel for the supplier’s ability to be agile enough to deliver the 20% tailored development you will need to make your project a success at the start, and to enter an agreement that includes the improvements that will be needed over the contract period.
- Once your objectives are set and a solutions partner chosen, you will need to allocate a full-time project manager to ensure focus is maintained, and to get structured input from end-users at the earliest opportunity. All of the contributors can offer a different and valuable perspective, but the buck stops with the project manager, so the decision as to who that will be should not be taken lightly.
- By following these steps you should end up with a new system that fits your needs, enables you to increase productivity and profitability, and adapts as your business evolves. You should also have a technology and process management supplier that becomes a trusted partner that works with your organisation for years to come.
- However, what is really important is to remember is that technology is an enabler for change and normally drives changes in processes, structure and sometimes people. Technology can only do the enabling; it’s down to the management team to use it effectively.