Disruptions are all around us. First, the various disruptions with Covid on all aspects of people’s lives around the globe. Now we have the riots across the US as well as other countries about racial inequality. With these, we have the backdrop of constant technology changes that constantly challenge how we run our lives. What next you may ask?
Disruptions to how change initiatives are managed seem to never cease. You think you’ve been through the worst with Covid impacting the budget expenditure on projects and the implementation timeline thrown up in the air due to lack of business capacity. The racial riots are disruption normal business operations and it is back to business continuity plans for some organisations. How might we continue to manage our various change initiatives amongst these constant disruptions?
Strategic approaches
In being able to effectively respond to constant business disruptions on initiatives a set of routines and practices need to take place prior to the individual disruptions.
Use the three horizons of growth as a framework to focus efforts on initiatives
A brief description of the Mckinsey 3 horizons model
McKinsey’s three horizons of growth describe 3 horizons of which initiatives should be clustered. Each horizon forms a critical set of initiatives from which the organisation may continue to develop and grow. If all focus was placed on horizon 1 that are focused on the here and now shorter-term initiatives, then the organisation is not placed to deal with emerging challenges addressed under horizons 2 and 3. Vice versa if all the effort is placed on horizon 3 and not 1.
With business disruptions, the effort and expenditure placed on initiatives can be evaluated in light of which horizon they are in. For example, if the Covid disruption is so significant on the business that it’s a matter of survival, then all efforts should focus on horizon 1 initiatives that contribute to organisational survival in terms of revenue and cost management. If the disruption is significant but not debilitating then it may be wise to spend half of the effort on horizon 1 with the rest on horizons 2 and 3.
Adopt a portfolio approach to manage changes
When initiatives are treated in isolation it is very difficult to flex and adjust to changes compared to a portfolio approach to manage change initiatives. Individual initiatives have limited resource capacity and project activities will have limited impact compared to multiple initiatives.
Having a portfolio approach to manage changes means having established the following:
Data-based approach to manage change impacts with a view of change impacts across initiatives
Ability to visualize and plan the change impacts from a business-unit-centric and stakeholder group centric perspective
Ability to manage resourcing across initiatives so that as required resources may be flexed up or down across the overall portfolio based on prioritisation
Ability to guide and prepare each business for multiple changes across initiatives
Key stakeholder messages may be synchronised and packaged across initiatives versus an initiative by initiative approach
Improved ability to map out clearly the various skills and capabilities being implemented across initiatives to avoid duplication and improve synergies
What can change practitioners contribute in planning for disruptions?
Derive different change scenarios
Scenario planning as a technique is rarely used in a project planning context. However, it is especially critical and relevant within an agile environment. Agile project practices mean that changes keep iterating and therefore it may be hard to anticipate what the end solution or changes will look like. It may also be hard to anticipate how the business will respond to the changes being proposed if we don’t know what the changes will look like.
To allow adequate time to plan for changes it is very helpful to derive at least 2 scenarios. In an agile environment, change practitioners need to adopt a hypothesis-based approach to deriving change approaches. Let’s take an example of a standard system implementation project. In rolling out a new system these could be 2 likely scenarios based on the hypothesis being posed.
Hypothesis: The system being implemented is easy and intuitive for users and therefore the change approach will be sufficient with awareness raising and a 1 hour training session
Scenario 1: The hypothesis is true and all users have found it easy and intuitive to use and therefore the change approach proposed is sufficient to prepare the users for this change.
Scenario 2: The hypothesis is only partially true and there are some user groups who struggled to understand all features of the system and need additional help and guidance. Additional training sessions with coaches are proposed
A different way of contrasting different scenarios will be to derive different project expenditures and funding requirements and resulting change delivery work. For example, under the system implementation project, a ‘Toyota’ approach of delivery could involve minimum training and stakeholder awareness generation. For a ‘Rolls Royce’ approach of delivery which will cost significantly more could include tailored coaching sessions for each stakeholder group, 1:1 coaching for senior leaders, a long awareness campaign, and an extensive measurement system. This helps stakeholders understand the cost of delivery and will help them to select an appropriate delivery model.
The usefulness of planning ahead to anticipate for different scenarios mean that steps may be taken to be ready for either of the scenarios and so the project team will not be caught off guard in case the hypothesis proposed is proved false.
To be able to visualize different scenarios it is important to show the different impacts of the scenarios. This includes the impact of time, sequencing, and impact levels on stakeholder groups. With a different rollout approach will stakeholder groups have better bandwidth and ability to adopt the change or will the bandwidth be more limited?
Here is an example of a scenario planning visual where the user can simply drag the impact bars to different times and be able to save this as a scenario. After saving the scenario the next activity will be to analyse the scenario to make sense of the potential impacts of this scenario on the business and impacted stakeholders. Are there project dependencies that need to be taken into consideration? What is the overall change impact across initiatives as a result of the changes in this scenario? How does this impact the customer versus internal stakeholder groups?
A scenario planning example from The Change Compass
For scenarios to be used in a practical way it is important to be able to list any ‘proof points’ that outline how we can tell that the scenario is becoming true or not. These proof points can include anything ranging from stakeholder reactions, the timing of the implementation, the complexity of the features or solution, cost, and other tangible measurements such as system response time, time taken to perform the process, etc.
Agree on decision making principle with stakeholder
Prior to any disruptions, it is important to agree with stakeholders key decision-making principles. Having clear, agreed decision-making principles means that key decisions can be made without subjecting to personal opinions or preferences. During any times of disruption Decision-making principles can be organised as ‘trade-off’ principles with a prioritised order of importance. Below are some examples:
Cost
Time
People resource bandwidth
Benefit realisation
Stakeholder readiness and acceptance
External media implications
Factor in critical path in project planning
The critical path method is a way in which a project’s key interdependencies are linked and mapped out in a linear way so as to understand the key logical points along the project. From this any potential disruptions, slippages or delays in project deliverables and how they impact the remaining deliverables can be clearly understood and planned for.
A clear understanding of the critical path within a project means that with any disruptions to activities the impacts of this on the rest of the deliverables can easily be articulated. To deal with the disruptions to the project a longer implementation may need to be negotiated with the impacted businesses, or depending on the nature of the disruption, a different project approach with different deliverables may need to be derived.
An example of critical path planning
Here we discussed multiple ways in which the change practitioner can help the organisation get ready for various disruptions to change initiatives. During periods of disruptive change, it is even more critical for change practitioners to demonstrate their value to lead and maneuver around and plan for uncertainty. Agile organisations are well placed to deal with disruptions, however, an effective set of routines, practices, preparations, and capabilities are all critical to building overall organisational readiness.
Agile is becoming a common standard for project implementation. Most organizations are implementing some form of agile methodology in how they manage initiatives, anywhere from the waterfall project methodology on one extreme end through to the pure agile project methodology on the other end. Yes, we know that agile may not be for every organization. Projects where the output of the change is known clearly upfront and where requirements won’t change much throughout the project may not benefit from an agile approach. On the other hand, those projects where the end design is not known, where innovation would be valued, would definitely benefit from an agile approach.
There are plenty of resources available for project managers on the mechanics of agile methodology. However, the same cannot be said for change managers. Many even commented that the role of change management has ‘disappeared’ within the agile approach. There are lots of examples of projects where there are significant change impacts on employees and customers, where there is no change manager on the project.
What is the role of change managers in an agile project? How will change work be modified to suit agile methodology? How does the change manager create value in an agile environment?
This guide aims to answer these questions and provide a simple and practical guide to aid the work of change managers in an agile environment. While the guide will not aim to cover anything and everything to do with agile, it will aim to call out aspects the change manager needs to consider in carrying out change work in an agile environment.
The basics of agile change – the Agile Manifesto principles
When the agile ‘godfathers’ got together to come up with agile change principles all those years ago, they were quite certain that they wanted to focus more on principles than ‘methodology’ per se. Since then the intent may have changed in how organizations have adopted this. Nevertheless, it is important to visit the core of what agile stands for.
12 Principles of Agile Manifesto
These are the 12 principles of the Agile Manifesto (from agilemanifesto.org)
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Here are some key takeaways that the change manager should note about the agile manifesto, the core of what agile is trying to achieve:
Iterative change
Iterative change is more effective than big bang change. This is because it reduces the risk of failure and increases the chances of success. This is also how designers work – making incremental changes to ultimately come up with the right outcome. This is because with these techniques the project team is getting feedback throughout the process. Therefore, the ‘test and learn’ and prototypes in design thinking are critical as a part of an agile approach. The emphasis on constant change is the core of agile.
Multi-disciplinary team
The power of the smallish and multi-disciplinary team. Business, technical and specialists from other disciplines are encouraged to work together to come up with innovative solutions to address the problem. Each discipline may approach the same problem differently, and therefore when we put people with different approaches together we start to get innovative ideas. Smallish teams also tend to perform better in getting traction and delivering without getting bogged down by hierarchy. Most agile experts agree that the right size for agile teams would be 6-7 people.
Early and continuous engagement
Another part of what is essential to agile is designing early and continuous engagement. Business representatives are included in the project from the beginning and continue to have strong involvement throughout the process. This is particularly important as the solution being developed by the project team continues to evolve and change throughout a short period of time.
Key agile methodology terms and approaches
There are two main agile approaches that are popular in project management, scrum and kanban. A lot of organizations also use a combination of both scrum and Kanban. Let’s go through these to get a better understanding of what they are and how change fits into these methodologies.
Scrum
Scrum is probably the most popular agile methodology used by project teams that are implementing agile. It starts with feedback or input from end-users or customers on what the need is and the business requirements. These are then captured, analysed and defined into clear features. They can also be in the form of ‘user stories’ that outline what the user goes through in the entire process. User stories are simple descriptions of a feature told from the perspective of the person who desires the capability. User stories are usually captured in post-it notes on a board (or digitally) to allow visualization of the journey/process.
The project team then goes through a series of ‘sprints’ where iterative work outputs are created under each sprint. Each sprint is aimed to produce a discrete piece of work output that is tangible and can be used or tested in some form. Each sprint goes for 1-4 weeks and is managed by the scrum master who’s role is to do anything that optimises the team’s performance. This is not a manager role who is tasked to ‘approve’ or ‘sign off’ on the work of the team, but more of an enabler and facilitator. In an agile team, the team is self-managed and empowered to come up with unique ideas to form the ultimate solution to address the user/customer needs.
So what is the role of the change manager in scrum? The role of a change manager does not really change significantly in an agile setting. Yes, the change manager needs to understand the why and how an agile team works. However, the fundamentals of the value of change management stay the same. If a project is creating change impacts on the user or the customer, then this is where the change manager steps in. This is not dissimilar to other non-agile project settings.
Let’s dissect the work of the change manager to better understand his/her role in a greater level of detail:
Initial scoping
When we have a high level of understanding of what the project is and what it is trying to accomplish, the change manager would help to scope and size the amount of change impact in concern, the level of complexity involved, and come up with a high level estimation of how much change management support would be needed on this project. This does not change in an agile project, compared to waterfall projects.
High-level change approach
After the features have been identified and the product owner has a clear idea of what the change is and what it involves then it is time to start on devising the high-level change approach. At this stage, we still do not know exactly what the solution is, though we have a few likely options to consider. By taking a few assumptions we can devise a high-level view of what change approach would work. A key part of this approach would involve understanding which stakeholders will be impacted.
Agile projects are focused on producing output and solutions and there is significantly less focus on documentation. However, this is not to say that documentation is not required. Instead, documentation tends to be more summarised and slimmed down versus the significant longer documentation required under waterfall methodology. In this phase, the two key documents are the high-level change approach and high-level change impact assessment document. Some even use a ‘change on a page’ similar to a ‘plan on a page’. The high-level change impact assessment could also be a one-pager that calls out key stakeholder groups impacted and the nature of the impacts.
Design and planning phase
When we get to the design and planning phase of the project the key focus starts to shift into a detailed articulation of what the change is. In this phase, the approach in change work is again no different than under waterfall. However, the difference is that there may be more unknowns as the solution is being developed and shaped iteratively and continues to evolve over each iteration or sprint.
The change manager needs to determine when there is sufficient information to start work on the detailed change impact assessment. And this impact assessment will undoubtedly need to be reviewed and potentially updated as the solution changes. Other key deliverables such as stakeholder matrix, engagement, and communication plan, change plan (including measurement) and risk assessment should also be captured, depending on the level of change complexity.
The role of the change manager is to partner closely with the team to flesh out and define what the change is and what the change approach is throughout each sprint. Some may call out that this may sound quite messy since with each iteration the change approach could change. In practice, a lot of the impacts and change approach are fleshed out and captured before or during the sprint planning. With each scrum and iteration, the solution becomes more and more defined, and only tweaking would be needed on the change approach.
Early and continuous engagement is a key agile principle and therefore the change manager has a critical role to play in engaging the various stakeholder groups. Depending on the nature of the change, business and stakeholder engagement may need to occur prior and during each iteration. For example, business stakeholders may need to engaged on what the new system is, and how/what it will do for them, and how they will be impacted. Then, when we are closer to having developed a full solution with system screens being defined, we can show our frontline employees what the system looks like. Throughout the iteration process, subject matter experts and business representations, and even change champions groups have critical roles to play in providing valuable business feedback.
Another key agile principle is focused on getting end-user or end customer feedback early, and continuously throughout the development process. The change manager needs to work with the business to carefully the right end-users to provide feedback (versus managers who may not know the intimate details of business requirements). The change manager also needs to balance the needs of the business by being engaged in the what/why/how of the change early on, and incorporating more details of the solution throughout the iterative process.
Implementation and post-implementation
Since agile produces change at a faster pace than waterfall approaches, there are a few things that the change manager needs to adapt to. One of the key challenges for the change manager within an agile team is not to lose sight of the fundamentals of managing change. Within the series of iterations, keeping the business engaged and involved is key. On top of this, understanding and agreeing with the business on the most optimal go-live and implementation period would be critical. Just because the change is ready technically, it does not mean this is the right time for the business to accept the change. On the other hand, there could be complexity or technical challenges that delay the anticipated go-live (like most projects, in any methodology). This needs to be managed effectively and there needs to be clear identification of the next ‘window for change’ from the business perspective from the perspective of the business having the capacity to digest the change.
Some propose that the change manager should ‘adopt’ an agile way of implementing ‘test and learn’ in implementing change. Whilst this is valid there are a few considerations. Implementing agile does not mean that how our employees respond to change will suddenly change. From previous experiences in implementing changes, the change manager should leverage what has or has not worked and not start from zero. For example, how was the reception from a particular business unit to online learning of new products? What has worked well in terms of how this group was engaged previously? If there is little experience in change within a particular part of the organization, then it makes sense to conduct pilots to test. However, again, leverage from previous experiences where possible before starting ‘new’ tests.
Post-implementation and benefit realisation are still applicable from the perspective of the change manager. Planning for effective embedment and measurement of change and that the benefits are realized through the users adopting the right behaviours are still valid under agile.
Kanban is a simple agile methodology that was developed from a manufacturing background (i.e. Toyota). It is not time-based, unlike Scrum. Instead, it is based on ordering a set of prioritised activities through the funnel of ‘To do’, ‘Doing’ through to ‘Done’. The list of activities is prioritised meaning that after one task is completed and moved to ‘Done’ the next activity on the list may be undertaken. This overall list of activities can be seen as a ‘backlog’ where a set of activities have been determined to be necessary to complete the project.
This kanban board needs to be real time and constantly updated so that the team members can easily visualize the progress they are making and how much work is outstanding. This is a great way of understanding the pace of execution and output achieved. The cycle time of measuring how long it takes tasks to move from ‘To Do’ to ‘Done’ helps to forecast the delivery of future work. The kanban board acts as the single source of truth for the agile team.
All of the previous comments regarding scrum and implications on the work of the change manager apply to kanban as well. The change manager, working alongside other agile team members, would also need to adapt to the faster pace of change, and work within the team to identify any obstacles to the overall workflow. Change management work activities would also contribute to the overall kanban board and flow through this process.
Building the change environment for agile
There are significant opportunities for the change manager to add value in creating the right change environment for agile initiatives to land successfully. Some of these include:
Helping business leaders, including sponsors and business owners to understand their role in leading change within an agile setting
Support the design and dynamics of the agile team to really flourish, generate innovative ideas, and to leverage the diversity of thought
Work with business stakeholders to prepare them for iterative agile changes where the end state is not always clear from the beginning. The challenge of crafting a clear vision of change without the necessary details
Helping to build the overall culture of the organization by adopting agile principles, is itself a separate cultural change exercise. For organizations that are risk-averse, the challenge may be to instill the value of ‘safe to fail’
The ultimate dilemma for the change manager
One of the ultimate challenges of preparing the organization for an agile environment is to understand the environment itself. When there are numerous agile projects going on in organizations, each with continuous iterative change, there lies the challenge. How does the business get visibility of all of these chunk-sized changes and be able to prepare for them collectively? Without a clear oversight of a collection of changes that are constantly moving it is almost impossible to effectively lead and embed changes effectively.
For more articles on agile change management visit our Knowledge Centre.
Are you ready to leverage digital change management platform to support your agile project? Check out Change Automator to streamline, automate, and improve the outcomes of your change work. To book a demo, click here.
