Part 1 of 3: Who needs Change Management when you can be Agile?
We all know why large projects fail. It usually isn’t because the teams aren’t talented enough, or because there isn’t enough money dedicated to the project, or even because the wrong solution is chosen to begin with (although those things do occasionally happen). No, most large projects fail because of poor interactions between people: communication is lacking, expectations aren’t set, adoption doesn’t occur, and decision-making processes aren’t clear. Thankfully, most companies understand this and invest in hiring change managers like me to work alongside project managers, and together, ensure all aspects of a project are managed appropriately throughout the project’s life. Some smart people out there even developed change methodologies that beautifully align to the standard aspects of a project and have long served change managers well. But about two decades ago, Agile, and other rapid release methodologies that don’t have a project manager, a project plan, or detailed requirements, started gaining momentum. Without these standard project management aspects, this new approach began to disrupt the change manager’s role and their ability to be effective, which left us change managers wondering where we fit in.
Generally, rapid release methodologies do not call out the need to incorporate many change support activities, let alone identify change management as a specific role that is needed. Is that because these methodologies solve communication issues, unify disconnected expectations, or resolve the need for user adoption? Does the organization no longer need change support if they go Agile? Heck no! This has change management written all over it!
An organization in an Agile environment depends on its employees’ ability and willingness to adopt constant change as part of their jobs. But change is stressful, and constant change is constantly stressful. And when employees are worried about their ability to keep up in a constantly changing world, resentment, resistance, and a lack of adoption can slowly set in if proper change support is not established early on.
Unfortunately, there are very few practical resources that break down the different change elements and support needed in rapid release environments. It’s not as simple as just using “mini” versions of standard change plans (as some people have suggested) because that still assumes traditional project management roles and deliverables are in play. On top of that, pushing a standard change framework onto an organization that encourages teams to work quickly and autonomously can even cause increased resistance within those project teams.
To complement the fluid nature of a rapid release environment, and not add friction to progress, a change manager needs to realign their approach to the overall project and right-size their change activities to fit each release. Doing this effectively will depend on two factors: 1) How much of an impact will users have to manage? 2) How mature is the organization in their ability to execute rapid releases? By simultaneously managing change at the release level, as well as right-sizing the efforts based on the organization’s maturity, a Change Manager can dramatically affect the likelihood of user adoption and overall project success.
In the next two parts of this series, we will do a deep dive into how to approach these two areas differently:
1. Supporting change, one release at a time: As with any initiative, the impact and scope of the change being undertaken drives the amount of change support that end users will need. From a general back end change to starting a user in a new system, the scope of change can vary greatly in rapid release environments. Not every change will need a communication plan, or warrant using complex survey models, so it’s important that a change plan is right-sized to the scope of each release.
2. Supporting the shift to rapid release: To get the most value out of a rapid release methodology, the development team must implement a Minimally Viable Product (MVP) and iterate on it based on learnings gained along the way. In life, however, people don’t generally receive minimally viable products with constant updates – they buy fully developed products and update it whenever it stops working. This means expectations have to be reset across all levels of the company, so that employees are more likely to adopt the changes right at the beginning. This allows the development teams time to learn from previous releases and create a product to its full potential.
