I’ve been asked this question several times over the last few months. It’s a valid question – there are number of different shades of change management and the answers you’ll hear depend on who you’re speaking to:

• Human Resources: An HR Manager will talk about managing change by aligning organizational structure, job descriptions, performance evaluations, peer feedback, and compensation. If the training or learning team is part of HR, they may also talk about training, coaching, practice systems, etc.
• Technology: IT Managers tend to think of it in terms of technical changes, and what needs to happen to get people to use new software as designed.
• Industrial Organization: The IO approach focuses on changing the business by building new systems of doing business, labor standards, and efficiency.
• Risk Management: A risk manager told me that, in his IT Department, the Change Management team functions as a gatekeeper for projects throughout the organization, ensuring that projects don’t overlap or contradict each other; and verifying that, if you said you were doing a project, it got done.
• Coaches: Talk about developing skills, behavioral change, and effective working styles at an individual- or leadership-team level.
• Communications: I’m seeing change management in an increasing number of Communications job descriptions. Based on my experience, I find this approach risky because it excludes the communicator from the project development and brings them in to “sell” employees on the change after it’s too late to make any changes to the approach. Thanks, but no thanks.
• Leadership: Many of the “change management” programs I see advertised at graduate schools focus on senior managements’ role in leading change.

There are so many ways to frame the answer, that I’m sure I’ve left out a few. None of these is wrong – even the risk management approach has validity – I would have killed for a project gatekeeper or governance committee in my last role. Every project I’ve worked on has involved aspects of these other kinds of change, to some extent.

My approach to change management is operational. With so many years in operations, how could it be otherwise? What does “operational” mean? I focus on Process and Outcomes: what result do we want to get and what do we need to do to get that result?

On the process side, I look at the systems of doing business and the procedures that will be affected, determine who will need to adapt their behavior, what tools they’ll need to make those adjustments, and when they’ll need them. I consider what “Why” will influence them and weave that into the strategy.

On the Outcomes side, I start with how the project is defined. A couple of years ago, I initiated the implementation of a workload planning and scheduling system. Our reason for rolling it out was simple: the old system had reached its limit for expansion, didn’t completely support the end-process, and was unsustainably at risk for failure. We could have said that our Desired Outcome was to stabilize the system and get more efficient schedules to reduce payroll (which it did). We could have said it would bullet-proof our labor-law and ACA compliance (which it also did). We could even had said that it would improve service by ensuring that we had the right people in the right place at the right time to serve customers (true also). Instead, we framed our desired outcome as a way to increase sales. Huh? We said it would enable us to reallocate four hours per week per store of assistant manager time from writing work schedules to the sales floor, to coach and model proactive selling behavior, convert customers, and increase sales. Phrasing the Desired Outcome this way affected the rest of the project.

Here are several ways it affected the project design:

• It affected the RFP and the purchase decision. The solution we selected had to have, as its primary benefit, a faster, easier-to-use interface that would result in a 50% reduction in time writing schedules. Other solutions might be easier to integrate with our HR or task management systems, but we focused our purchase decision on speed and ease of use.
• It framed our discussion with the local management teams. We knew that the ASMs who were writing schedules defined success as writing the perfect schedule. If the process cut that time in half but they didn’t measure success by their ability to get on the sales floor, they would work the schedule to death or find other office work to do. This mean that every conversation, presentation, and communication hammered home that the last step in the process was to get back on the floor.
• During the months of discovery, configuration, and testing, we emphasized effective coaching principles and the pro-active selling model; that way, when the time came to leave the office for an additional four hours per week, the ASMs weren’t stepping into the unknown.
• It simplified scope creep push-back because few retail leaders will argue against something that increases sales.
• It guided our decisions around building in ways to measure and follow-up on results.

An HR friend, when I spoke to him about my approach, said Process and Outcomes feels… cold and non-transformational. Well, not to me. I’m passionate about making it easier for people to adapt to change as painlessly as possible. Focusing on Process and Outcomes allows me to do just that: I am relentless in advocating on behalf of the people who are most affected by the change and ensuring that project teams work effectively to get business results on their behalf.

Your turn – what do you mean when you say Change Management? What informs your definition?