There’s a deliverable at the beginning of every effective business initiative that involves sitting down with key stakeholders to determine the organization’s readiness for change. Do it correctly, and you’ll have the information you need to run your entire program.
Frequently, though, change management teams skip this key step or use it for their own purposes. Bad idea.
Here are four approaches to stakeholder interviews to avoid:
Change is inevitable in business. Senior leaders know this, so do employees and customers. When change is afoot, stakeholders need an honest and transparent approach. What they don’t want to hear is blame – laying the responsibility for change at someone else’s feet.
Recently, a magazine I subscribe to sent out a survey, asking readers how they’d feel about:
- receiving this weekly magazine four or five days later than it currently arrives (meaning most of the reviews and listings would be outdated) or
- an increase in the subscription price of the publication.
These potential changes were prefaced with some context: The U.S. Postal Service was changing its service levels, forcing the magazine to arrive late or cost more for subscribers. Or, at least, this was the magazine’s conclusion. Readers, on the other hand, have some sense of who’s responsible for publication schedules – magazine staff, not the post office – and responded with hostility to both options. As of this writing, the subscription rate of the magazine remains at the old price.
Change initiatives spring from an essential need inside an organization: more effective business processes, reliable systems, better customer service, less bureaucracy. Stakeholders know this just as they recognize that the impetus for change is coming from the organization’s leadership. Strong leaders take the wheel and turn the ship when it’s required; change programs need to acknowledge why there’s a change in course rather than assign the blame to some outside factor.
Let’s Talk about Me
One of the first change programs I worked on had an 18-month period of research and strategic planning. That kind of preparation time is unheard of in today’s business environment. Yes, time is precious, but the stakeholder interview is not the place to try killing two birds with one stone.
It’s tempting, when a stakeholder wants to know more or doesn’t understand the change initiative, to jump in and share the vision, goals and messages of the program. But, this deliverable isn’t about talking; it’s about listening. The purpose is to capture all the background about this senior leader’s organization, how it works, what stakeholders require, when they might be opposed to or ready for change, where they touch other key functions in and outside of the company, which cultural sensitivities might affect training readiness and communications, and so on.
Barge in to this discussion, and you’ll miss the most important, salient reasons why you’re engaged in this effort in the first place. Be willing to listen, and your program will run like clockwork.
Likewise, the stakeholder interview shouldn’t be used to float trial balloons. In addition to keeping the change team from the important goal of listening, launching a trial balloon to gauge reaction to it only tells stakeholders that the new direction hasn’t been fully vetted yet. This is dangerous because early in every change program, you want senior leaders invested; you want them championing this change to their organization, not downplaying an initiative because they don’t believe it’s ready to fly.
If 12 percent of survey respondents said they prefer grape jam with peanut butter-and-jelly sandwiches would you assume the remaining 88 percent like strawberry? When designing the stakeholder interview, make sure the questions lead to appropriate conclusions.
Try out the questions on members of the team first, noting the answers, then take the extra step of tabulating them. Did that question about a key business process provide enough detail for you to draw a conclusion? Or do you need to ask follow-up questions about informal channels that bypass the process, which systems are involved, and which teams outside this functional area use the data, too?
Never assume, and make sure to drill down with specific questions that will help eliminate erroneous assumptions.