Know your stakeholders

Change can be hard. This is true for many reasons; but at an organizational level, one of the main reasons is that the people involved in or affected by a change may resist it. Maybe the change will be too hard for them to learn, maybe it deprives them of benefits they were getting under the old system, or maybe … well, they could have all sorts of reasons. But if a few of them dig in their heels, the whole job of implementing even a minor change becomes exponentially harder.

Of course this is why change management is a field, and why stakeholder engagement is one of the main topics in that field. Over the years, practitioners have discovered that some methods work better than others to win people over to your side when you are trying to implement a change. Today there are organizations, like the Change Management Institute, that focus on nothing else.

Yesterday I had the opportunity to attend a webinar sponsored by the Quality Management Division of ASQ, which introduced the CMI's Body of Knowledge (CMBoK™). The webinar was presented by Douglas Wood and Sandy Furterer, both of ASQ. Of course, in a single hour the presenters could touch on only a very few topics, but I found it useful all the same. And for those already looking ahead to next year, Wood and Furterer promised they will be back in 2025 to present an overall change management approach for middle managers. Stay tuned! (Yesterday's webinar was part of a series that began last month with "The Faces of Change Management.")

I want to talk today about a tool that Furterer described for evaluating your stakeholders and planning how to engage with them. Conceptually it is very simple; but that simplicity makes it useful and powerful, because it is so straightforward to apply.

The tool is just a table that lists all the stakeholders involved in a particular change initiative. It has six columns, as follows:

Stakeholder: List each stakeholder by role, not by name. Use the structure of the subject process to identify every single role that is affected in any way. List them all. 

Type: A role that is directly affected or impacted by the change—one that actually touches the process or system or technology—is primary. All others are secondary.

Primary role: What does this stakeholder do in this process? Why are they listed here?

Potential Impacts/Concerns: What does this stakeholder care about? What are their fears, or concerns, or issues? What matters to them? Note that sometimes when you do this analysis, you'll find that one of your roles has several unrelated concerns. Maybe you identified "Customers" as a stakeholder, but it turns out that domestic customers have very different concerns from customers abroad. If that happens, it's a sign that you need two rows. You have just learned that Domestic Customers and Foreign Customers are actually two different categories of stakeholder.

Initial Receptivity: What does this stakeholder think about this change today? Where are they now? Are they for it or against it? Furterer's example included three ratings: Strongly support, Moderately support, and Neutral. (I suppose that for completeness your table should also allow for Strongly opposed and Moderately opposed, although naturally we'd all like to avoid that case if possible.)    

Future Receptivity: Here is the critical planning question: Where do you need this stakeholder to be (with respect to this change), before your plans can go forward? Note that you don't necessarily need strong support from every stakeholder. It all depends on the details. Of course you hope to avoid strong opposition from anyone; but for some stakeholders it might be enough if they are neutral, so long as they do not actively interfere. For others, if you do not have their strong support you will get nowhere. So work out what target state you need to achieve in the mind of each stakeholder. 

Now look at the differences between your last two columns: Initial Receptivity and Future Receptivity. Those differences tell you where you have work to do, before you can launch your change initiative in earnest. Identify which stakeholders you have to win over, and how far you have to win them over. Then look at what they care about, in order to figure out how best to approach them.

For example, if one stakeholder is currently opposed to the change and all you need is for them to be neutral, you can focus on addressing their fears. Find out why they oppose the change, and then show them how those concerns have already been considered in the planning. You might not get their active enthusiasm; but if you can show them that their fears are ungrounded then you may move them from opposition to neutrality.*

If another stakeholder is neutral—or even opposed—and you need their support, you have a different job. This time you have to show them how they will positively benefit from the change you have in mind. Answer for them the basic question, "What's in it for me?" Presumably you already have a good answer: you wouldn't be doing this change if it weren't on balance a benefit for everyone. But make sure that your stakeholders understand what it is before you ask for their support.

It's a simple tool. But it shows you at a glance what your stakeholder strategy has to be.  

__________

* I assume that their concerns really have been addressed in the planning already! If you've made these plans without even thinking about their concerns, maybe it's time to go back to the drawing board. 😀  

     

Why are you an auditor?

Over the years, I've worked with many third-party auditors. And often, over lunch, they start talking about their work. I like to ask how they got into auditing as a profession. Many of them started in very predictable ways: they worked as Quality managers or engineers for some company, and then made the sideways move into auditing. Sometimes it was because they wanted more variety in their work; sometimes they lost their jobs (or retired) and needed a new job that drew on some existing expertise. Many of the stories were variations on that basic model.

But one of the most interesting stories I heard was very different. This man's background had not been in Quality. He was an engineer, and a would-be entrepreneur. And he told us he had invented a product that he thought would sell itself.

Let me call him Amir. (I no longer remember his name, but I'm sure that's not it.)

Anyway, Amir quit his job, bundled all his savings into starting a new company to market his new invention … and promptly went broke. Oops. 

So far, it's not an unusual story. A lot of people try to strike out on their own and then fail. What was special is what he did next.

When his company failed, Amir did a systematic root-cause analysis of the failure. And he determined, after careful scrutiny, that the reason his company had failed is that he had no idea how to run a business!

So he set out to learn. He reasoned that the best way to learn how to run a company was to look at a lot of them, successes and failures alike. And therefore he sought out work as a third-party auditor, which would let him see a wide range of companies. His hope was that through his experience as an auditor, he could learn which management practices worked, and which ones didn't. 

His long-term plan was that, once he had saved up some more money and learned how to run a business, he was going to quit auditing and go back to restart his company so that he could finally market his invention.

I lost touch with him years ago, so I have no idea whether his career ever worked out as planned. But I was always impressed by the systematic thinking behind it.  

       

Have you used the Five Hows?

The August 2024 edition of Quality Progress contains a brief article about the Five Hows, and I'd love to know if you have used them yet. Leave me a note to tell me your story!

Most of us have already heard about the Five Whys: it's the simplest tool for root-cause analysis. I describe it in multiple earlier posts: for example, I explain how the concept works in this post here. And recently I applied it (purely as a demonstration) to a current question in American public policy in this analysis here. (I discuss it in other places too, including here and here.) 

In principle the Five Hows are exactly the same thing, except that instead of asking "Why did that happen?" you ask "How will we do this?" So they look forward rather than backward. They are for planning rather than diagnosis.

So far, so good. But the documentation I have found up till now has been awfully thin on examples. The article in Quality Progress is only one page long and it's written entirely at the level of theory. I have found a few other articles, but the information they provide about how to use Five Hows are not consistent with each other.

For example, this article that Dennis Henry posted in LinkedIn (from November 2023) treats the Five Hows strictly as a supplement to Five Whys: the idea is still to find the root causes of a problem, but Henry says that by asking "How ... How ... How ...," we can uncover detailed technical root causes instead of managerial ones.

This article from Quality One (undated, no author listed) still restricts the Five Hows to problem-solving, but applies them to brainstorming corrective actions. In other words, once you have found the root cause of a problem, you next ask "How ... How ... How ..." in order to fix it.  

Back in my first article on Five Whys, I worked an example that started with "My car won't start," and the root cause turned out to be "I didn't maintain the car according to the schedule in the manual." (This was a fictional example.) So in that case, the Quality One article would propose that I next ask, "How can I make sure to maintain my car according to the schedule in the manual?" The answer would probably involve adding reminders to my calendar, or something similar.    

Then there's this article in Medium, that George Spasov wrote back in February 2017. Spasov tells us that he actually invented the Five Hows method independently. And he also gives one detailed example of how to use it outside of traditional problem-solving.

His remarks on inventing the method are as follows:

This technique was developed by… well … me.

I was trying to figure out a way to achieve a very specific goal for my work. By being a heavy user of the 5 Whys I knew that there must be a way to reverse the process. To be honest, I don’t know whether somebody else had drawn the same conclusion as me. If you know a similar concept and the person behind it, I would love to hear about it and collaborate on the matter.

His example goes like this:

• How can I improve my brand positioning? By getting more quality exposure to my target audience.
• How can I get more quality exposure to my target audience? By communicating the right messages to the right people.
• How can I communicate the right messages to the right people? By first understanding what these messages are and who is my target audience.
• How can I understand what these messages are and who is my target audience? By first making an analysis of my existing clients and their interests.
• How can I make an analysis of my existing clients and their interests? By making a drill-down of this data from the analytics.

Someone might say that "improving your brand positioning" is a kind of "problem" that Spasov is solving with this analysis, but it's certainly not traditional problem-solving! This is somehow more like corporate strategy than it is like traditional corrective action, and I'm excited to think that Quality tools can be as useful in the boardroom as they are in the laboratory or on the production floor.

I only wish I had found more examples of this kind of usage.

So tell me your stories! Have you started using Five Hows? And if so, what kinds of problems have you used them to solve? Do you find them most useful to supplement traditional root-cause analysis? Or have you been able to deploy them—as Spasov did—to build corporate strategy as well?

Drop me a note. I'd love to hear from you!