Management Consulting and Training Since 1993
BPM Consulting & Training
menu MENU

IT, Process Mapping and Change Management, Part 1

Three Decades, Two Pieces of Bad Advice

Part 1: Expert Mistakes on Change Management

by Paul King

Over my 30 years at Orion, I have had the opportunity to observe a lot of IT projects and collaborate with many IT consultants. It’s inarguable that the right technology implemented the right way can deliver dramatic improvements in customer satisfaction, revenue and efficiency. However, too many projects fall far short of the intended ROI – in part due to “expert advice.”

In my experience, the two most misguided examples of expert advice are:

1) Start change management efforts as soon as the new IT system is implemented. We need to make sure people use the new system and drop their old workarounds.

and

2) Don’t bother with as-is process mapping. The new ERP/CRM/SFA/Cloud system will deliver best practice processes.

We Must Force the Users (our customers) to Change

Forcing change

A change management expert could easily write a book about everything that’s wrong with the first piece of advice. The goal of change management isn’t to coerce people into using the new system as the vendor intends; it’s to involve and engage everyone’s heart and mind so that we implement a solution that yields the highest return on investment… and to foster a sense of “ownership” throughout the organization. That sense of ownership is what makes performance improvement sustainable.

You might think “coerce” seems like too strong a word, but it accurately reflects the perspective of some IT professionals. Here is a true story to illustrate this mindset.

Back in 2016, I attended PRISM – the conference for information systems professionals who work in public employee retirement agencies. After a breakout session on change management, I headed back to the tradeshow floor with other vendors, most of whom sold software or implementation consulting. I asked one of my colleagues what he thought of the session.

At first, he offered a couple of positives sentences that generated gentle nods from the two other gents. Then he blurted out:

“For me, change management is getting the user to use the new system. These people think they can just ignore the new system and keep using their personal spreadsheets, even though their employer just spent millions of dollars on an upgrade. Change management is getting the user to change. Am I right or am I right?”

At this point, the gentle nods from his peers became vigorous. It was like watching a trio of bobblehead dolls.

To be fair, it’s important to point out his attitude was not a function of arrogance or the need for control. He was frustrated – frustrated because he had multiple clients whose ROI lagged due to poor user adoption. Even though he heard the words of the change management professional in the training session, he did not really believe them because his experience told him the user is the problem. Chances are, this consultant participated in or led several projects that achieved technical success but never quite got the human side of change management right.

Change management begins on Day 1. Not on Day 1 after we’ve determined the solution. Not on Day 1 after the technology is implemented. Not on Day 1 of end-user training as we go live. No, it must be Day 1 of the entire initiative.

What does good change management look like? It should deliver a:

There are a lot of good models (Kotter, ADKAR, Nudge Theory, etc.) that can help you achieve these outcomes. I like an approach my colleague Ralph Smith created called CODE. It’s a question-based approach that helps you think through the technical, behavioral and cultural issues that are key to achieving the intended ROI and sustainable performance improvement. Regardless of the methodology you choose, make sure you engage stakeholders from the very beginning, before the “perfect solution” is designed or implemented.

Part 2: Experts Mistakes on Process Mapping
Share This