Journey to Cloud: 5 Common Cloud Implementation Risks and How to Avoid Them

If you are migrating from on-premise to Cloud or implementing a new Cloud SaaS service, these 5 common Cloud implementation risks should be on your radar. 

Having had the privilege of putting a number of Customers live on Oracle CX Cloud, we have seen a few patterns that we thought we could share, to help other people in their own journey to the cloud. If you're considering either migrating from on-premise to Cloud or implementing a new Cloud SaaS service, these 5 common Cloud implementation risks should be on your radar. We decided to focus on SaaS as the core of this article, because this is the most common play we've seen from our customers.

1. Managing expectations from on-premise models #

For people moving from on-premise to SaaS subscriptions (such as Oracle Sales or Service Cloud), there is usually a trade-off between the range of extensibility options, which is virtually unlimited in on-premise applications, and the agility of having a best-of-breed application pre-built and managed for you, in which case the Cloud deployment option is a clear winner.

For that reason, approaches like the on-premise run-of-the-mill “lift and shift” are really not advisable on SaaS. Trying to twist a SaaS application around to conform to processes that may have been heavily customised in the on-premise application will not only introduce risk to a SaaS application (making things like upgrades and patches significantly more complex), but might even make the processes that ship "out-of-the-box" with the SaaS application unusable, losing a lot of the benefits that come with it. This is also a good opportunity to re-think and modernise your old business processes!

Of course, some degree of configuration / extensibility is to be expected--and fortunately most modern SaaS applications like the ones mentioned above are built to support a degree of this, especially if the application is to be adopted by users of more specific, niche, processes. It is in this case that the need for advisory from an experienced and trusted implementation partner can be invaluable and save you time, money and a few headaches in the longer run. The debate between configuration and customisation is very relevant on Cloud, to ensure applications are rolled-out with minimal acceptable risk and it is important to be aware of when something can be achieved via configuration instead of full customisation, of features that are being added to the product roadmap and to adequately manage any gaps.

When extensive customisation is indeed required, then an option to consider is PaaS (Platform as a Service, which we've blogged about before here). This is usually referred to as the "PaaS4SaaS" play, where PaaS services (such as Oracle Java Cloud Services to build and deploy custom application extensions) and features are used to enhance the core processes delivered by a SaaS subscription.

2. Skills gap #

Moving to the Cloud usually involves a wide range of skills. Although this is typical of any IT project, Cloud is special because the skill set is slightly different, and may rely more heavily on the business side. We've always felt that, to deliver the best results as a joined up effort with our customers, our teams need to be able to embed in the customer teams—regardless of an on-site or remote delivery model. While on traditional IT projects this typically meant more IT presence, our Cloud teams usually find themselves deeply tied directly with the business users, at all levels of an organisation, from sitting next to sales reps, to meetings with CTOs and CFOs. There are several key reasons for this.

Firstly, with Cloud applications, business users have a much greater role in shaping the application for themselves, whereas previously this was the remit of a (relatively large) IT organisation. Secondly, it is important to know the processes these users are expected to deliver in the new application, their pain points and challenges and where they will get the most value. Lastly, the change of budgetary approval requirements that follows a shift from CapEx to OpEx, means that decisions are usually done directly at Line of Business level. In short, this means that your implementation team not only need deep (expert level) knowledge of the application, but also be able to converse directly at the same level to business users, from sales reps or customer service reps, to sales directors, CFOs, etc.

3. Disconnected business and implementation teams #

This was already partially covered above, in terms of the skills that the implementation team need to command and their ability to embed within the business team. A key area where the implementation team must be able to drive conversations is requirements gathering. This is absolutely crucial because requirements need to be challenged and drilled into to really understand the underlying needs and which application features could be leveraged to address those needs and where custom development is required.

One way in which this becomes evident is, sadly, after the fact. We have rescued a number of projects where it was clear that the implementation team had gathered what they perceived to be the requirements. Not having adequately challenged these or mapped them to the application capabilities, this meant they either ended up with deliverables that did not address the underlying needs or bloated customisations that hindered the customer from actually using the application as it was intended and getting the most benefit from it. These mismatches then lead to additional costs incurred in unnecessary build and testing effort and ultimately lead to Customers being dissatisfied with the implementation team, poor user adoption and dissatisfaction with the software or, more commonly, all of these.

We have also seen a number of cases where customers believe that end users can be involved only towards (or after) User Acceptance Testing. What we've seen is that users involved this late in the process usually have bigger issues adopting the new application. Sometimes this can be down to their needs not having been understood and therefore met, but often it is down to not having been involved in the decisions from the start. Therefore, we advise Customers that leaving users out of the initial Discovery Workshops (where we dig deeper into the requirements and challenge them, exploring various solutions) means that they are missing out on their invaluable experience and contributions and also increasing the risk of poor user adoption. Getting end-users involved early on also helps manage their expectations and getting early buy-in. These users will usually later become advocates and really help with change management while rolling out the solution to the entire organisation.

4. Integration not considered from the start #

Sometimes, when a Customer brings a partner to the conversation, they will already have firm expectations of what they want their new SaaS application to do. They will also already have an idea of how it should fit in their architecture and already have pre-approved a budget. This is not always the case and, more often than not, we are brought early on in the process and are able to steer the conversation from a solution architecture perspective. This means that requirements need to be considered in terms of which data needs to flow to and from other systems, which systems hold the golden record for master or transactional information, which fields are required and must be gathered at various points in the process, etc. It is important that these considerations be raised as early as possible. The longer these are delayed, the higher the impact to the project plan and budget.

Other systems like middleware also need to be considered, as they will have their own requirements that might not be immediately perceivable by the business team that have acquired the SaaS subscription. The skills required to adequately design and implement an integration solution are not the same skills as required to implement any of the individual applications.

5. Inadequate testing #

Finally, we cannot neglect the importance of testing--not just for software bugs, but for the correct understanding and validation of requirements and functionality. We cannot stress enough the importance of starting the testing effort in parallel with requirements gathering and design. Specifying and writing down the test cases helps bring a common understanding to the requirements and helps manage expectations when the tests are executed.

Without diminishing the importance of unit testing and integration testing, we would just stress the importance of User Acceptance Testing (UAT), because at this point the end users will be getting their hands on the solution. As above, getting users involved in defining the solution from the start and throughout up to this point is crucial to managing a number of different risks that impact this moment and can make or break an implementation.

Key take-aways #

Cloud projects are, at least when compared to on-premise, very simple. Part of this simplicity comes from knowing how to best leverage the SaaS applications for what they were built to do and extend them only when necessary, and even then knowing how to use the right tools for the job. Considering how your SaaS and PaaS applications will integrate with your existing architecture is essential from the start, and the same applies to getting your users involved in requirements gathering and specifying the corresponding test cases. For the best results, the implementation team on a Cloud project will have to know what they’re doing, not just in terms of the technology, but also delivering the best results to address your users’ needs. First time right.

Find out more #

If you want to engage with us to discuss any concerns you have with on going Cloud projects or projects you're about to embark on,  email us at [email protected] or call us today on +44 203 2834315 to speak to our experts.