You’ve got old systems that still must be maintained; you’ve got a backlog of small changes; and you know your team has to change how it works and what tools and methods it uses if you’re going to move forward. How do you manage the transition?
Let’s talk first about what hasn’t worked well for most enterprises. Many have tried sending the signal that change is here by reorganizing. One large Western Canadian company moved from dedicated development/solutions teams tied to portions of the business to a central pool concept, organized by skill sets. Nothing much happened: the same people kept working with the same people, because maintenance and small changes to existing systems was “known”; forming ad hoc teams to respond to new demands was “unknown”.
Change requires getting people on board
Productivity in this organization actually started to fall the moment the idea of changing how they did things was first discussed. Even ahead of the reorganization, it was falling. That’s because the normal reaction of most people to a change imposed on them is to go into denial.
Most managers hate the ones who start talking about all the reasons this change won’t work. These resisters, on the other hand, are one of your greatest assets: they, at least, have accepted that change is required. Most, on the other hand, cling to what they know, ignore what’s new, and, in denial of the need to change, double down their efforts on things that don’t move the team or company forward.
We saw this when the transition from home-grown code to packages took place. Ideally, packages would have been installed “vanilla” (it’s much easier and cheaper to maintain and update them if you do) and user areas would have changed practices. But most IT teams didn’t even try for that: “writing code is what we do” and, in denial, packages were modified for any reason, any demand, from the users. This left the enterprise trapped in old releases that were too expensive to update as the years rolled on.
Paradoxically, with today’s cloud offerings and the urgent need for value creation from IT, we’re now back to the need to write home-grown code for systems that differentiate the company and allow it to extract value from the marketplace — while running the routines of the firm as inexpensively as possible. That means today’s challenge is to “de-modify” packages while going back to coding where it makes a difference. (Likewise, it means application portfolios, which had been shrinking as more function was moved into comprehensive packages, are growing again.)
But, instead of seeing differentiated function being written in stand-alone modules (either outside the main packages in use or as wholly contained components within them), we’re mostly seeing mods directly to the cores of packages being authored. Denial is deeply rooted.
One west coast company actually tackled fixing this — with highly positive results.
Getting past denial and going into productivity
This company, like its peers, was running a superannuated version of a major ERP package. When a new financial extension that allowed for business differentiation came through the backlog and onto “work to do”, it was delivered (for the first time) via an authored component within the ERP framework. The manager in charge asked for volunteers from his team: rather than select who’d do this work, or force the whole team to change at once, he made it possible for the deniers to “do no harm” by doing maintenance and other small work, while letting the resisters go forward.
He coupled this with new performance standards, and new degrees of freedom, to encourage the path of learning and delivery he wanted.
The new component was delivered much more quickly than usual. Now some of the deniers saw opportunity, and wanted to sign up. There wasn’t a new component requirement in the queue.
So those who wanted to “join the future” got projects to de-modify the core of the ERP. At first these were done on a shoestring, since they weren’t funded. But they became an engine for change, one person at a time.
Four years later, their ERP was mod-free. The entire group then jumped from a mid-1990s version of the product direct to the latest release from the vendor.
The manager in question got a two pay grade jump — from manager to director — for the initiative. Oddly enough, as the only “product-centred” team, his group had been left out of a more general reorganization into “productivity centres” that had failed to deliver.
The bottom line on change is this: you have to find a way, up front, to bring people from denial (the normal response) to wanting the change. This will mean facing resistance — but resistance is not futile, it’s the path forward. It’s how those having to change ultimately make changing “their idea”.
