Top 3 reasons why the cloud transformation experience is painful and disappointing

Why are enterprise organizations losing trust in the promises of system integrators and hyperscalers? Is the cloud not all about being the land of milk and honey? Apparently, it is not. While sellers and so-called experts describe it as a silver bullet to all issues IT, the reality is different. Cloud is simple yet complex, meaning the core principles are easy to get, the range and variety of services and options is rather complex. Let’s explore the top three disappointments, challenges and misconceptions leading to this loss of trust.

#1 The time share needed of internal resources

There is the promise that the journey to the cloud is requiring only very little time from the internal team and the application/business owners if any at all. The experience by enterprises is that this promise has not been kept. Even though the integrators to date mostly targeted the easy jobs like Lift & Shift rather than the application graveyards, they have disappointed. The need to directly involve internal teams went beyond all promises and let to a high level of frustration. Keep in mind these cloud projects are often IT department driven and are totally reliant on the cooperation and collaboration of the application and business departments. Now, imaging that IT took the first steps with them on the promise of least effort by them, least downtime and maximum outcome. And then reality hit, and it hit hard. The value from Lift & Shift is lesser than promised, the time share needed much higher and rather than running this smoothly it is perceived as intrusive from assessment to deployment.

For second generation approaches, using automation, tackling the graveyards and actually really limiting the time share needed, this early wave of bad experiences has created a massive trust issue. You end up running PoCs, pilots and low number batches and have to prove yourselve again and again because others have failed before. Yes, a burnt child dreads the fire but on the other hand the pressure to move is only increasing and these countless iterations due to lack of trust reduce the overall velocity.

 #2 Using well established, or as I call it, outdated approaches

Sometimes you wonder. Why would someone in 2022 still suggest a waterfall approach to a cloud transformation be defining wave groups? Why would a major consulting and services company suggest a multiyear approach and plan it from end to end, where all of us know that the plan will not stick beyond even the first 6 months?

No Plan Survives First Contact With the Enemy

The reality is that this happens ever day. The drivers for this are

• Lack of automation approach
• Time and Material budgeting instead of a factory approach (there is the risk of idle times for the factory)
• Not knowing better
• Afraid to challenge the client with the art of the possible
• Listening to the hyperscalers which still talk about wave groups

Do not get me wrong, I do understand the concept of dependencies and that some things must move at the same time. But why you do not put applications into a backlog, the factory can pull from and drive speed through that, is a mystery to me. Through backlog grooming you can adjust to priority changes, group applications/servers together and keep the speed up. Any team in the factory that has capacity can pull from the backlog. The result is that you cut down the overall project time / increase the velocity, reduce the cost through avoidance of idle times and gain the flexibility to adjust to business needs and changes.

This also helps with the #1 issue from above as you can use availability and readiness, see #3 below, as criteria for your backlog grooming.

The nice thing is that this also enables enterprises to run the different value levels from re-hosting to re-architecture in parallel. And, if you have a partner that has the right approach and automation, they can also drive your custom java/.net applications up the value chain into re-architecture without changes to the overall timeline.

#3 Lack of internal readiness

In a perfect world all internal resources are trained and ready for the cloud, new software architectures and the use of CI/CD processes and tools. Sadly, we do not live in a perfect world. And not being ready and trained is at least 50% of the reason for resistance to change and 80% to 90% of the time the reason for delays. It is not the system integrator or the hyper scaler that is causing delays of cloud projects. It is you and the internal organization. Bold statement? No, actually not. It is the hard earned and painful experience of real project life.

This starts as early as budgeting. As one client lately told me about having a budget challenge but not with the 3rd party project cost but the internal cost of getting the different teams ready and trained. Even though the external cost was agreed on and a purchase order ready, the timeline had to be revised and slowed down due to internal readiness efforts needed on the client side.

This leads to painful discussions where client project participants question the system integrator about the client's internal strategy and their decisions. A difficult spot to be in and certainly a sign of lack of client internal communication and sometimes even ownership.

 It is not technology that leads to lost trust and disappointment!

You might be surprised that there is no technology point here. The reason is that technology challenges can be solved one way or the other and are fact based, at least usually. The nature of the points above is, that we often have to deal with a level of “feelings”, challenge the status quo and inflict change. To overcome these, I have compiled the following action items to consider:

• Plan how many iterations of proof you need to trust again in advance and communicate openly
• Be aware that penalties will not reduce the frustration of the application/business owners of overuse of their time
• Be on the lookout for a provider that drives automation at the core of the approach
• If you use tools like the Gartner Magic quadrant – be sure to read the detailed texts. Some providers are in the upper half due to their size, but the descriptions call out lack of cloud experience and solutions as a downside.
• Challenge the suggested journey planning for more flexible approaches than classic wave grouping
• Challenge the number of Lift & Shift applications and try to move up the value chain to the maximum extent.
• Explore the art of the possible. A great provider can always slow down easily, a bad provider though cannot speed up
• Drive your internal readiness (also beyond the direct IT/cloud team) as an immediate priority. Do not wait for the cloud to be chosen, or the procurement to have run an RfI/RfP process. Start today!