Core tenet: All leadership aligned in building change capability from the start
Why this is important
To build change capability all leadership must understand and be committed to investing in the capability. This means that people will be taken out of the day-to-day business to lead and participate in the change effort. This requires an agreement across the whole organisation that the activity is critical to achieving strategic plans.
How we did it
By working with the leadership to help them gain an understanding of the scale of change that was in the programme, and the impact it would have on operational teams, we built the vision and plans for how to build the change capability that the business would need.
Building agile change as a capability
The approach then followed five principles that are described in our blog post “Building change capability”.
This is how we enacted them on this programme:
Building agile change capability: Coaching and learning through doing
Having communications and training that immediately feels relevant to front line staff is one of the success factors of any change programme. While it often gets left to last and must be fitted in between technology driven deadlines, it has to be built from the perspective of the ultimate recipient. Embedding the impact assessment and training into the programme and involving recipients in the development mean we deliver interventions that are more impactful.
Before each release of the programme a detailed change impact assessment was conducted. This was done by the business analysts on the programme and then worked through with training teams, knowledge managers and the operational teams themselves. This ensured that not only did all teams get a truly clear assessment of what they would have to do for each release, that understanding was fully embedded in any communication and training that was delivered.
Ensuring local and operational ownership: Building the vision and outcomes
The programme was business driven from the start. Leaders from the commercial and operational parts of the business worked to define the outcomes expected from the project, and thus owned the achievement of these outcomes.
At the start of the project, we set up a Business Change forum, focussing on the main decisions that the business would need to take to achieve the desired outcomes. We ran these as key design decisions that the business teams would need to answer before any technical design could begin. This set the business teams at the heart of the programme and ensured that they felt ownership over the vision and direction.
Delivering change in incremental steps – Involvement in shaping the change
The people who are going to be operating the new ways of working must feel that they have had a say in when and how the programme is delivered. Much as in any programme we design for the customer outcomes, we also need to ensure that we are designing for the operational outcomes.
Each of the releases of the technology was designed from a business perspective, with functionality logically grouped together and planned so that a meaningful and relevant set of technology is deployed at the same time, and everything that operations need to run it is included in the release. This then shapes the backlog and priority of the development activities, which along with the customer view and the technology priorities are shaped together to form the programme delivery.
The recipients of change have decided and shaped how their future will be deployed and therefore are deeply committed to ensuring it is a success.
Local teams integrated into all stages of the programme – Involvement in shaping the design
Any programme consists of changes to systems, processes, roles and behaviours. The challenge to make a successful change increases in this order, with changing systems being the easiest and changing behaviours the hardest.
The principle underpinning successful acceptance of change is that if you have been involved in the design (along with testing and deploying) it is very hard to claim this is not what you want. So, ensuring that level of involvement and transparency, so that operational teams and leaders can see their involvement, adds effort to the development of the programme but smooths implementation and adoption when that support is really needed.
To be involved at the level needed to make a meaningful contribution to a change, requires time and effort. Operational organisations do not have a level of capacity that allows this to be done with their existing staff base.
Therefore, from the start of the programme we worked with the operational leaders to plan out what additional resource they would need to support those design, testing and implementation efforts and helped them build the case for bringing in additional staff to back fill the key resources who would be involved in the programme.
This also involved people stepping up inside the organisation to take on more senior roles while those team leaders were part of the programme. Building up this change capacity early in the life of the programme was probably the most important change intervention completed.
Capability is continuously reviewed and improved: Involvement in sustaining and embedding the change
90% of the effort to make a change work for the recipients, comes after the implementation. To make this successful, all the elements discussed previously have to be in place, along with a comprehensive plan of how the change will embed itself into the operating fabric of the organisation.
People from operations were involved as subject matter experts (SMEs) in the design, writing and executing tests to ensure processes were manageable and building in continuous improvement into the programme process. We built an allowance for updates based on experience of people using the processes into the programme schedule, so changes based on early use could be efficiently implemented.
People who had been testers and SMEs were used to coaching and guiding people during the programme and continued these roles once we had gone live.
All these elements built the practice of embedding the change and continuously improving it into operations, so it continued seamlessly once the programme had closed.