Craigenreoch © Al Lee-Bourke
Overview
As an adoption and change management practicioner, my primary role in the current ‘move to cloud’ project is to focus on adoption and change management. This report outlines my core responsibilities in this capacity and explains why engaging too deeply in the technical aspects of the project can be a distraction from my main objectives. It is vital to balance being closely aligned with the technical project regarding timelines and products while ensuring that the technical and change management aspects are integrated effectively.
Core Role in Adoption and Change Management
Adoption and change management involves facilitating the smooth transition of the organization and its employees as they adopt new technologies, processes, or behaviors. In the context of the ‘move to cloud’ project, my core responsibilities include:
Identifying the potential impacts of the technical project on the organization and its stakeholders.
Developing and executing a comprehensive change management strategy to address these impacts.
Ensuring users are trained and prepared to use the new cloud-based applications effectively.
Monitoring and measuring the success of the change management efforts, focusing on user adoption and satisfaction.
Supporting the organization in addressing any resistance or challenges that may arise during the transition.
Continuously improving the change management process based on feedback and lessons learned.
Distractions from Technical Project Involvement
While it is essential to maintain close alignment with the technical project, becoming too involved in tasks such as daily stand-ups, creating OKRs, technical project management, and educating the organization on agile methodologies can distract from my core responsibilities. Specifically, it can lead to the following:
Dilution of focus on change management and adoption efforts.
Inefficient allocation of resources and expertise.
Potential delays in identifying and addressing change management challenges.
Importance of Integration between Change Management and the Technical Project
For a successful project outcome, it is crucial to recognize the interdependence between change management and the technical project. Both aspects must engage with each other to ensure:
Timely communication of project updates, milestones, and potential risks.
Inclusion of change management considerations during the planning and execution phases of the technical project.
Coordination of training and support activities to align with the project timeline.
Collaboration in identifying and addressing any challenges that may arise during the transition.
Recommendations
To optimize the success of the ‘move to cloud’ project, it is vital to maintain the focus on adoption and change management while ensuring effective integration with the technical project. I recommend the following actions:
Clearly define roles and responsibilities within the project team to avoid overlap and maintain focus on core competencies.
Establish regular communication channels between the change management and technical project teams to facilitate information sharing and collaboration.
Encourage the technical project team to consider change management implications throughout the project lifecycle.
Evaluate and adjust the balance between change management and technical project involvement as needed to ensure the successful realization of the project’s opportunities.
Making it real
Here’s a straightforward way to make this work.
Stage 1: I will kick off this process by building the backlog in stage 1.
Stage 2: I’ll dive into sprint planning and find adoption scenarios and personas for each sprint.
In stage 3: I’m taking things to the next level with sprint planning for change management. This means creating action plans to tackle topics like executive leadership, manager coaching/change network, communications, training, resistance management, rewards and recognition, and adoption measurement. And every day, we’ll start with the stand-up (Scrum) meeting, led by the Scrum Master, where we’ll organize our work for the day.
Stage 4: This is about reviewing the backlog with the Product Owner and Agile team, prioritizing user stories and work for future sprints, and getting those user stories ready for the next sprint planning with input from the change management team on workforce analysis.
In stage 5: Here, I’ll create adoption scenarios by prioritizing and grouping user stories and taking part in scenario/persona workshops with key end-users and stakeholders.
Stage 6. At the end of the sprint, it’s time for the sprint review, where we’ll present the completed work to the Product Owner, stakeholders, and customers. The team should try to create a product ready to be shipped.
Stage 7. Now I’ll present the sprint adoption campaign to the same group.
Stage 8: Then, I’ll reflect on the sprint with the entire team and find one or two processes or interactions to improve in the next sprint.
Stage 9: Next, I assess the adoption and business outcomes, supplying feedback on improving or accelerating adoption for the next sprint.
In stage 10: Launch the selected adoption scenarios and apply the change management action plans to speed up end-user adoption and build confidence in the new way of working.
Stage 11: Creating adoption scenarios and personas by prioritizing and grouping user stories and participating in scenario/persona workshops with key end-users and stakeholders.
Stage 12: Here, I’ll be helping the change management team find sponsors, managers, change agents, and affected groups and setting up a strategy for executing the change management action plans. I’ll be lending a hand in creating the necessary templates, getting the sponsors and change network set up, figuring out how to communicate and train the troops, and deciding on the delivery options. I’ll also hammer out a measurement approach for the benefits dependency network, 4Ps, KPIs, OKRs, and other metrics and give the nod to the instrumentation for adoption monitoring.
© Al Lee-Bourke al@554north.scot
Comments