Getting Everyone on Your Team: Planning with All Your Stakeholders
Mar 08, 2021
Designating a particular department or team to take the lead on cloud migration can be beneficial to drive your project forward. Problems can occur, however, if that team forgets to think beyond the particular needs and capabilities of their own department. This can occur when one group is the driving force initiating the change, or when others are simply less familiar or have less motivation to be involved. Let’s take a look at when the small-unit approach can be problematic, and how to remedy this.
The Trap of Too Few
The unit driving the migration often feels empowered and motivated – and those are positive characteristics for change. But moving too fast or failing to solicit input from other stakeholders across your organization can lead to missed opportunities, divided efforts, and the necessity for future design changes that should have been caught ahead of time. Plus, nothing destroys cohesion and forward motion as quickly as making others feel surprised, ignored, or as if their concerns don’t matter.
For example, it might be natural for an operations department to approach migration from the perspective of their own problem set – what they view as their current impediments and the capabilities they see the cloud bringing to the organization. But if they develop too far internally, they will suddenly find themselves in the position of telling the security department: “We’re moving to the cloud, so get ready!” In this scenario, lack of communication across departments means valuable technical insight that would have helped shape planning was not brought in early enough, and now what should have been a cooperative effort can very easily create a rift that turns the whole project into an adversarial process.
Seeking Buy-In
The solution is to make a deliberate and concerted effort to get buy-in from all of the organization’s key stakeholders. Each will see slightly different benefits to cloud migration, through the prism of their particular specialties. Even more importantly, they will see potential problem areas and issues that other teams might not recognize.
Including all of your technical teams and functional units helps ensure that your migration plan arrives at a solution that best addresses everyone’s needs, as well as an agreed-upon understanding of how the project should proceed.
Which Teams to Include?
How do you know that you haven’t missed an important perspective? At a minimum your planning period should pull in members from:
All technical teams
Operations
Security
Developers
Leadership
Additionally, representatives from the following departments might surprise you with relevant insight derived from their areas of expertise. Consider including:
Accounting
Marketing
Sales and Customer Relations
Beware the trap of how good it can feel to quickly deliver functionality to meet your own team’s needs. Make an effort to get buy-in from all stakeholders. Doing so will not only help build a great team, but it will also save you from costly reengineering during implementation to solve a problem that would have been obvious to someone who wasn’t included.
Once you’ve included all your stakeholders and developed a comprehensive and collaborative plan for cloud migration, you’ll need to determine your readiness requirements. In our next blog, you’ll discover the basics of compliance, and how to best involve security in your planning process:
Asim Iqbal
Asim is Enquizit’s CTO and a member of the founding team. He has been an SME on security, storage, and resilience as well as Enquizit’s Lead Architect and VP of Solution Architecture. Among his professional endeavors is the implementation of a weather modeling HPC setup for Environment Canada, storage design and implementation for the Canadian National Institute for the Blind’s library, Media ingestion, encryption, and transcoding architecture for Bell Satellite TV, Cloud infrastructure, resilience, and security architecture and implementation for The Common Application and complete migration of Harvard Business Review’s Primary and DR data center to AWS. He maintains a strong personal interest in frictionless technical designs focused on end-user happiness and employee satisfaction, still thinks that ‘Data Availability Architect’ (from his early days working with HPE) is the coolest certification title ever and is an ex-CISSP. He neither confirms nor denies his purported afflictions with coffee, slow travel, and cats with unbridled spirits.
