When Cloud Implementations Go Bad
By Matt Richards, Managing Director, Oracle Cloud Practice, KPMG US
Matt Richards, Managing Director, Oracle Cloud Practice, KPMG US
Cloud has completely changed the implemen¬tation risk-reward equation. Leveraging pre-built process workflows and pre-configured technology environments, cloud applications can typically be im-plemented two or three times faster than on-premise systems, with predictable outcomes. What once took weeks, now takes days or hours. What once felt like a massive risk increasingly feels more like a solid bet. Cloud systems projects rarely fail.
But despite the benefits, cloud implementations can still go off track. Over the past several years I’ve seen dozens of enterprise cloud deployments— ranging from the best to the worst—and believe there are three common ways why cloud systems implementations go bad.
The first is implementation failure point is overconfidence. I get nervous when clients or key stakeholders say something like, “The cloud is prebuilt, and so the implementation will be easy. Just plug it in and go.” This attitude is sometimes a byproduct by ambitious software sales representatives who rarely have actual real life experience implementing these products. Don’t fall for this trap.
Cloud implementations are not simple—they represent a massive change in how technology is consumed in the enterprise. While the applications themselves are technical marvels, installing them almost always big changes in people and process. What was done one way for years must be done a different way in the cloud. This creates a massive change management challenge for clients that have used aged, legacy systems for decades.
On the majority of our projects, clients underestimate the amount of change management needed for these systems implementations. They think end users will magically see the benefits of the cloud and embrace it with gusto. That simply doesn’t happen. Don’t underestimate how difficult it will be!
The second is trying to recreate the old in the new. Cloud systems are purpose-built to support a certain way of running your business. They were crafted by software vendors to support a process and organizational structure thatis regarded as the industry or business standard. This push to standard is essential to driving out customization, and achieve the economies of scale that make the cloud economically attractive.
The fatal flaw I often see is trying to reconstruct legacy processes or technologies in the cloud. Resist the urge to rebuild in the cloud what you have today on-premise! This almost always creates problems, and frequently dooms projects. Think of your cloud implementation as a blank slate opportunity to rethink your entire operating model. Don’t miss the chance to reimagine your enterprise, stripping out all that’s not value added or redundant. Commit to adopting the best practices provided by your software vendor and implementer.
The final way I see these projects often go bad is lack of executive or line of business support. Most on-premise legacy system implementations from the past were IT led with support from functional leaders. System implementation teams gathered information from functional leaders, then blue-printed an application that was presented back weeks or months later for approval. Business leaders were the approvers of on-premise systems, but IT was the builder. This put IT in a politically powerful position.
Cloud has completely changed the project ownership dynamic. Since the application is prebuilt with prescriptive processes, the business has become the de facto owners of cloud implementations. Unlike the past, IT typically supports but doesn’t lead these projects. This has put new pressures on the business to commit time and resources to these projects. Red flags go up when I hear business leaders say, “We’re really busy right now. Work with IT.” This is not a good sign for cloud projects. When functional leaders resist taking ownership, bad things can happen and projects fail.
Functional support is demonstrated in resource commitments. When leaders are committed, they allocate key people and put them on the implementation. On KPMG’s projects, we insist that a functional leader serve as the overall implementation owner with support from an IT resource. We also require an executive sponsor from the function or business to be championing the project to fellow leaders. These are “must haves” for our projects.
It should come as no surprise that a realistic implementation plan plus a commitment to embrace best practices supported by business leaders are common denominators in successful cloud implementations. I’ll admit that these seem pretty obvious. But oftentimes, what seems so obvious still doesn’t make its way into the implementation strategy for one of these projects. Clients continue to overlook these items and find themselves in implementation trouble.
Avoid these three pitfalls and you should be on your way to a successful cloud implementation.
On the majority of our projects, clients underestimate the amount of change management needed for these systems implementations
The fatal flaw I often see is trying to reconstruct legacy processes or technologies in the cloud. Resist the urge to rebuild in the cloud what you have today on-premise! This almost always creates problems, and frequently dooms projects. Think of your cloud implementation as a blank slate opportunity to rethink your entire operating model. Don’t miss the chance to reimagine your enterprise, stripping out all that’s not value added or redundant. Commit to adopting the best practices provided by your software vendor and implementer.
The final way I see these projects often go bad is lack of executive or line of business support. Most on-premise legacy system implementations from the past were IT led with support from functional leaders. System implementation teams gathered information from functional leaders, then blue-printed an application that was presented back weeks or months later for approval. Business leaders were the approvers of on-premise systems, but IT was the builder. This put IT in a politically powerful position.
Cloud has completely changed the project ownership dynamic. Since the application is prebuilt with prescriptive processes, the business has become the de facto owners of cloud implementations. Unlike the past, IT typically supports but doesn’t lead these projects. This has put new pressures on the business to commit time and resources to these projects. Red flags go up when I hear business leaders say, “We’re really busy right now. Work with IT.” This is not a good sign for cloud projects. When functional leaders resist taking ownership, bad things can happen and projects fail.
Functional support is demonstrated in resource commitments. When leaders are committed, they allocate key people and put them on the implementation. On KPMG’s projects, we insist that a functional leader serve as the overall implementation owner with support from an IT resource. We also require an executive sponsor from the function or business to be championing the project to fellow leaders. These are “must haves” for our projects.
It should come as no surprise that a realistic implementation plan plus a commitment to embrace best practices supported by business leaders are common denominators in successful cloud implementations. I’ll admit that these seem pretty obvious. But oftentimes, what seems so obvious still doesn’t make its way into the implementation strategy for one of these projects. Clients continue to overlook these items and find themselves in implementation trouble.
Avoid these three pitfalls and you should be on your way to a successful cloud implementation.
Read Also
ORACLE's Cloud Service
Martin Ingram, CIO/SVP, Arise
Enhancing Customer Experience with Oracle Service Cloud
Sunil Gandhe, COO, Onsitego
ERP Consolidation - A Necessity Today
Seshadri Viswanathan, VP Information Technology, Dorf Ketal Chemicals
Proper Data Solutions Can Accelerate the Company's Digitization Process and Enhance Its Competitiveness
Xuewu Wang, Head of Data Labs, China Eastern Airlines
