Plutora Blog - Release Management
Change Management Process: 13 Steps to Getting It RightReading time 19 minutes
There’s nothing quite like the phrase “change management process” to induce eye rolls from rank and file employees before you even finish your sentence. And, honestly, rightfully so, from their perspective.
This term presages short term inconvenience, disruption, and hassle for nebulous long-term goals, of which they are likely skeptical. Everyone involved can practically close their eyes and picture the Dilbert cartoon that starts with this phrase.
The point is, a change management process is hard to get right.
It’s hard to get right because it’s typically a fraught, large undertaking. But it’s even harder to get right when corporate lore, anecdotal evidence, and popular comics stack the deck against you before you even start.
Don’t let that stop you, though. Organizations have to adapt or die, and organizational change management is the key to doing just that. And, for any but the smallest companies, a change management process is table stakes to effecting that change.
Luckily, you have plenty of tools at your disposal for creating an effective change management policy. These include, of course, having a solid plan and good organization. But they also include cutting edge pieces of software and technological options for managing the change management process.
In this post, we’ll take a detailed look at change management, including traditional approaches. Then we’ll walk through the steps to building a change management process that works for your organization, including how to leverage modern technology to help with each step. And we’ll do it all using a tangible change example: a movement to agile methodologies (a so-called “agile transformation”).
What Is Organizational Change?
Before tackling the subject of a change management process in detail, let’s start with first principles. What is organizational change?
Self-evident as the answer to this question may seem, it’s important to be very clear here.
After all, everything in life, organizations included, drifts along in a default state of evolution and change. Companies are no different. Organizational change isn’t the simple fact of things somehow becoming different, the way a company might if, say, the best sales person on the team up and quit one day.
Rather, organizational change is deliberate. And it has a purpose that you could place into one of two loose buckets:
- Reacting to negative stimulus with a strategy to course correct.
- Proactively seizing some kind of market opportunity to gain an edge.
In pursuit of one of these ends, the company in question will engage in deliberate activities, such as changing its operational procedures, bringing on new staff, adopting new technologies, or socializing new strategies.
For instance, consider the aforementioned agile transformation. Generally this happens in response to massive budget over-runs and slipped deadlines when delivering mission critical software or, “bucket 1.” So the organization seeks organizational change, typically in the form of slightly altered personnel, different estimation and planning strategies, and a fundamentally reconsidered operating philosophy.
So organizational change is, specifically, deliberate, sweeping, strategic activities designed to make the organization more competitive.
What Is Change Management?
With that definition in mind, the next philosophical consideration is, “what is change management?”
The answer to this question is one of scope. When organizations undertake an agile transformation, one of the core changes they seek to drive is “let’s go from delivering software production once or twice a year to doing it once or twice per month.”
And that doesn’t happen by someone in leadership waving a hand and saying, “make it so.”
Instead, that type of change happens via careful, collaborated policy change. In a medium sized company or program within an enterprise, this can affect hundreds or thousands of people over the course of years. If it’s enterprise-wide, this figure can climb to tens of thousands of people over a decade.
Change management is, at its core, the raising of organizational change into a first-class, formal initiative.
Startups can affect organizational change almost on a whim, serially “pivoting” until they find something that works. They’re the organizational equivalent of jet skis. But as they grow, they become sailboats, then yachts, and eventually battleships. And you don’t turn battleships on a dime when someone yells, “hey, look at that bird!” Turning a battleship requires a plan and coordination.
What Is the Change Management Process?
So with an understanding in our pocket that organizational change is about remaining competitive and that doing so requires elevating it to the level of project or program, let’s look at what a change management process really is, in detail.
Simply put, a change management process is the battle plan used by the team tasked with creating an organizational change. It describes the sequence of steps and milestones that must happen between the company’s current state and successful completion of the change. It is the change management team’s project plan.
Beyond that, the change management process will vary by organization as much as a corporate strategy does. And indeed, that is the purpose of the remainder of the post—helping you create the change management process that works for your organization.
Change Management Models: A History and Taxonomy
Now, much as I’d like to add “came up with the idea of change management” to my professional portfolio, alas, I did not. People have likely been reasoning about organizational change for as long as there have been organizations.
But, more formally, there are change management models dating back over the last century. And, it’s important to have an understanding of these when constructing your own, modern change management process. This is not an exhaustive list, but it’s enough to give you the requisite background.
1. Lewin’s Change Model
Let’s start with perhaps the oldest documented model, dating from the mid-1900s. Developed by Kurt Lewin, the Lewin Change Model breaks organizational change into three steps.
This is an excellent starting point because it’s simple but captures some of the core challenges of organizational change.
The “unfreezing” stage earns its name from the conceptual notion of “unfreezing” the organization to make it malleable for a change. This, of course, involves analysis of current processes, but, critically, it also involves winning the hearts and minds of the people involved by convincing them of the need for change. Remember it by thinking of “thawing” their hearts.
Naturally, the change process involves implementing the changes, managing both organizational processes and the psyches of the folks involved and affected. Freezing is then a matter of crystallizing the new way of doing things at the same level as the old way, pre-unfreeze.
2. Bridges’ Transition Model
Next up, consider the work of William Bridges, an organizational consultant. Throughout his long career, he defined (and wrote a book about) managing the human side of organizational change.
Bridges’ Transition Model, in an interesting parallel to the Lewin Model, puts people’s reactions to organizational change in three stages:
- Neutral Zone
- New Beginnings
It might seem counterintuitive to name step (1) “endings,” but it actually makes a lot of sense, given that, for a staff comfortable with the status quo, the organizational change represents an ending. The model then talks about how to deal with the bevy of natural, negative emotions that come with this ending, and to work their feelings toward neutrality and eventual appreciation for the new status quo.
It is telling that an entire model is dedicated to managing the emotions and morale of staff.
3. Kotter’s 8 Step Change Model
Fast forward some years to the mid-’90s, and we have a newer, more detailed model in terms of distinct stages. This model is the brainchild of John Kotter, who published a book called “Leading Change,” which introduced an eight-stage change process.
- Create a sense of urgency.
- Build a guiding coalition.
- Form a strategic vision and initiatives.
- Enlist a volunteer army.
- Enable action by removing barriers.
- Generate short-term wins.
- Sustain acceleration.
- Institute change.
It is interesting to note that one can’t simply overlay Kotter’s model with the previous ones. In other words, simply assigning each of Kotter’s phases to a corresponding Unfreeze-Change-Freeze stage wouldn’t work. And this is because Kotter’s model implies a more iterative and incremental approach.
Modern Steps to a Change Management Process
I wanted to end the historical section by mentioning the idea of an iterative and incremental approach because the need for such a thing has only intensified since the mid-’90s. Organizational feedback loops have tightened considerably with the rise of digital technologies and, eventually, digital transformations.
As you build a change management process to suit your program or enterprise, understand that you should approach this more iteratively, perhaps, than past models have called for. In the 1950s, you might expect a period of malaise to precede a serious change initiative and then a nice, comfortable status quo for many years.
Not so in 2019, when organizations have to respond to market changes orders of magnitude more quickly.
So with that in mind, let’s take a look at specific steps to creating your change management process, interwoven with the example of the iconic agile transformation.
1. Understand the History and Philosophy of Change Management
Let’s start with an easy one to understand, conceptually. if you’re not already familiar with it, do some background research on the subject (and I don’t mean just reading the beginning of this post).
This doesn’t have to be your PhD dissertation or anything like that. But you should read about the models in detail, and find some case studies to review, preferably about organizations similar to your own.
Change management is a complex subject, and there will almost certainly be enough budget on the line that the least you can do is a bit of homework to prepare.
2. Define an Objective and Desirable End-State
Having done your research, the first thing you’ll need to do that’s specific to your situation is to identify an objective, along with a desired end state. What is the actual goal of the organizational change for which you’re defining the change management process? Is it reactive or proactive? What will the company look like when you achieve success?
With an agile transformation, this usually has to do with software delivery capabilities. In organizations with which I’ve consulted, objective and end-state can look like this:
- We want to ship software releases monthly instead of behind schedule every few years.
- Our competitors have switched to a service model rather than a product model, and we can’t follow suit until we’re more responsive to software changes.
- We’ve been dramatically over budget for the last seven major software initiatives, some of which never shipped. We want predictable, timely delivery.
You get the idea. Whether proactive or reactive, all of these statements define a desirable end-state to shoot for, based on business needs.
3. Build a Business Case and Sell It to Key Stakeholders
This step is inseparable from the last one but worth mentioning separately since it’s a distinct activity. You need a rock solid business case for the change, and you need to sell it to decision makers.
To get specific, take the goal of wanting to ship monthly rather than yearly. I think just about anyone would agree that this is a good thing, for some definition of “good.” But is it “good” enough to merit a significant spend, armies of consultants, and staff upheaval? Will more regular shipments mean a significant shot at more revenue, or is it just a vanity metric?
That’s a dicier question.
And because it’s a dicier question, it requires a well-made business case. Work on documenting the cost of current shortcomings or the potential gain associated with a proactive play. Alongside that, project out the cost of the change, given all of the hires and initiatives you’ll undertake.
Once you can demonstrate ROI, bring the case for change to those necessary for approval.
4. Identify Core KPIs for the Change and Ways to Measure Them
Once you’ve defined a desirable end-state, built a solid business case, and sold key stakeholders, it’s time to get more granular. You want to define some core KPIs that will mark progress toward your goal.
In the case of an agile transformation, potential KPI ideas abound:
- Cadence of shipping software.
- Metrics around release health.
- Improved recruitment numbers and reduced staff turnover.
- Measurably increased software quality.
- Defect and feature cycle time.
There are plenty more besides, but hopefully this conveys the idea. Each of these things would tie into your overarching goal and desired end state, but with more specificity.
Equally important, however, is the consideration of whether or not you can measure these things. If it’s something like, say, reducing reported defects, you can probably already measure that. But, for things like release health, you’ll almost certainly need to instrument your program with additional capabilities to properly measure.
So establish not only what you want to measure for progress, but also a very specific plan for exactly how you’re going to measure it.
5. Create a Messaging Plan Backed by a Thematic Goal
With the mechanics of a business case, goals, KPIs, and measurement methodology in place, it’s time to turn your attention to the human side of the change management process. It’s time to start thinking about how to spread the word and earn buy-in from the broader organization.
Of course this involves creating a messaging plan. And that messaging plan should address not only the company’s health, but the motivation that individuals will have for adopting the change, beyond “what’s good for the company is good for you.”
But you can actually go one better here.
Popular author and management consultant Patrick Lencioni wrote a book about breaking down silos within organizations. And while a change management process is more broad than the specific change of silo deconstruction, there’s an important, relevant piece of wisdom there: defining of a thematic goal.
Broadly speaking, the idea of a thematic goal is to create a rallying cry for the organization. Banding together against an external, existential threat is great for breaking down silos. But it’s also good for helping people become receptive to change.
Are you a national bank pursuing an agile transformation because your competitors are leaving you in the dust with their digital capabilities? “Getting modern to stay in business” is a powerful organizational rallying cry.
6. Identify and Enlist Champions to Help With Buy-In
Buy-in isn’t just a matter of blasting out a memo or mass-email to the company. Having a thematic goal is important, but so too is winning hearts and minds in more individualized and granular fashion.
Any initiative is going to fail if it’s just the executive organization “doing stuff” to everyone else. Rank and file employees are smart, pragmatic folks, and nothing will work without buy-in at every level of the organization.
So go out and find your early adopters and make them champions of the cause. Have folks in mid-level management been clamoring to look at agile ways of doing things? Do your software developers, testers, and project managers have Scrum or Extreme Programming in a former life on their LinkedIn profiles? Find these folks and ask for their help.
And you needn’t only look to people with past experience necessarily. That’s valuable, but anyone who is excited about the prospect of the change is a valuable, early ally.
7. Translate Core KPIs to Individual Departments and Teams
Once you’ve got messaging squared away and are making progress on the buy-in front, you also need to equip departments and individual teams with ways to mark their own progress.
If the entire organization needs to ship software more frequently, what does this mean for the more granular business units that contribute components to this software? Sure, it probably means more granularity for each of them, but one size does not fit all.
It could be that the team responsible for the company’s mobile app is already cutting releases every two weeks, but nobody realizes value from them because the backend API team only ships once per quarter. You need a way to recognize the interplay among the organization’s components so that you can set granular KPIs.
For any decent sized enterprise, this is going to mean adopting a platform like Plutora that gives visibility, management, and dashboard capabilities across the organization just to understand the team interaction, let alone to create KPIs for driving improvement. This is one of the most challenging steps of an organizational change management process.
8. Identify Training Needs and Create a Plan to Supply Them
As you’re socializing the change and identifying granular APIs, you want to set your teams up to succeed. You can’t just tell them to change and adopt new things and hope for the best.
Rather, you need to get ahead of the game by identifying training gaps, figuring out how to remediate them, and then laying out a schedule.
Agile teams need to grasp the software development principles that let them move more quickly. Going faster isn’t just a project management concern. Without practices like continuous integration, automated deployment, unit testing, and more, there’s an upper bound to how fast delivery can happen.
If the team lacks training in those areas, line that training up for them. This not only helps drive the change, but can reduce resistance, since you’re effectively providing them with free resume skills as part of the initiative.
9. Create a Resistance Management Plan With Your Champions
Speaking of resistance, have a plan for resistance. Seriously. It’s going to happen, so you need to plan for it.
Human nature drives us toward a certain comfort with the familiar and the status quo. As a result, there’s a natural, “who moved my cheese,” reaction to change among a large set of the workforce. Some will get over this quickly, but it will rankle others.
Create a plan for mitigating this resistance and easing people’s concerns. This plan has to include your champions. Edicts from upper management will never alleviate it in the way that champions at every level of the organization, leading by example, will.
10. Go for a Quick, Big, Visible Win
In the same vein, you should lay out your change management plan in a way that it will deliver a big, visible win, and quickly. That will go a long way toward preserving everyone’s patience and showing them the value.
For instance, in the case of an agile transformation, perhaps you can identify a team under a great deal of pressure or with a history of non-delivery. Then you can take that team, assign some skilled champions to help it, and turn things around quickly. That’s one example, but you’ll have to find something that makes sense for you.
Whatever it is, don’t neglect this step. Demonstrating results early can quiet a lot of grumbling and help people buy-in much more readily. After all, it’s a lot easier to nay-say about a massive effort that may someday pay off than it is about one that started paying off immediately.
11. Monitor and Tune Your KPIs
As I mentioned earlier, in this day and age, change management process isn’t a matter of defining a change, implementing it as a project, then patting yourself on the back. It’s a much more dynamic process, subject to a feedback loop.
So, monitor and tune accordingly. When you start your agile transformation, you may consider the ultimate measure of progress to be shipping software every two weeks. But maybe you discover at some point that you really need it weekly or even more frequently.
If that happens, it happens. Adjust your expectations and measurements, and proceed accordingly.
Don’t do this willy-nilly, but be prepared for it. As long as you can make a business case for the tuning, as you did early on, remain flexible.
12. Inspect and Adapt
The theme of monitoring doesn’t just apply to KPIs, either. More generally, you should make sure to keep an eye on the entire process.
KPIs create sort of a higher leverage set of metrics, so I treated them separately, but everything you do as part of your change management process should be subject to continuous inspection.
“Inspect and adapt” is a common mantra in the agile world, and it begs the implementer to treat nothing as settled or sacred, always accepting that improvement is possible. So it goes with an organizational change. Pay attention to some of the non-KPI things, and have periodic check-ins to see if you can improve them. For instance, here are some additional ideas:
- Is the thematic goal resonating with people and is buy-in increasing?
- Is resistance petering out, holding steady, or increasing?
- Have you closed the training gaps you’ve identified?
- Do the champions seem as enthusiastic as they once did?
I can’t possibly enumerate all of the questions here, but hopefully you get the idea. Make sure you’re constantly asking questions, and use those questions to drive an inspect and adapt mentality about the change.
13. Assume Change is the New Default
Finally, I’ll close with a philosophical step that builds on “inspect and adapt.” And that is to say that you should assume organizational change is the new normal.
Over the last 100 years, the pace of change and new technology has dramatically increased, as best exemplified, perhaps, by Moore’s Law. As of the time of writing, the companies with the top four market caps in the world are all less than 40 years old, with two being a lot younger than that. The days of blue chippers spanning the centuries are over.
As a result, organizations face more pressure than ever to adapt constantly.
So manage your own expectations accordingly. A good change management process isn’t the thing that will get you through a weird transition time as you do something different. Instead, it will become the lifeblood of your organization as you implement it over and over again.