OK, Information Technology, you win. You can have it. You’ve ruined it beyond recognition anyway. Only left me a shell of a concept that, at one point, had so much to offer an organization. The ‘it’ I longingly refer to: change management and today change management is dead because the I and the T of information technology has killed it.
The change management that Information Technology (IT) advances is a limp version of the high school, sports, star Organization Development (OD) was and on a playing field where once we excelled. Change management was OD’s domain of excellence.
The concept, simple: how to intentionally manage change to meet objectives. That was our business value. That was OD’s time to shine.
Now change management is a footnote, an add-on, a Frankenstein stitch to a hardware, software, and IT service roll outs.
Worse, led by people who neither care to help their effort relate to people goals in the business, nor care to know that behavior change, not product change, is change management.
IT you have bastardized this concept. Worse. If IT has anything to do with change they’ve taken change management and turned it into … a process.
Change Management, You’ve Changed
So much business value to provide. All that promise, wiped out by IT’s callous treatment of OD’s final, toe-hold to business. You, me, and the other lonely OD practitioners are now the modern-day equivalent of the lonely, Maytag repairman.
At one time, not-so-long-ago, me and my OD brethren held brief audience with business leaders. We made our pitch for why people mattered and in those 6 to 7 seconds we did have opportunity for end-user adoption and utility and business case benefit/cost analysis.
No longer. You! IT! You have slithered behind our backs to convince board rooms, and the C-level, and the VPs of business, and the operational directors that because you wield huge capital expenditure, you can manage the people side. After all, being responsible for so much funding, no fool would give you that much without confidence you would deliver as you said.
Somewhere you have convinced CFOs, COOs, CEOs, and investors that people adopt and love the hardware or software or policy for one of 3 reasons:
- You have made sure they have no choice, or better yet,
- You designed it you know what is best for them, or
- Isn’t it enough you told them
Winds of Change (Management)
Oh I hear on the wind that IT teams account for change management, but never do see a change management plan. Change management is not a plan or a process, but a promise.
I hear business directors make mention of the importance for change management for the project to succeed and announce they’ve assigned someone to take care of change through a timely email announcement at the proper time. A top-down announcement is not change management.
But in reality, I am here to tell you change management dead and it is your fault.
Let’s look at this from a rational, not emotional, view. Let me take this to the people’s court of Google. I type “change management” into Google:
- 1st Google result: Change management is a structured approach to shifting/transitioning individuals
, teams, and organizations from a current state to a desired future state.
- 2nd Google result: Change management is an IT service management discipline. The objective of change management in this context is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control IT infrastructure, in order to minimize the number and impact of any related incidents upon service.
The concept, the theory, the principles, the process, the goal, the objectives. The whole lot. Ruined. I now leave meetings with nothing to do. I am told IT has change management covered. I feel like I have entered an alternative universe.
“But I don’t want to go among mad people,” Alice remarked.
“Oh, you can’t help that,” said the Cat: “we’re all mad here. I’m mad. You’re mad.”
“How do you know I’m mad?” said Alice.
“You must be,” said the Cat, “or you wouldn’t have come here.”
(Alice’s Adventures in Wonderland, Chapter 6)
Organization development is change management and now we might get a trinket of a communication strategy, somewhere near the end of the project, that the IT department will have final edit and approval for anyway.
The Change Management Call
The scenario plays out, again and again.
“Change management? Nope, we’ve got that covered in the project management plan, it is called … now, let me see, what is it called, oh, yea, here it is, we definitely have it covered, it is called change control.
“You said change management, you see, we are a step ahead. We are monitoring and controlling change.
“We control change, you see, we don’t just manage change. We won’t let change stop us.
“So, you see, we got change covered.” [Phone hangs up.]
“Change management? We’ve got that covered in the IT department. Nope, don’t need your help, thank you.
“What’s that you say: impact assessment? stakeholder analysis? training? end-user testing? persona models? communications? change readiness? survey? Can we do those if it won’t affect when we go-live?
“No, you say, they may affect the date?
“Well, perhaps, we try just one of those whatever-you-call-them?
“We have a date to get this done. We can not take time for delays to deal with any soft stuff, this is business.” [Phone hangs up.]
“Change management? Yep, the project management office has it covered.” [Phone hangs up.]
You, yes you, IT. You alone have destroyed OD’s final engagement with business on stuff that matters: end-user adoption and utility.
The only books on my office bookshelf people recognize have the word Change and Management somewhere in the title and some books have the words Change Management together.
Now, stuff on the shelf about engagement, collaboration, learning, Emotional Intelligence, organization behavior, no one stops to talk anymore. They just walk direct to IT.
Change Management: Not Dead, Just Sleeping
10 years ago I could look across the table and say, “sorry, I know how to do change management, but I really have no idea what you just described as change management.”
Now? Now everyone does change management:
- Project managers – check,
- Business analysts – check,
- IT managers – check,
- Human resources – check,
- IT architects – check,
- Software designers – check,
- Customer service – check,
- Catering staff – check,
- Systems architects – check,
- Accountants – check,
- Building security – check,
- IT engineers – check,
- Anyone… [well, not anyone, I would say 2 of the above qualify as slight exaggerations]
If everyone has a handle on change management, there go all our psychology-type degrees, right into the rubbish bin.
Change management to a project manager? Nope, not the same: change control is not in OD vernacular.
Change management to an IT person? Nope, not the same: facilitate agreement of change assumes change is linear.
Change management to an HR person? Closer, but nope, not the same: a change communications plan is not date driven.
Change management to an OD person? Doesn’t matter anymore. Now? I meet IT. I look around the table and say, “what do you have in mind for change management?” I bite my tongue as they show their change management process. I take notes. Listen to their time line, then, any number I write, I know, is divided by behavior.
Hey, unless I want to go into OD academic research, I still need to work.
If IT focus is on contribution to productivity, change management has life.
If IT focus is on value creation, instead of problem avoidance, change management has life.
OK, OD here’s my change proposal: IT has already ruined systems theory, let them have it; IT has advanced their version of change management so well it is the accepted version, let them have it. Good riddance to change management.
From here out, OD, they say change management, I say end-user adoption. IT can have the change process, I will care for the change promise. End-user adoption puts OD back at the table, it is our job to make certain we stay there.
Next: Change management is dead – the vital signs
Share this Post
Interesting take on the subject of Change Management.
I had to read it a few times to appreciate the satire.
It does highlight the fact that diverse groups and disciplines are using identical terminology to describe very different functions. I belong to the IT community, I tasted the ITIL cool aid, and it was good.
Controlling change through change management has been proven to make a complex technical environment more stable and less prone to inadvertant failures caused by uncontrolled change.
When asked if I have Change Management covered, I am pleased to answer that yes I have, with bells on!
On the other hand, when I am invited to participate in an application upgrade or new application deployment, and am asked if I have Change Management taken care of I am again pleased to answer that yes I have, with bells on!
BUT, I didn’t understand the question. It is totally out of context for the area of expertise in which I work.
If asked whether I have a plan to assist staff to adopt the new system and to manage their expectations, provide training and a support desk, my answer would be, a resounding NO. That is the realm of OD.
Your article reminds me that context is so important in what we say and what we hear.
Thanks for the reminder.
I am interested to hear of solutions to this problem.
Change management certainly relies on context. I tried to be a bit tongue-in-cheek about the whole thing, but I have further beliefs I hope to expand in future blog posts: suffice it to say they revolve around HR being so far removed from the real business of business that IT’s version of change is at least a bit more respected – change management [history] is written by the victors.
Perhaps not complete change management – to the purist.
Perhaps not intended as such, but HR/OD has a hand to play in losing the battle for hearts and minds to go along so critical for the new IT solution.
I have found, reading Alan Cooper’s About Face 3 book lend deep insight in what I can do to design better, in any thing that involves design. Now that matrix management seems the default in most organizations, design principles and community persona modeling gets us both IT and people closer goal-oriented design for change.
I truly appreciate your comment. Where have you seen the most complete change management initiate that started with the business case, assembled the project team, built the physical change, and accounted for the behavioral/emotional adoption?
I am the IT Change Manager in our organization. As “people” change management receives more and more attention, and rightfully so, I find myself almost always having to clarify that I do “IT” change management whenever I introduce myself in a business setting. Kind of a namespace thing… yes I am a techie!
IT change management is relatively easy to follow (implementing it is another story…). IT change management has a process, a checklist, SOPs, etc. which funnel you towards the goal of introducing change without disrupting production IT systems. Rinse and repeat as necessary.
OD change management, that’s another story. The people side of change is an art, not a science. People have an inherent limit to how much change they can accept and everyone and every organizations culture is different.
I don’t envy the job of OD change management folks, but I am certainly here to help in any capacity that I can!
Change without IT disruption is a critical component of continuity planning, no doubt. The key to change: the context of what change brings to someone’s world.
IT Change, forgive and clarify if this is too general, is rational change. Organization Change (end-user adoption?) deals with the emotional change.
Emotion trumps rational all the time.
Technology or product-related items are intended to work each time you execute a command, until it breaks, and you had a contingency for that (I expect).
People-related change or end-user adoption of a technology does not work, reliably, when a command is executued; so-to-speak.
Thank you for reaching across the aisle in the hopes that our objectives meet an enteprise goal. Because after all, why the capital budget spend if the end-user adoption and utility fail.
Great! Server farms.
Terrible! Lost business-side productivity as people were left feeling incompetent about the new software. [utility]
How do your conversations account for roll out/ramp up? Roll-out: product focused? Ramp-up: end-user focused?
I am one of those psychology-type graduates who has recently stepped into the world of Change Management in an IT Services world. Like Lee Farrell mentioned below, I too find myself explaining that what I ‘do’ is the people side of change. Maybe its in the semantics….or maybe its just a plain ol’ homophone (-think blue, blew, to, two, too). Either way, I am now part of an IT shop that has made it a priority to compliment ITIL/ITSM change by implementing change with people, staff and clients in mind. Project impact and risk assessments, communications, client feedback, training, emotional adoptation and continuous improvement are our goals.
I expect it to be a learning process but I am hopeful to see that at least from where I stand, we are learning to breathe new life and new perspective to Change Management in IT.
Maybe it isn’t quite dead yet?
What, if you don’t mind, do ITIL and ITSM (systems management?) mean?
I have hope and trepidation for you. We do, sincerely, plan for the possibilities. Perhaps that IT budgets are so dramatically larger than Organization Development/Design, Organization Behavior, Organization Change budgets gives IT the actions of a 600 pound gorilla?
We are left, many times, with the budget that may get us a 2nd-hand acoustic guitar and the ‘Kumbaya’ sheet music. Can’t beat a gorilla with an acoustic.
Well, if we hide within project management, my Project Management Professional certification may be the most powerful tool I’ve acquired, then we might have better traction.
No, unfortunately, many organizations treat PMs as meeting coordinators and note-takers – if you’ve ever tried to do a stakeholder assessment plan or communications plan, you know this.
My hope: change the words. I am going with end-user adoption. I am sprinkling the word utility about. I gave it a go with a CIO and a CTO today.
You should try it, tell me how it works up in the Great White North – so much friendlier up there, could be our last toehold.
Seriously, Lisa, they call people change the ‘soft’ side. Replacing a laptop is the easy part, building confidence for tool adoption and utility increase: that is hard part.
Toby, provocative as always!
I wonder if we can make change a bit more tangible by referring to it as behavior change.
Yes, there is an emotional component. And part of that is our inherent neurological preference for certainty over uncertainty. The brain has six times as much wiring devoted to threat detection versus opportunity. Therefore, change is not treated by most people as juicy goodness, at least not as it is served up. One way the brain learns fairly easily is by observing and imitating others’ behavior.
This is one of the inherent challenges of IT-led change. New software and systems are offered to the business self-evident goodness. “You asked for it. Here you go.” It is also positioned as a control-driver. “There is one right way to do it and it is captured here.” If it is not in the system, it must not be a way that you or our customers need to do business.”
There are rarely respected individuals who enthusiastically model their own use of the system. What’s missing is a group of respected individuals who will behave the change into place.
Incentives are not enduring ways for humans to learn. Kids don’t learn to walk because they will be given a treat or a bonus. We don’t usually need to negotiate with them and launch a communication plan to our kids. (Okay, today’s wakeup theme with oatmeal will be “Walking – it beats falling!” At lunch, we will show them a PowerPoint on the 5 short term benefits of self-ambulation. At dinner, we’ll show the video on the long term benefits.) They walk (in part) because they see adults do it and because adults celebrate when they get it right.
Unfortunately, demonstrating the new behaviors required of a new system very rarely equals the sheer thrill of accomplishment of learning how to walk.
Change management is challenging when people leading the change forget that their real job is modeling the change. Most often, that means senior leaders need to stand up and take the first steps.
This comment is incredibly rich. One item that leaps into to the forefront is ” … missing is a group of respected individuals who will behave the change into place.”
The thrill of accomplishment is very intrinsic. When accomplishment has to have a temper against the amount of transactions, project milestones, or deliverables (reasonably or otherwise), the thrill to some is replaced with the fear of failure or just keeping their head above water. So when items are piled higher, more effort is marshaled to survive than available to thrive. It takes a great effort to look to the thrill of accomplishment when the chill of survival breaths down your neck.
Sad, but too many times, true. Squeezing more means you can expect to extract more. Modeling change relies on a realistic model to change and the context of who you are modeling to.
Greg, thanks for your comment, I have framed some new thinking around the perspectives you shared.