The Cloud: 6 Considerations That Are Often Overlooked at The Start Of An Implementation
By Michael Sheppard, M.S., Data Foundations Director, EDIS, HITS, University of Michigan
Introduction
Let’s paint a hypothetical scenario: You just came out of a meeting with an executive in your company and they informed you that they just had a conversation with a peer of theirs at a different company. What they heard was that Cloud solved several critical issues for that company and now your executive wants the same and more out of Cloud technology. This is just what you’ve been waiting to hear! The next hour is filled with positive energy and lively discussion. At the close of the meeting, everyone seemed aligned on a single goal: Your company will “adopt the Cloud.”
From this moment on, if you are not careful, things will go bad in a hurry. There are so many ways that a cloud adoption can fail, but I believe there are 6 challenges that, if not addressed early, can torpedo a cloud implementation. If you are an IT leader tasked with solutioning a cloud architecture, consider these themes before any others. Check each one off as complete and you will dramatically improve your odds of success. Some of what is given below can just be considered good project management practice and yet other aspects, I think, plague cloud initiatives more than other projects.
In a previous position, I was involved in a cloud implementation where this basic question had not been addressed at the project kickoff. We raised the concern early and addressed it before too many cycles were wasted by going in the wrong direction.
Who is sponsoring your journey?
Is there a single person on the executive team that is putting their name on this project? Are they empowered and prepared to endorse project recommendations and, potentially, have tough conversations regarding the setting of priorities, cost models, service disruptions, organizational support models, and resource allocations?
What are the business drivers?
Reaching consensus on your business drivers through conversations with your project sponsor is key. Many leaders in your organization will be stakeholders and have different motivations for adopting a cloud solution. Learn what their challenges are. Do they need to cut costs, or improve a service, or expand their infrastructure, or meet regulatory challenges, etc..…? Some of these drivers may work against each other, so capturing them, prioritizing them, and setting expectations with stakeholders is key to developing a viable project scope. People sometimes assume that the cloud is a value-add-only proposition and that no sacrifices will be required, but that may not always be the case. It is unlikely that an organization can build everything in the cloud that they have in their on-premise data center today for less money.
What is the scope of the effort?
When you have reached a consensus on business drivers, then you can craft a project scope with specific deliverables. It is important for IT executives and the sponsor(s) to share their perspectives on a project scope that is right for the organization. I find it useful to frame the project with one of three implementations: A proof of concept, a pilot, or a commitment to an enterprise-wide “full” production implementation. These three general scopes will have vastly different budgets, resource needs, risks, and timelines. Using these terms often with a sponsor and stakeholders creates guideposts for the scope conversation.
What are the expected outcomes?
In a previous position, I was involved in a cloud implementation where this basic question had not been addressed at the project kickoff. We raised the concern early and addressed it before too many cycles were wasted by going in the wrong direction. Put an emphasis on outcomes over output. Outcomes should be measurable and aligned with business drivers. Socialize the expected outcomes with your sponsors and stakeholders.
Find your champions and realign your organization
This is the big one! Anyone who has led an organizational realignment knows that individuals and whole teams will not naturally find their way into new roles and responsibilities. That is because realignments don’t just change people’s positions. It disrupts employees’ cultural norms and sense of community. To nudge an organization in a different direction is nothing short of an act of will on the part of the leader. Left to their own devices, your support teams will trend to IaaS technology offerings and your cloud implementation will look a lot like a hardware “Lift and Shift.” Why? Because people will continue to do what is familiar to them – not because they are lazy, but because the current organizational alignment and reward system keeps them focused on the systems and processes in place today. So, if IaaS isn’t what you want, then you will have your work cut out for you in this space. You can improve your odds of success by recruiting a technical champion for your cause. This is a person who believes in your vision and can provide continuity of message in decisions around technology and organization. This person can be recruited from outside the organization, but they may be more influential if they are an existing staff member that your team trusts.
Building the Guiding Principles and a Reference Architecture
If you have the activities above checked off, you may be ready to start thinking about how to approach the work. Your team is going to need a strong guiding hand and sounding board. If you haven’t logged into a hyperscaler portal like Google, Azure, or AWS, then prepare yourself before you do because the sheer number of product offerings can be overwhelming. Your project team is going to need some guiding principles early in their technology evaluation. I once worked on a cloud implementation team that was instructed to just “explore and try some things.” While that sounded very appealing to IT professionals at the outset, inevitably, it led to confusion and a splintering based on opinions very early in the project. Before project team members create their first Cloud portal account and log in, you will need to task your champion with leading a small workgroup in building a set of guiding principles. The guiding principles are there to help project teams make decisions when there is a fork in the road and resolve differences in opinion between architects.
Summary
If this article has helped you to realize that getting your Cloud project off the ground will depend on your ability to guide your company’s leadership to reach a consensus and inspire change in staff, then you are on the right track. Once you’ve put your analysis and leadership skills to good use, you can then demonstrate your technical prowess. When the project closes, you may be celebrated for your, and your team’s, ability to build the right solution architecture for your company, but clearing these early hurdles will ensure that you get that far.