Change Management and IT

In IT, change management often means making the client go through bureaucratic hoops to slow down the change requests from the users. In my reckoning, a lot of times the change request system only worsened the situation: it led to the software developers feeling more powerful and the customer feeling more alienated from the development process, since the product ended up being the way the developer wanted it. This problem always bugged me. I tried to think of a different way to do change management, but the literature on this was all based on technical solutions (ie, creating procedures and forms to manage user expectations).

Years later, I would encounter the same phrase -- change management -- in MBA school. But the way it was tackled in business school used a different approach to it. The first principle they taught us about change management was: "You can't manage change."

That's because change is dependent upon the people involved in (affected by) the software development process and you can't manage (control) people the way we manage furniture, or printers, or office supplies for example. (And for that matter, can we even really manage how employees use office supplies and printers?) People are the X Factor of management. That's why business school distinguishes between managing and leading.

Managing is about seeing what we have, preserving status quo, and optimizing what we have. Leading is about seeing far ahead, seeing more than what we have, and guiding people towards that vision.

In their book Leadership on the Line, Ronald Heifetz and Martin Linsky argue that the usual management problems require technical solutions to solve, but change requires adaptive solutions. Technical solutions are those we do by the book or were taught to us in school or from the company manuals. Adaptive solutions are more challenging because they require us to understand the environment and experiment (ie, "to adapt").

Leading people through change is an adaptive skill. It is about knowing the people well and how to influence them towards a certain goal. It's not about position or authority. It's about selling a vision of change to the people affected by the change. It's about empathizing with those who stand to lose a lot from the change you are introducing. It's recognizing that they have emotional attachments to tightly held values and traditions about how they did things the old way and how that mattered to them.

Sounds crazy, right?

But think about it. All software development involves leading users through change, often difficult change ("What if I become redundant if this new computer system gets popular?"). But what is an IT expert's usual response to resistance to change? "Give them the right training and a user manual, and they'll stop resisting."

Training won't always work, because some users may be attached to one way of doing things ("My dad was an accountant for 50 years and he taught me how to do this in columnar pads."). And change always requires a learning curve that forces people to jump out of their comfort zones ("This is just more work for me.")

I've seen and heard all kinds of excuses and expressions of resistance. But most of them stem from the few patterns that I mentioned above (more of these signs of resistance in future posts). If you ask me the key to change management and resistance, my quick answer is "Plan and Persist." (And more about these, in future posts, too).

How about you? What signs of resistance have you seen and how did you work around them?