In Cloud Consulting
I want to share with you the top three mistakes that I see when implementing cloud applications
Independent Oracle Cloud Consultant
I've been the functional lead on over 20 Oracle cloud projects and my goal with this article is that you walk away with some insights and takeaways that you can use in your next implementation.
Misalignment
So let's dive right in. The first mistake is the misalignment between executive sponsors and business users. For example, let's say leadership wants to upgrade the HR systems to Oracle and the business users are attached to their existing legacy system and don't want to upgrade. These types of conflicts need to be addressed before implementation otherwise, they pose a significant risk to the project.
Imagine an implementation partner going on-site, holding requirement sessions, demos, and every time there's a new feature discussed there's push back from the business gaps identified, and it's as if the business is fighting to keep that old system alive. Meetings are getting drawn out, open items lists are exploding, and suddenly milestones are being missed and everyone is stressed out.
Make sure your team is all in the same page and committed to making the project a success. If there any holdouts try to explain the advantages why leadership chose this system and what it's going to do for the business as a whole. Now, of course take their concerns into consideration but if they're still not getting on board strongly consider if they're the right person for this project.
Unrealistic expectations
The second mistake to watch out for is having unrealistic expectations when it comes to cloud systems.
Now another way of saying this is treating cloud applications like they're on-premise. The business must understand the advantages and limitations of software as-a-service, aka the cloud.
Now, of course the infrastructure that used to be maintained by the company in house is now outsourced to the vendor like Oracle but one of the limitations that comes with that is a reduction in the ability to customize that application. Most organizations welcome this change because it forces them to standardize their processes and this is especially crucial if they're a global organization. In the case of Oracle, they've built into their system what are called modern best practices based on all their years of data-driven research from their customers. While not everything is going to be a perfect match the business should have a pretty good idea of any major functional gaps based on those early discovery sales sessions.
The worst case scenario is trying to force the system into highly specialized and customized processes that it wasn't really designed for and even if you get it to work there's a risk that it may not work with future updates and new functionality. This is one of those areas where early discussions with your implementation partner is critical especially someone that has direct knowledge of the module being implemented. I can't tell you how many times I've had to explain functionality to a client that had a different understanding of how that functionality worked from those early sales demos. Now, It's not that the sales rep was wrong or inaccurate, it was that they didn't go into the level of detail that the customer needed to really understand that functionality's capabilities and limitations.
Not taking ownership
The third and final mistake is not fully taking ownership of the system. The reason this happens is that people are busy, there's organization restructuring, open enrollment, year-end reporting, on-boarding new hires, and so on. The business must dedicate enough time and energy to this implementation, to the project, to fully take ownership and get it off the ground. Most teams take ownership of the application at go-live.
This is when the implementation partner has put everything into production, they hand it over and then support for a few weeks or a few months after that. While this approach works. It's not ideal and can even cause serious issues when the system's being rolled out. I've seen it many times where a client will attend all the meetings, they'll complete and update all the open items, they'll complete the testing, sign off and yet every time they're going through one of these steps they get the minimum required done and then they move on to the next activity in their daily job. And their may their mind just forgets, forgets everything that they did.
It's kind of like studying for a college exam. You've crammed all the information you can into short-term memory, you take the test, and then as soon as it's done, you forget most of what you learned and you're on to the next course. Of course, repetition is key and I don't expect anyone to learn a system like Oracle or any other cloud application just one time through, but there's a difference between a quick refresher and repetitive deep dives.
I can see these requests happening early on in the project as the team's learning the new application but when I see these requests coming in toward the end of the project, that's a red flag. Organizations that fall behind like this often have prolonged support periods and may even have critical issues or mistakes made in production. The way around this is to start taking ownership of the system prior to user acceptance testing.
This means reviewing all the documentation from the vendor, from the implementation partner, checking help articles, release notes, and so on. If there's any recordings of earlier sessions or meetings that you've had review those and also try to set up working sessions and training sessions with your implementation partner.
If you really want to take it to the next level offer to help with the UAT prep work. This means setting up users, double-checking the configuration, and doing some initial pre-testing. Ideally the business is running UAT and the consultants are there to support it. Now when I see this, I know that the launch is going to be successful and there's going to be minimal surprises or emergencies. There you have it.