How you can stop worrying (about implementation) & love cloud adoption

The control freak in you is all about implementation. To be completely honest, the control freak in all of us is all about implementation. Implementation speaks to having our fingers in every single detail, in every single moment in a process. It’s about doing things the way we’ve always done them. Implementations are like reconstructing your mother’s famous chicken soup recipe in your own kitchen. We strive to rebuild the comfort we are used to.

However, this perceived need for persisting in the past is usually a key to a pandora’s box. As you travel that implementation pathway, you tend to discover an issue or two or five. These issues typically have seemingly easy customizations that attack the root of the problem. However, in sticking with the food metaphors, once you pop the Pringles can of customizations, you can’t stop. The next thing you know, you have a uniquely adapted system that looks like nothing else in the world.

You are truly unique. That’s fabulous for art, but it’s a bit of a problem for software because, at some point, something will have to change, to be upgraded, to be swapped out or replaced. And, if you took the implementation-to-customization route, trying to figure out what and how to unravel customizations can be a very long, very difficult, and very, very expensive process.

If we quell our kneejerk need for implementation—control your inner control freak, you might say—there truly is a better way that’s easier on you, your processes, your people, your tech, and, in the end, your future planning. What’s required is a shift in mindset from thinking about your next large-scale software changeout in the terms and techniques inherent in implementation to the new concepts and flexibility unique to adoption.

Let’s double click on that.

Is there really a difference between implementation and adoption?

The short answer here is: absolutely. While it may seem like we’re picking and choosing popular buzzwords and splitting those proverbial hairs, this comparison really does have a solid, defining difference in foundation. Implementation means you drive the process. Adoption means the process drives you, which can be super scary for our inner control freaks.

So, why is that shift to adoption so important? Three things come to mind: (1.) ease of updates. (2.) lower costs. (3.) future-proofing your organization.

To truly achieve those three very important benefits of the cloud adoption process, you must change the way you’re thinking at the beginning of the process, even if it feels like you’re “losing control.” Trust us. You’re not losing any amount of control. You’re simply shifting from micromanaging to macro-managing—moving decisions, planning, and strategy away from those devilish details and into a long-haul mindset that focuses on benefits to achieve and not on the exact path to get there.

So, why does it feel that way? Because you don’t have access. You can’t touch the source code to customize. You can’t access the database the same way you used to. You don’t have the connection you were expecting, the one you’ve become comfortable with.

But remember, that kneejerk thinking returns you right to that implementation thinking (and right back to increasing time spent on the project, complicated customizations, and increasing issues down the road—not to mention that all-important expense factor).

How do you get comfortable with the adoption mindset? Here’s an ever-popular listicle to help you.

(1.) pull long-haul and future generations planning into your upfront talks—those first meetings, those initial sit-downs with the team. This isn’t about this one project; this is about a lot of projects that will all tie together to make your system smarter, stronger, faster. How do you lay the foundation for that up front?

(2.) to get comfortable, discuss your discomfort. What scares you about this process? Is it the loss of access? If so, think about how often you use that access and whether those moments are frustrating enough that having fewer of them might be quite a good thing all around. Lay all those process problems out on the table.

(3.) trust yourself. You’ve already done a lot of the heavy-lifting work during the selection process. Now is the time to build on that foundation, not undermine it by getting bogged down in the same details as always. Trust what’s in the box you bought; you’ve already done the research on it.

(4.) lay out potential impacts, pain points, and slowdowns within the organization during the process and maintain transparency both within your team and within the wider organization. Remember: No one expects perfection, but no one likes a nasty surprise.

(5.) while you need to be transparent with those pain points, don’t lead with them. Begin these talks with a look at the benefits coming for each stakeholder in the process, from the C-suite to the customer rep.

(6.) get an executive sponsor/point person whose job it is to talk through everything, be the face of the project, and lead the charge of change—a physical, personal manifestation of the mantra.

(7.) constantly circle back to the thinking that brought you here in the first place: You need this change. This change is positive, and there are many good reasons to go through these growing pains.

ABOUT ESC PARTNERS:

ESC Partners is building #smartcities from #utilities work to #publicworks with solutions in the #Oracle Cloud. Let us show you how your city can be #hometownSMART today. Just send us a note via the contact form, and we'll circle back within 48 hours. Or contact us anytime on FB, X/Twitter, or LI. You can click through directly from the icons on the footer of this page.