In this second article in the series on sustainable change, I’ll show how I’ve used a kanban-based approach to manage change initiatives. This resulted in a continuous flow of improvements that were absorbed by the organization, leading to lasting results.
The possibilities in organizations to absorb changes are limited. Overloading people with change is counterproductive, there will be resistance. When managing change my suggestion is to figure out how much change an organization can handle and manage accordingly. This helps you to guide and safeguard the required changes and makes it possible to have a lasting result.
In the first article on sustainable change, I explored how we can catch signals of overload during change. When we recognize that the organization is getting overwhelmed by change, we can take action to prevent overload.
Change with Kanban
Changing is not something you do one time. Organizations are constantly changing. Then it actually makes sense to choose an approach that supports continuous change and improvement, such as kanban.
A kanban-based approach makes it possible to:
- make change visible and transparent.
- control the number of change initiatives that an organization carries out at the same time
- prevent overloading organizations with change
- do bottom-up change using a pull approach
- optimize the entire chain with a change
With a kanban approach you can limit the number of change initiatives that an organization is working on (Work in Progress). If a new change initiative is needed, another must be finished or stopped. This way you prevent that too much is happening at the same time, which overloads people and leads to failing changes.
Another advantage of a kanban-based approach is that you start change initiatives based on real needs. Instead of using a “push” approach, implementing change top down, you use a “pull” approach to pick and support changes by teams and departments.
I experimented with one of my clients to see how many change they can handle using a kanban-based approach. The changes themselves were small enough and mostly well-arranged, but due to the complexity of the organization, the lead time was on average around 6 months per change initiative. Doing everything in succession would take too long, all changes at once was too much to handle. We needed something to manage the change processes to prevent overloading the organization.
The IT department of a government agency that hired me wanted to make their quality assurance and process support activities more effective. To do that, multiple changes were needed. The organization had previously done a CMMI assessment and was starting a large number of change projects based on the findings. Some of the projects took off, but there were also improvement projects that proved to be more difficult and were not making progress.
With a bottom-up change approach, I started working with the quality and process managers. To keep the amount of change manageable, I ensured that a maximum of four mini-change projects were running at the same time (limited WIP!) with changes that could be implemented relatively independent of each other. Before a new mini-change project could be started, an ongoing mini-change initiative had to be finished to prevent people working on too many things at the same time. In one case, one change was temporarily parked to make room for another change with a higher priority. It was also possible to stop a change, for example if it became clear that it no longer has any added value.
Every month everyone involved in the change initiatives met. The status of the changes was discussed, looking at how many months (iterations) are still needed to complete the change. The employees also presented their experiences, shared good practices and learnings, and jointly evaluated how the changes were progressing.
Kanban looks (just like Lean) at the entire chain and the cooperation between the parties involved. With software development, the chain starts with the needs of the customers. It ends when products and services are delivered. With a kanban approach you optimize the collaboration between all participants in the delivery chain.
The changes at the IT department are improvements in their way of working. Based on interviews, I mapped out the need for change together with the stakeholders and defined the improvements.
The changes that have been made had to do with better cooperation, more insight into the quality of software products, more effective management of projects, achieving KPIs, and better application of processes. These changes also resulted in knowledge sharing, coordination of processes, and lowering of overhead.
Not too many changes at the same time
As indicated earlier, I have limited the number of changes that were carried out simultaneously to four mini-projects. Why four? On the one hand, I was guided by the project triangle: Quality, time and money. You can have a maximum of two fixed for a project, so that you can influence the third one. In a large change project we preferably have only one goal: Faster, or cheaper, or better, not a combination. So then for the number of changes that an organization can handle at the same time, you end up with one, or maybe two if things go well.
When I look at teams, then seven (+/- 2) is the magic number that is often mentioned for the number of people in a team. Seven changes at the same time, however, felt much too much to me. That is why I experimented with four as a Work in Progress (WIP) limit, halfway between one and seven. And that worked well for the IT department of the government agency, we met once a month and discussed progress with the stakeholders where four ongoing change initiatives felt to be a good fit.
Four change initiatives in parallel seems a lot, but it was true that these changes are not all at the same stage. Some have just started, others are in full swing, and others were almost finished. Also, not all stakeholders were involved in all initiatives. The organization could handle the four changes. More changes at the same time would have been too much, by doing four change happened at a stable pace.
Monitoring coherence was an important reason to keep track of the changes and to discuss them on a monthly basis. It also encouraged cross-fertilization between improvements.
I do not want to suggest that this is exact science. More important than the number four is to ensure that there is an overview of the current and planned changes. That change managers and the stakeholders know how they contribute to the operating result. And thereby indicate priorities.
At the same time, with the kanban approach, you also have a tool to keep you busy with a change. If a change does not work, if it does not bring benefits, if the organization is not ready, stop it. And grab another change that is possible and useful. That way you keep improving!
How much change can your company handle?