Manage Change – Or It Will Manage You

Humans measure progress in two ways. The default approach is to make a to-do list and measure milestones. What do we need to get done? By when? What's the hottest priority now? That works fine until we get overwhelmed by either volume or the need for speed. Then the system breaks down fast.

Today, volume and velocity are givens. Everyone expects IM responses in seconds, email responses in minutes, decisions made better and faster. The bottom line: We need to get as good at change management in our decision-making processes as we are in networks. Technical leaders especially tend to think they intuitively understand the process of change and can manage it effectively without Gantt charts, milestones, and dashboards.

They're wrong. It's rare that IT pros look at their efforts through a real change "lens." It's even rarer that they assess progress and take "change actions" that are distinct from normal project work.

[Want more change-management tips? Read 10 Agile Skills CIOs Need To Manage Change.]

There are three steps to move away from the to-do list method and look at progress from a change standpoint. But first, you need to select and stick to a change-management approach that fits your needs. There are many to choose from, including Lewin's Change Model, the Kotter Model, the Mckinsey 7-S Model, and the Burke-Litwin Model. Your project managers or a colleague might have a favorite, so ask around. It's not about picking the perfect model. What's critical is having an approach and using it consistently.

Typically, change models include standard ways to communicate and create a shared vision. Right there you start to see the challenge, especially for the technically oriented among us. There needs to be a consistent effort in communication, discussing the right things at the right level with the right people. Managing change requires leadership and a sustained effort.

Got your model? Then let's posit a scenario. I recently worked with the head of a development team who had one particular project that, despite being considered a priority, kept slipping. There always seemed to be some reason it fell down on the to-do list. Now what?

Step 1. Assess the effort on a change scale.
The dev lead assessed the project from a change standpoint using the Kotter Model and discovered the problem: The sense of urgency was just not there. He realized that people were not talking about the project as they were other initiatives that clearly had a sense of urgency about them. He noticed that some senior people and peers were not as involved as they could be, which might have been sending an unintended signal. This is what I mean by looking at a particular project through a change lens, stepping back from the "to do" work and assessing where the effort is on each change dimension of your adopted model. This is a subjective assessment, where you simply rate where you are on a scale and determine the strongest and weakest factors.

Step 2: Identify what change-management actions to take.
With the assessment in hand, it's now about brainstorming. This is a creative step in the sense that there can be many ways to address a particular problem. I have found over the course of many client engagements that this step really unlocks thinking and action. The output here is a carefully selected set of relevant change actions. For example, if communication within certain groups is low, what can you do about that?  Should you talk with the manager of that group? Give a short presentation in a staff meeting? Provide succinct email updates? It depends on the situation.

For our development team leader, thinking about the "sense of urgency" problem led to several options. He could continue to bring this project up in conversation. He could get team members to take greater ownership. He could get senior leaders involved. He could get peers energized.

Given his organization and nature of the project, it was clear that what he needed was to get his boss, the CIO, involved to show how urgent this effort was. He also needed to enlist several peers.

Step 3: Act!
So far, so good. You have a change model, you used it to make an assessment, and you came up with key actions to take. However, there is a final step: Ensure the actions you identified happen. Sounds obvious, but the problem is that "normal" work can push extra change-management efforts off the list. You can't let that happen if you want change to stick.

So our dev manager did several things. He scheduled his boss to come by and talk with the team over the course of several meetings. He sought out peers and gave them a better understanding of how the project fit into business goals. These steps, which aren't about a technical side of the problem, put the project back on track. The red status indicators started to turn green. He had established and reinforced a sense of urgency.

The critical factor in having change that sticks is to recognize that you must continually manage it. This is different from completing the normal "to do's."  The practical step is regularly assessing change and taking change actions.  Make this part of what you do, or change will always manage you.

Take part in the 17th annual InformationWeek Strategic Security Survey, help shape our 2014 coverage, and enter to win a 64 GB iPad or one of three on-on-one consultations with report author and security expert Michael A. Davis.