Here you can find a few case studies describing 5 main change management obstacles I’ve experienced. I believe that getting familiar with those common difficulties and simple solutions will help you not to reinvent the wheel at your daily work. There are two things that I’ve learned from physics classes: the speed formula and the real meaning of Heraclitus maxim. Before the high school, I thought that “You could not step twice into the same river” means you can't make the same mistake twice, as obviously you are already familiar with its consequences. I was really surprised that it wasn’t the crux of the matter. However, it was only when I’ve started my first job in IT I realized what constant change really means. On one hand, I had a unique opportunity to have an insiders look at the company which has grown from 30 to 150 employees. But what is more, I was responsible for introducing and executing innovations on many levels.
I failed some, and succeeded a lot. Now, that I’ve done my homework, I am ready to share my experience with you.
The good, the bad and the ugly
Considering the value of improvement and its actual stage of implementation, there are at least two types of changes, the good (lean) and the bad (regressive) one. And if you can’t discriminate between them, it can get really ugly. Antiprogressive changes usually end up creating serious waste. They sap precious time and deplete your team's motivation and trust. Furthermore, they hinder everybody's efficiency, which in consequence make the organization lose out on potential opportunities. Finally - all the above costs money. Therefore, to ensure that planned changes are lean in nature and beneficial to the organization, make sure to differentiate between "good" and "bad" change characteristics:
GOOD (LEAN) CHANGE
- supports company/team/personal strategy
- increases efficiency
- fulfils gaps
- is an answer to the team’s needs
- is a reaction to external/internal impulses
- the one that really works
BAD (REGRESSIVE) CHANGE
- is a change for its own sake
- decreases efficiency
- is an overkill
- is forced
- is delayed
- the one that doesn’t actually work
Źródło: Agnieszka Amborska-Bogdziewicz, 2017
In order to do that, you can simply answer a few questions:
- Which goal does the change support? Is the change aligned with our strategy?
- What kind of effect do I expect?
- Which gaps can be covered with the new process?
- What exactly does my team need? / What kind of feedback have I collected so far?
- Can we take advantage of some external/internal opportunities? If yes - how?
- How will I make it work in practice?
These open questions will help you deeply analyse both the situation and the solution. What’s more, thanks to case studies described below, you will be able to avoid common “technical” mistakes.
Case 1: Lack of a designated Process Owner
Do you know anyone who doesn’t like smoothies? I can’t imagine a person who would refuse this fresh, fruity, colourful beverage. We even had the idea of a smoothie jar at Bee Talents. The concept was simple, everyone puts some money into the jar so we could all enjoy a tasty drink during the day. Unfortunately, the improvement petered away. Why? There was no Process Owner (PO) who would:
- remind us about the jar (new process),
- set clear rules of collecting money (motivation and awareness),
- work to ensure wide buy-in (motivation),
- propose the way of making smoothies and cleaning all stuff after all (assigned roles and responsibilities).
I’m not a process-freak so I don’t claim that such a simple idea as the smoothie jar should be established as a new process. What I want to show you is that even though a perspective of a tasty prize was tempting, the whole team was so absorbed with daily tasks that we have simply forgotten about a new change! If we were able to ignore the new process despite its simplicity and associated advantages, just imagine how hard it may sometimes be to execute more complicated change without obvious and immediate benefits.
Quick win:Make sure that there is always one person who is actually responsible for implementation of a change. Process Owner should not only design and present the idea but also train the team, collect feedback and make sure that further improvements are introduced. PO can get help from change advocates, people who promote and support change and champion their efforts toward making things happen. However, she/he can’t be replaced with them as her/his responsibilities are much wider.
Case 2: Change in people
The truth is that one can’t incorporate innovation without people. It’s super easy to bring new ideas, describe and publish new processes. The biggest challenge is to adapt the team to change. Every time I start consulting cooperation with a new client, I’m a bit stressed. Even though transforming a company is not my goal, many people take my appearance as a forerunner of changes. For most of us, deviations from status quo are stressful - they take us away from our comfort zone. This feeling can be especially strong at the early stages of change implementation. At some point, we may feel frustrated or even burned out, however, open-minded PO should be able to deal with that.
Quick win:The Kubler-Ross Change Curve can be very useful in understanding various stages of dealing with new reality.
Zanim zaproponujesz innowację, upewnij się, że spełnia ona potrzeby Twojego zespołu.
- Before you suggest an innovation, make sure it meets your team needs:
- What are their main challenges now?
- Why does the current process look like this?
- What kind of improvements were tested in the past?
Don’t propose huge changes. It’s much easier to accept a small adjustment (quick win) rather than a complete overhaul. Be patient and try to understand people's emotions. As a PO you feel most comfortable with a change, you are the one who understands best the reasons behind it. Others will need your help to adopt change on working and emotional level.
Case 3: Too many changes at the same time
When I’ve become a PM Team Leader, our team had many brilliant ideas - and a lot of motivation to implement it. Only after a few months, we’ve realised that there are too many modifications and a lot of obstacles we haven’t been previously aware of… We didn’t have enough time for either being good POs (hopefully after reading the last two paragraphs, you are able to characterize a good PO:)), or to adjust our work to new standards.
What is more, we were exhausted with continuous improvements. Just imagine yourself continuously learning new processes. Last but not least, we had no idea what is most important to incorporate so we could boost our efficiency. We got lost in a steady and at the same time chaotic stream of changes, which is a slippery slope to miss out on really good ideas. Define areas which require improvements most urgently, then design adequate innovations. Lean change should be an answer to an existing need or gap, it shouldn’t be implemented only for its own sake. If you are not able to limit the number of changes, track them all. You can use simple doc or a tool that I’ll introduce in the 5th case study.
Case 4: Poor training
When I talk to my clients about their improvements that failed, I ask them to describe the whole implementation process in details. There are three patterns that I’ve observed most frequently and they are usually present in two phases - process introduction and maintenance.
- Wishful thinking (implementation phase).“I’ve arranged the meeting, introduced my idea thus now I expect that everyone will follow it”. In other words “I’ve done my best to make sure that the idea will survive”. However, as we’ve already learned from the Change Curve, an introduction is just a top of the iceberg.
- Evolving needs (maintenance phase). Usually POs rest on their laurels once they introduce an idea but in fact, this is just a first version of a solution, and your change design should come in improved iterations.. One of the overlooked advantages of it is that initial version exposes deeper gaps and team needs. By digging deeper team can create a truly customised process.
- Knowledge sharing (maintenance phase). If we want to create a long-lasting team habit, we have to take into consideration not only current but also the future team. How can we make sure that our idea will be spread across the whole organisation now and in the future?
Change Curve is a good answer for POs wishful thinking. If we want to quickly react to evolving needs, we will need a solid feedback loop that I will describe in the next paragraph. Therefore let’s focus now on the last challenge - knowledge sharing. These are the few steps easily allowing for efficient training.
- Describe and publish your solution. Once the team agrees to step into a new process, describe it (steps, roles, responsibilities) and make it available in a document collaboration tool that is most commonly used in your company.
- Take care of newbies! Define roles that are involved in the new process and make sure that proper onboarding guidelines/documents are updated.
- Refreshing workshops are a good opportunity to remind a process, onboard new colleagues, and collect feedback from the team.
Case 5: “If change is hard, make it continuous” - Claudio Perrone<
A few years ago I had a unique opportunity to help to introduce Jira (issue tracking tool) to a big organisation (> 100 employees, ~ 40 projects). After initial research, we realised that there are few serious risks:
- the tool gives us enormous customisation options but it’s quite complicated to kick off and learn,
- such change has a high impact on every single project and we have to make sure that clients will sense that only in a positive way,
- although we had a unified development process, it appeared that requirements for the tool vary depending on project teams,
- last but not least - most of the team didn’t find the change necessary.
Considering all those risks we’ve designed the plan:
- make a list of low-risk projects,
- look for a few project teams (low-risk projects) that are eager to test a tool,
- collect their requirements,
- design a project flow based on team feedback,
- share the plan with the whole team,
- start testing our solution basing on bi-weekly sprints (version 1 -> feedback & update for the whole team -> version 2 -> feedback & update for the whole->...-> version X),
- implement version X of the flow project by project (starting with low-risk projects).
As you can see, the main idea behind our plan was to split a huge change into smaller ones so we could easily manage risks and team concerns. What else could go wrong if we didn’t decide to make our change continuous?
- The bigger the solution is, the harder it is to accept by the team,
- Big change means delayed results thus PO can’t react quickly.
- Huge modifications are expensive, which isn’t acceptable considering uncertain results.
Quick win:One of the answers may be Popcorn Flow. I regret that I was only vaguely familiar with this change management tool at that time! Anyway, I’m happy I can share it’s advantages now when I’ve tested it in a few other organisations.
- Popcorn Flow encourages its users to start with Observation, not with a Solution. It’s a great booster for creativity. It simply opens your mind to a wide range of possibilities.
- It helps to limit changes only to most accurate ones.
- It reminds about cyclical feedback sessions so you can adjust the process to team needs and follow the path of continuous improvement.
- It’s a great tracking and visualising tool for all changes in the team or the organisation.
If I wanted to implement one lesson learned from the article, I would probably start with Popcorn Flow as it’s ready to use tool that eases following most of the findings I shared. Once you add a well-trained and empathic PO, I’m sure you will succeed!