Author: Geoffrey Hamm, Sr. Automation Advisor
Everyone hates change. Everyone loves improvement. Two statements that appear to be mutually exclusive. That’s because they are. The reality is people don’t like change, unless it’s irrefutably “better”.
You may have heard the term “Change Management” floating around the water cooler, understated, as if the phrase wasn’t worth the air used to muster it.
But what exactly is “Change Management”, and why is it always the last kid getting picked to play volleyball?
According to the American Society of Quality (ASQ):
Change management is defined as the methods and manners in which a company describes and implements change within both its internal and external processes. This includes preparing and supporting employees, establishing the necessary steps for change, and monitoring pre- and post-change activities to ensure successful implementation.
At this point in my career I’ve been involved in several software projects. Some have succeeded, some have failed. The number one culprit for failed projects is a lack of proper change management, yet organizations repeatedly make it an afterthought.
“They’ll do what we tell them to do”
“Leave adoption to us, that’s just change management”
As it turns out, companies will spend a ton of money building applications that never get used.
Have you ever been driving out in the middle of nowhere, passed a sign for a new, sprawling subdivision and thought to yourself “who would ever live here?” A few miles later, as you pass the advertised subdivision, the answer is crystal clear: nobody would, and nobody does.
This also happens with software. And sure, you could impose a corporate-wide mandate (i.e. use it or lose… your job), but that’s a pretty hostile card to play. Regarding the adoption of a prospective solution I once heard a C level resource say, “I’ll jam it down their throats, and if they don’t like it, there’s the door”. Yikes!
What can we do to make sure it never comes to that?
Today I’m going to talk about a few specific things we can do to manage change with minimal effort, resulting in a dramatically higher success rate. By designing to the users, challenging everything, telling the story, taking a proactive approach to user acceptance, not walking away early, and a little hand holding, we can guide the highly subjective outcome of change from “worse” to “better”.
If I was designing a new hammer, I’d at least want to know what worked and what didn’t work with the old hammer. An easy way to get that information? Talk to someone who uses a hammer all day long.
This seems obvious, but it frequently doesn’t happen. Strategic overlords want to reverse engineer solutions from desired outcomes – metrics or KPIs. The “who” becomes secondary and is often written off as an issue for “Change Management” to address later. But to neglect our users is to neglect Change Management. Systems and data have no opinions on change; humans do.
Be aware of desired outcomes, but design to the users.
In 1980, IDEO, the renegade design firm out of Palo Alto, was tasked with creating a new computer mouse for Apple. The desired outcome was a cheaper mouse. This project was a success and the mechanism designed has been recreated in nearly every mouse since. More on that story here.
Imagine, however, if that mouse had been created with no consideration for the human hand. It would be (a) cheaper and (b) in a landfill.
The goal is to make it so good that people want to use it.
Challenge everything. Nothing is off limits.
Ask “why?” five times in a row (if you can do so without being annoying).
Ask the “Harry Potter” question: “If you had a magic wand and could change anything in your organization, what would it be?”
Process improvement should be an opportunity, not an obligation.
Trust is a prerequisite. If the participants think these changes are purely hypothetical and unlikely to materialize, they will be unlikely to subscribe to the paradigm shift. This is where the “Art of the Possible” plays a key role, because it’s not just about thinking outside the “box”, it’s realizing that what’s outside the “box”, albeit foreign, still exists in nature.
The sad reality is that a lot of people have been burned by the promise of technology, resulting in wide-spread skepticism. As a result, it takes some people a while to warm up to the principles of agile software development. They fear that if they don’t disclose every single nuance up front – covering all bases, dotting all i’s, crossing all t’s – that it will very soon be too late.
Today, technology can change as rapidly and as fluidly as our conversations about it, but that adaptability is useless if there is nothing to adapt it to (i.e. no conversation being had). So, to make everyone comfortable, mitigate fear and encourage conversations, just break it down:
When challenging everything, don’t just say “we can…”, but also say “…and here’s how we could” (possibly even “this is how long it might take).
Once all parties (including the system) trust one another, and we have successfully fostered a “challenge everything” environment in which everyone is openly contributing, challenging our competitors will just be another thing.
Don’t just talk to your users at the beginning and end of a software engagement, keep them involved every step of the way. Everyone loves a good story. Even more, everyone loves to feel like they’re a part of a good story
Like most good books, we want to focus on our characters and their development. More specifically, we want to focus on our characters (End Users) and the actions they take to achieve a result or outcome. Our beloved characters must always prevail!
Like books, projects have chapters (Iterations) with a beginning paragraph (Sprint Planning) and an ending paragraph (Playback). Over the course of the chapter, things change. Have you ever found yourself reading a book, briefly zoning out, then realizing your comprehension dropped off a few pages ago? This happens in software engagements too, which is why we recap with a Playback.
Blank page. New chapter.
If you can’t explain it to a middle schooler, you probably don’t know what you’re talking about. An age-old adage. If you think it’s a hyperbolic one, it isn’t – just watch Dr. Talia Gershon explain Quantum Computing to an 8 year old. Hand holding is important. This is the reason I am so anti-acronym, as you may have discerned from my previous articles. Acronyms isolate those unfamiliar with them.
Make it so simple that it’s understood by the least common denominator, and don’t omit the value proposition. The value of the new system should be universally understood. This is the definition of everyone being “on the same page”.
Much like a parent teaching a child to ride a bike, at some point we’ve got to let them go. They may fall. They almost always fall. But over time, the child will ride like the wind!
My point – you can’t hold the end user’s hand forever, which is why it’s important to let them drive. We always prefer Playbacks to be delivered by the End Users, because (a) it gives us an opportunity to regain some objectivity, (b) the message is always stronger when delivered by someone close to you and (c) we can see what happens when we take our hands off.
There’s no reason to get everything 100% complete before asking our users if they like – accept – it.
When I first started at IBM, we had a Bootcamp. The general function was to input a group of fresh-faced college kids, and output a group of capable, self-reliant software consultants… or so I thought.
During Bootcamp we’d get very hard (often impossible) assignments and the expectation was for us to find our own answers and to present whatever sort of self-sourced solution we could scrap together. There was a kid in my class however who was notorious for asking questions. Meanwhile, I kept my questions to a minimum, thinking I would learn more by making it harder on myself – I’d have more to show for it. But every day around 5 or 6, my co-worker would have completed his work and be out the door, while I would stay late, clinging to the linings of a Keurig cup.
Did this make me a better consultant? No. Arguably worse. In the real world, nobody cares how you got the answer, only that you got it. I would argue that my co-worker was developing better skills by uncovering solutions quicker, making better use of available resources, often leaning heavily on soft skills to do so. He also was getting a lot more sleep.
User acceptance is the same way. If we want to be popular, we can’t just be quiet all year and then rock everyone’s socks off in the annual talent show. Napoleon Dynamite is the exception.
If we want to be accepted, we need to be proactive and talk to people – ask questions, let them know that we’re human too, and that we’re capable of listening.
At some point, our work will be done. What a great feeling! We can exhale and look forward to life’s next challenge. Too often, we think we’re done when we aren’t. We’re setting the baton on a desolate strip of highway with no fellow runners in sight – it’s not on “Autopilot”.
I am not saying we should make ourselves irreplaceable (or move in), but rather that we should plan to be replaced responsibly. We should define what “Autopilot”, or a successful handoff, looks like because it varies from project to project. “Autopilot” might mean that we’re running in Production with 100+ instances. Other times, it might mean that the in-house development team is successfully building greenfield applications for their fellow users. Either way, we should define it and work towards it.
The harsh reality is that – if we disengage too early – the project will often crash, or fly straight on to the shelf.
Change Management is a very complicated, nuanced discipline. By no means have I fully explained it over the course of this article, but hopefully I have helped convey its importance. For Salient, Change Management is not just an afterthought – it’s omnipresent. By taking some of the steps outlined above, we can increase the adoption of our applications.
We’re like the news, we have a story and we need to spin it from “everyone hates change” to “everyone loves improvement”.
Salient Process is a full-service digital business automation shop and proud IBM Automation business partner. To learn more about us at our website, request a free consultation with one of our expert automation advisors! We look forward to guiding you and your company along your own unique Digital Business Automation journey.
