Project Management

Changing things too late: Why change management feels like an uphill battle

Most change managers spend most or all their time recording already enacted changes. What if, instead, the change manager could work with key decision makers to get ahead of the change process?

Recently, as sometimes happens, a common theme emerged in the "over beer" discussions I have with current and former clients. As budgets slowly begin to reawaken from their years of stasis, managers and CIOs alike find that they have a huge number of projects that need attention. More importantly, attention-starved business users have already begun to demand changes to projects not yet undertaken. In short, they need to resuscitate their moribund change management systems before the chaos overwhelms them. At the same time, they remember the fear and loathing change management inspires in everyone who comes into contact with it.

Usually I just listen to their venting then move on to another topic. Mostly they know what they can and can't do, and I know they know, so it's harmless enough. However, one of them asked me directly once about a quote I often use: "Today is ancient history." After a fair amount of avoidance I finally admitted to him what I've seen over the years.

Why change management inflicts pain

In a change management methodology some entity, usually a change committee or change manager, gathers ideas for changes from various parties. These changes pass through an approval process. Accepted ideas then find their way to the appropriate parties for implementation. Rejected ideas fall into a big bucket somewhere, only to recur in an altered form sometime later. All changes, accepted or rejected, create a paper trail an auditor or manager can follow later to "prove" an idea received its due attention. In a healthy system the accepted change log becomes a record of the change controlled system's evolution, in theory allowing a responsible party to assess the "as it exists" system state.

This all looks great on paper. In practice, the change management system often comes into play at the tail end of the change cycle as a kind of "rubber stamp" for decisions made by whomever holds the power to enact change within a particular area. In application development, this power falls into the hands of developers and the system architect. In infrastructure, system administrators and system engineers hold the power of change. When it comes to business systems, each individual actor in the system can effect changes on his own part of the process and on the immediately adjacent sectors.

When the change manager tries to reject changes he, in effect, tries to usurp power from the primary change actors. In effect, the decision to enact the change has already occurred. The change manager may have the authority to do so, but without some power over the actors or strong influence to alter the decision at its source, he cannot stop a change without creating considerable ill will. This reduces many change managers to record keepers, desperately struggling just to keep up with the constant changes flowing though the system.

In very small, simple environments this causes few problems. Everyone enacting change understands all of the ramifications of each alteration to the system. However, in more complex situations the individual actors really only understand their own work. A very sophisticated actor may intimately understand the work of his adjacent peers.

The change manager, on the other hand, develops a highly sophisticated awareness of the business systems (or application, or infrastructure) on par with that of a business architect. He sees the effects of changes on a daily basis. He can track how various changes impacted nodes four and five spaces removed from the change originator. In other words, he has the perspective to judge whether or not change should occur, but lacks the power to enforce that perspective.

That said, I know of at least three companies where IT groups have assumed the change management role and seized the power to enact changes. These organizations have elaborate ERP systems and massive development staffs to match. They also have equally sophisticated "shadow ERPs," but that is the topic of another conversation.

Towards the idea of change leadership

So, what can we, as managers, do to control change? This is where that obscure quote comes in: Today is ancient history. If we force our change managers to work on the basis of accepting or rejecting changes, we strip them of the ability to really effect change.

Today is the sum result of all of our yesterdays. Every time we expend influence, wield power, or exert authority, we make a small change in today that carries forward into tomorrow. If we want to control change, then, we need to find the right place to use our tools in order to enact the small change that will make tomorrow better.

In terms of change management, I suggested to my client that we focus on the wrong things. Nine out of ten change management systems I've seen either focused on recording the changes enacted by the actors or on giving the change controller sufficient power to override change decisions. The first approach is management at its finest: It can tell us what happened but not affect the outcome. The second creates considerable animosity between the change controller and the change actors (say, a BASIS team and an App Dev team) unless the manager is particularly skilled at influence manipulation.

What if we focused on change leadership rather than management? What if change management were less accounting and more counseling? The idea we hatched looked something like this:

Most change managers spend most or all of their time recording already enacted changes. What if, instead, the change manager could work with key area change decision makers (e.g., the development leaders, the key infrastructure leaders, and the business unit work leaders) to get ahead of the process? These individuals usually wield influence over the change decisions made by those around them. If the change manager could, through communication and force of personality, build an influence network with them, he could begin to affect change before it occurred rather than after.

As we worked on the idea, something else became obvious. An individual with these skills would have to be part leader, part manager, and part technician. He would have to use extremely strong communication skills coupled with the ability to recognize system interactions on a variety of levels. Alternately, he could build trust with the key influencers, relying on their area expertise and the relationship he has with them to come to decisions.

In order for the later model to work, my client realized he needed to give the change manager real rejection power, like that seized by another of my clients in his organization. This power becomes the threat backing up the influence and counseling. If used very sparingly, it makes it easier to work with the change leader rather than against him. If used openly and without remorse then the principle actors will go back to their wild ways, since they "need to do what is best for the business."

Implementing the idea in full will take some time. Elements of it are already in place in his organization; he will have to create others from whole cloth. Taking this approach also forced him to reevaluate his current staffing in the change management role; the gentleman currently in the role lacks the leadership skills to take a more subtle approach.

Next time I have a chance to talk with my client about his experience, I'll write another column to let you all know how it goes.

Editor's Picks

Free Newsletters, In your Inbox