Avoid SaaS deployment failure by prioritising post-go-live services

Enterprises are failing to maximise the benefits of their SaaS deployments because they under-estimate the importance of ongoing management services. Too many clients have either considered the post go-live stage to be a ‘steady state’ or believed they have adequate in-house resources and processes to manage it themselves. Here, we outline the key things that clients keep getting wrong, and look at why, and what they need to do about it.

Post-Go-Live is the beginning, not the end

SaaS service deployments require a mind-set change compared with on-premise application projects. If you think you can employ the same approach and expect the same long-term results, you will be disappointed and very unpleasantly surprised. (see: SaaS Services Success Requires A Different Approach.) The HfS SaaS services Blueprint reports over the past few years, covering Workday, SuccessFactors, Microsoft Dynamics and Salesforce services, have highlighted the following common themes:

• Consulting services: These are in growth, as enterprises increasingly consider adopting a holistic approach that positions the specific SaaS deployment in the context of their process strategy (HR, CRM, ERP). True transformations are rare unless you are receptive to the service provider’s vision in the space, or, more often, if your project champion (e.g. CHRO) is particularly visionary.
• Implementation Services: Enterprises continue to proceed with fast deployments, prioritising an ‘on time and on budget’ SLA that denotes project success. While obviously important, enterprises are not taking enough time to consider implications of decisions in this phase. For example, consider whether you can transform a process or even do away with it altogether, before painstakingly matching the functionality in the SaaS product. Moreover, to quote a recent Workday client ‘Remember that the SaaS product is the best practice. Do not try to make it adapt to your processes. Instead adapt to it’. Ask a lot of ‘why?’ questions in this phase. Our research shows that many clients say they wished their service provider had pushed back on some of their requests because it caused additional work later in the project. Service providers should know this based on their experience, but deployment teams do not often share this proactively, so it’s up to you to ensure that all decisions are questioned.
• Management and Optimisation Services: We see the management services space as made up of standard ongoing support services as well as proactive, consultative optimisation services. This is the area that too many enterprises are just ignoring. Granted, demand is picking up, but it is still a small market. SaaS products are updated with new functionalities and even new modules several times a year. This means that you need to make sure you and your end-users understand the changes and are comfortable using the tweaked product. In addition, you must understand the implications of the changes to your systems and processes. In other words, management services are not a steady-state hum in the background. They include optimisation services that are dynamic, visible, strategic services that likely involve ongoing consulting and implementation work. Also, it is in this phase that you can take advantage of the latest technology and business enablers, such as analytics solutions.

Where are enterprises failing and what do you need to do about it?

Over the past three years, HfS has spoken with more than 160 SaaS services buyers who have shared the pros and cons of their SaaS deployments. The four main reasons that they have failed to focus on post- go-live services can be broadly categorised as follows:

1. Speed is our priority: Many of the organizations we spoke with had decided that they wanted a cloud product. Many still compared the cloud options with the latest version of their legacy on-premise solution, but this was often purely academic as the cloud journey was the preferred option. Once this has been decided, enterprises forge ahead to achieve as fast a deployment as possible. This includes global deployments, covering several geographical sites and most if not all employees (in the case of a HR solution). Gone are the days of long drawn-out design phases and 2-year deployment cycles. While this demonstrates progress and a nod to the current agile development environment, it does have its issues. One of the most obvious problems is that enterprises are so hung up on the speed of deployment that they overlook the post-go-live process, and the corresponding resource, time and cost requirement. Here are a few quotes from clients we spoke with, that highlight their short-term focus:

• “Because our deployment was very rushed (our fault), the service provider did not push us hard enough to document our own existing processes. This led to some misses late in the project, and left us with some stabilization work in the year following go-live”
• “The time was not right for these conversations, given our focus on getting initial scope implemented.”
• “There was no time to look beyond a few weeks at a time.”

Action: Give SaaS deployments the same attention that you did to on-premise projects. They have clear differences, but this does not mean that you should completely believe the SaaS vendors’ hype that the product is so easy, intuitive, cost-effective and business-ready that you will need minimum IT support capability.

2. We didn’t even know to ask for this: The most common quote we hear from SaaS services clients is “we don’t know what we don’t know”. Enterprises rely on service providers to proactively communicate everything the client needs to consider for a successful SaaS experience. However, resource constraints lead to delivery teams being very technically oriented, often experts in only one specific module, resulting in challenges for them to present any holistic or long-term scenario for clients. One client even told us that they didn’t believe their service provider even offered post-go-live services – in fact, the provider has a solid catalogue of these capabilities.

Action: Proactively ask questions to your service provider project team leaders to ensure that you understand all implications of the project, especially the post-go-live requirements. A conversation with the relevant service provider experts should not cost any money, and even if you do not engage any post-go-live services with them, at least you will be better prepared for the implications and requirements.

3. We can manage Post-Go-Live in-house: This strategy is not a weakness because at least the client recognizes the need for post-go-live support services. Examples we have heard include a global enterprise developing a Centre of Excellence to stay abreast of new software features. The one possible issue with an in-house approach is ensuring that you do have everything covered. Several service providers offer consulting advice, which explains how the client can do management services successfully and effectively. You may be caught out by how many resources you need, with the right skills mix, to make this work. In addition, you may still need ad-hoc access to external consultants with specific expertise, for example in new modules.

Action: Seek advice from the service provider about how to effectively manage a SaaS deployment. Be prepared to still use ad hoc external resources for advice.

4. Our service provider didn’t explain this: While there are elements of this in all the points above, it’s worth highlighting as a stand-alone issue. Clients we have spoken with emphasise that they appreciate service providers pushing back on some of the decisions that clients make, if the ramifications of their decision may cause problems later, namely in the post-go-live stage. One client who was rating a service provider for their flexibility, stressed that there is such a thing as ‘too much flexibility’ where the service provider simply agrees to all the client’s demands, regardless of any future implications. The following client quotes sum up some of the problems that this can cause:

• “We were surprised that this came up at end of the engagement and it’s something we needed a lot earlier on… this caught us by surprise – we now need to invest in a system that was not part of the business case.”
• “We would have appreciated more best-practice sharing without needing to request it.”
• “We had to proactively tease things from them (the service provider).”
• “A lot of credit for getting the project done but they (the service provider) didn’t ask the ‘Why’ questions or think about doing the business differently.”
• “We would have definitely benefitted from having a solid testing strategy/plan for accommodating the weekly updates and the bi-annual upgrades.”

Action: Create a collaborative environment, in which service providers are not encouraged to blindly agree to all your requests. Tell your account and project leads that you require a full picture of the deployment including post-go-live implications. If necessary, demand regular access to a senior consultant throughout the deployment so that post-go-live requirements are considered and prepared, whether with external or internal resources.

The bottom line: Have a plan for SaaS Management Services or risk a failed project

Achieving go-live is an important milestone, but effective, ongoing support services, which include optimisation services, ultimately ensure a successful deployment. Adopting SaaS is an ongoing, dynamic project, which requires up-to-date module skills, as well as deep understanding of your changing business strategy. Whether you opt to manage the SaaS solution in-house, with additional external consultants, or choose to completely outsource it to a service provider, make sure you prioritize this at the beginning of your deployment journey, so that there are no unpleasant surprises towards the end.