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

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

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.