Is your organization ready to adopt your next technology project?
“Your new system doesn’t work.”
When CIOs hear those words, they know they’ve been blamed for a lack of ROI. Never mind if the plan was painstaking or if the installation was flawless.
In fact, any CIO who has lived through a failed implementation will tell you: most of the time, technology isn’t at fault. The system works fine. The problem is the people and process did not change.
Change management educators like Prosci would agree: “For important projects, the percentage of benefits that depend on people changing how they do their jobs is commonly in the 80% to 100% range.”
Still, when benefits fail to materialize, people are quick to point fingers at the new technology and the CIO.
Six questions to assess and neutralize resistance
Late last year in an otherwise deserted conference room, I sat with a CIO determined to stop being the scapegoat.
Together, we developed a questionnaire to gauge how much organization change management his next technology project would need.
Below is a condensed version of the in the form of six questions. When answered candidly, CIOs and their teams can use these six questions of this evaluation to uncover and neutralize resistance to an implementation before it scuttles the benefits.
1. Is the change an Upgrade, Transition or a Transformation?
Change in any organization usually fits into one of three categories: Upgrade, Transition or Transformation.
An Upgrade is the least disruptive change. It involves the upgrade of existing technology with minimal (if any) effect on business processes. While change of this kind typically meets little resistance, communication is still critical for success.
A Transition is more vigorous. This usually involves significant changes to processes, which requires new skills, knowledge and practices, yet there is little change at the organization or cultural level. An ERP implementation, for example, often falls into this category.
A Transformation makes the deepest impact. It requires a complete overhaul of culture, behaviors, organization, structures, systems, processes and technology.
Examples include M&A and major restructuring.
Determining the type of change in which your new technology is involved is the first step in gauging how much resistance you can expect.
2. Is the executive leadership team on board and do they understand their role as advocates for the change?
If users perceive executive leaders aren’t behind the changes, they won’t see any reason to back them either.
That’s why the leadership team are vital advocates. Yet that means more than touting the promised capabilities. You need them to explain to users why those capabilities are important to the business’s future. They also need to explain why the changes they demand will benefit the users themselves.
If you can say with complete confidence executive leadership strongly supports the change and are ready to drive it in the organization, you’re well on your way. If you’re unsure, plan to take time translating the technological changes into real business benefits they can easily understand and rally behind.
3. Will this program change how individuals work on a day-to-day basis?
Herein lies the core of resistance. Changes to a person’s roles and/or responsibilities can be perceived as threats to their status. Process changes may clash with what users have always deemed most important. Unaddressed, users will quietly revert to the more comfortable status quo.
I saw this firsthand when a global manufacturing company asked for our help with their new ordering system. Data integrity had plummeted after go-live, causing significant delays in fulfillment. After a little digging, we discovered end users did not trust the information they were getting from the new system. Instead, they had gone back to using standalone Excel sheets.
Within two months, the data was reconciled and everyone was re-trained, but the damage had been done. The company received a record number of chargebacks from customers who’d grown tired of waiting.
Just like a new system will depend on technological infrastructure like servers and routers, realizing the benefits of that system depends on human infrastructure: the behavior of your end users.
Plan on helping them not only learn how to use a new system, but also understand why it’s needed to support the change. Otherwise their preferences will eat your new system (and credibility) for lunch.
4. How many users will be impacted by this change?
The more users involved, the more difficult the change, and not just in terms of complexity. It can also mean more obscurity in which resistant users can carry on as they wish.
If you’re dealing with a large user base, plan on segmenting it into smaller groups in which accountability will be easier to maintain.
5. How many regions and/or countries will your change be implemented?
When needed, most technology change efforts include training in multiple languages. Yet when spanning the globe, or even one country, differences in culture should also be taken into account. And in many cases, those differences can be significant.
For example, users in the Northern area of one of our client’s regions were quick to please. They craved instructions and took pride in following them exactly. Yet their Southern counterparts were different. Keen to avoid conflict, they would nod along with our instructions quietly, and do what they thought best when we were gone.
For programs that span countries and regions, plan to consult with people steeped in each area to determine the best approach.
6. Who will be responsible for ensuring that non-technology changes are made?
By now, if you’ve thought through the previous questions, you’ll recognize that successful change management goes well beyond just training. There are also process, role, responsibility and cultural changes to consider. None of which typically fall under normal IT or HR responsibilities.
For example, to take advantage of an integrated digital supply chain, engineering will need to work with purchasing and planning in ways that don’t fit an engineer’s job description. If they’ve never had to work with those departments before, why should they think they need to now or in the future? It gets especially tricky if you have hundreds of engineers dispersed around the world.
Who is leading the change effort for your critical programs? Identify someone (or a team of people) who has the background to guide the change effort critical to the new system’s success. Otherwise, if no one has any of the responsibility, you’ll be much more likely to get all of the blame.
Conclusion
Every CIO has a choice when it comes to a new implementation: Assess the resistance a project is likely to face and plan organization change management accordingly, or roll the dice.
The first option is more difficult up front. It’s not easy to think through the ways a positive change could be resisted. Yet it not only increases the odds of success, I’ve found it also gives CIOs an equal seat at the leadership table because a focus on change moves the conversation away from just technology to business capability.
The second option is easier initially at kick-off, but at go-live, the problems quickly mount at the doorstep of IT. You can try to bring up change management at that point, but it will be difficult to hear you over the blame.
This is why successful change management goes well beyond just training. With any change, processes, roles, responsibility and cultural changes are key to a positive transition.
