By: Andy Troup
Successfully assessing workloads and placing them in the appropriate private, hybrid, and public cloud environments can make or break a cloud strategy, enabling greater agility and cost efficiency.
In this series, I’ve been reviewing four key areas to consider when performing a workload assessment. In the first three parts, I suggested a framework for classifying workloads as potential candidates for moving to a cloud environment, looked at service portfolio mapping, and examined how to assess the costs and benefits of moving workloads to a target cloud model.
In this final part of the series, let’s take a look at stakeholder analysis. How do you get stakeholder buy-in on your cloud strategy and roadmap?
First, Identify Your Stakeholders
When running a migration project, the first thing you should do is understand who your stakeholders are so you can make a judgment about:
- Risks that specific stakeholders will hold;
- Any unsupportive attitudes they might hold towards the proposed system;
- How they can help indicate the overall socio-political feasibility of the system.
Here’s a sequence you can follow to be sure you have everyone (and their relative influence on the project) accounted for:
- Identify each stakeholder by title and name.
- What are his/her interests?
- What level of influence and power will each have in the project?
- In what capacity might each be most effective for the project?
- How do you plan to communicate with each of them?
Don’t forget: There will be key stakeholders for the entire program of work as well as stakeholders for individual workloads (e.g. business units, application owners etc.).
Different Stakeholder Types
Stakeholders can be divided into four different groups. Each has their own set of concerns and drivers for putting workloads into the cloud:
- Business Stakeholders:
- Concerned about service disruption and service levels.
- Drivers: Reducing costs and time to market.
- Governance:
- Concerned about compliance, risk impact, data security, provider certifications (SOX etc).
- Drivers: Same as their concerns.
- Technology:
- Concerned about technical feasibility.
- Drivers: Greater agility, not just keeping the lights on, but being able to implement more lights due to reduced firefighting, efficiencies, cost controls.
- Operational:
- Concerned about vendor stability/lock-in, SLAs, availability.
- Drivers: Same their concerns.
The more you can understand your stakeholders drivers and especially concerns, the better equipped you are to ensure that they are on-board with your migration programme.
Applying Governance – A Matrix
Once you’ve identified your stakeholders and their concerns/drivers, you can place them in a matrix that calibrates their levels of interest and influence. This matrix will help you understand how to monitor and/or manage their concerns:
An Example
Take, for example, the case of supporting a decision around the feasibility of migrating your client-server application. Completing a stakeholder analysis will reveal that your proposed cloud migration will have many implications for the organization, including non-technical areas, such as the finance and marketing departments.
Overall, a positive net benefit may be clear to the business development functions of the enterprise and the more junior levels of the IT support functions. Yet the project management and support management functions of the enterprise might see a net zero benefit, while the technical manager and the support engineer functions might see a negative net benefit.
By doing your analysis, though, you will have identified all potential benefits and risks associated with the migration, and thus are able to accurately inform all stakeholders of factors that might either confirm or challenge their initial impressions.
The result: All stakeholders are heard and their perceptions accounted for, but none get to control the outcome without merit.
Review
Remember the following points for successful stakeholder analysis:
- Identify all stakeholders for both your entire program and your individual workloads;
- Understand the concerns and drivers of your various stakeholder types;
- Calibrate your stakeholders’ levels of interest and influence in order to best decide how to monitor and/or manage their concerns.
Finally, this blog is really trying to guide you in who to communicate to, how to communicate with them and when to communicate. If I can leave you with one message it is that communication is key to your success. The more information you can impart, the more confident your stakeholders will be in the success of the project. Tell them:
- Why the project is important;
- How the project will run;
- The benefits for them and their department;
- The benefits for the organization as a whole.
When you’ve finished telling them, start over and tell them again. Communicate, communicate, communicate.
Hopefully this series of articles has provided you with some insight into how to run your migration program with some snippets of information that you can take away and use. If you missed the earlier parts of this series, you can find part one here, part two here, and part three here. Also, check out our list of blogs on workload migration.
Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.
