Hey, Laura Brandenburg here from Bridging The Gap. Today, I want to talk about how to handle
resistant stakeholders. We received a question from the community
about this particular business analyst who was working with users of a potential CRM
system who really liked their paper processes. I’m there! I’ve got paper notes right here (but there
are a lot of things I do electronically too). But they were resistant to transitioning over
to using the new customer relationship management system and he just wondered if he’d done
everything he could to help bring them up to speed on the new system and to engage them
and make sure it met their needs. Let’s talk about that. How do we handle resistant stakeholders, those
who really don’t like technology? I’m going to talk about five different strategies
to make sure that you’re engaging resistant stakeholders to the best of your ability. The first is build an individual relationship. We have a whole video that I talk about different
ways of cultivating a 1:1 relationship with the stakeholder and helping them understand
business analysis. Make sure you’re taking some time to invest
in that relationship with that stakeholder. Not just as “a stakeholder,” but as a
person. A work relationship doesn’t have to be like
you are best friends and go out for coffee or drinks every day, but that you care about
them as a person and that you’re not just there because of a project need, but that
you have a relationship with them outside of just the context of that specific project. It’s going to help build trust and smooth
the wheels for more conversations, deeper conversations, and a real basis of trust and
understanding. Take time to understand their current process. Their current business process, as paper-bound
as it might be, what are they taking notes on, how do they manage information, especially
when it’s a resistance to technology, where does the paper come in, and why is the paper
easier to them? Why does it feel easier to them? What need is that serving? Just understanding it. Not trying to change it, improve it, or do
anything to it, just let me understand your current process. I want to make sure, no matter what solution
we come up with, it meets your need, your process, your way of doing your work. Because, presumably, they’re good at what
they do and that’s why they’re in the roles that they’re in, and probably why
there’s a little bit of resistance, too (like, “this is working for me”). Take some time and understand that. That’s a great way to also deepen that relationship
with that stakeholder. (Not sure how to document a business process? We’ve got a free Business Process Template
download for you.) Focus on their problems. What are they frustrated by? In the scenario that the BA brought up with
us, it sounded like there was, maybe, some frustration that they traveled a lot. They had all these paper notes that were in
filing cabinets that they couldn’t refer to easily. Is that a point of frustration for them, or
is it not? Do they have a way of working around that? If so, what is it? What’s their frustration? If the system could do one thing for them,
what would it be? What would change the game for them? Sometimes, especially if you’re dealing
with higher level stakeholders that have a lot of power in the organization but haven’t
really been involved in the project so far, this is where you can use a little bit of
that influence you have as a BA. You can say,
“You know, this frustrates this important stakeholder. I know we weren’t planning to address that
potential issue right away for this project, but do you think we could address some things
that would really help get them on board?” You help bring that frustration into the scope
of the project, and that can help wear down some of that resistance. Now you’re solving a problem that they care
about, that they want solved, and you’re bringing it into the context of the project
and you’re putting it in the light of if we can solve this problem, we’re also going
to solve all these other bigger picture problems, which is probably why the project got started
in the first place. I saw a project manager do this in one of
the organizations where I worked. I was a contractor and everybody was new to
me, and we knew this particular team was going to be resistant and that we might not get
any information from them. They were just so resistant. When we got going, then they gave us the wrong
information. It was craziness. So she went in and said, “Let’s just talk
about your problems. What’s on your plate? What’s slowing you down?” They just gave us this overload of information
about what their frustrations were. Some of it wasn’t in scope for their project,
originally. She took that and went back to the executives
and said, “We really need to address this in addition to the things that you wanted
to address in the first place. We might have to actually eliminate a few
of your things to make sure that we get this important group up.” And it did wonders. She had just paved a trail of gold for me
as the business analyst to walk behind her and say, “Okay, now, let’s get the detailed
requirements for these issues that have been bothering you for a long time.” She broke down that disengagement and turned
it into trust and generosity and excitement about the project. As you do this, then you also want to share
wins. This is a little bit above and beyond. Now that you see other salespeople working
and using the CRM, once your project gets going, if you’re still facing resistance,
share the wins. Who are the people that are using the system
effectively? What are their processes? How did they organize their work differently? Share those wins and adjustments. How is it affecting their sales or their numbers? For example,
“So and so was able to leave early on Fridays because his sales notes process is so much
easier.” Whatever it is that might be important to
that stakeholder, share those wins. When you see somebody having success, share
that more broadly so that people start to see people are using the system and having
results, and they’re solving these problems. Those are 4 strategies, let’s talk about
the 5th. That is to secure higher level support. At the end of the day, as business analysts,
we have influence; we don’t have authority. We can’t fire people. We can’t remove their paper. We can’t do anything specific to make anybody
do anything. Nobody can make you do anything. But as business analysts, we can’t use direct
authority. Sometimes we have to get higher level stakeholders
involved. That can be escalating to the director, the
VP, or the manager. Whoever is that level up from that person
who is resistant. It’s up to them to say if the problem to
be solved by this project, if the return on investment of using this new system is so
important to the company, we’re going to stake our performance metrics on it. “I’m going to pull out the rug on the
old system, we’re going to make it uncomfortable for you not to use the new system in some
way.” After they go through all the influence and
authority, and ‘you need to do this’ tactics, it might come down to a much harder line. That’s not for you to do as a business analyst;
this is for you to be aware of, of how these things might play out in an organizational
context. Fun story, or kind of a quirky story, is my
mother-in-law is a retired nurse and she still talks about the day that they introduced electronic
health records at her office and that led to her retirement. She consciously chose not to learn to use
the new system and chose to retire instead. To this day, she doesn’t use a computer. She does not see our kids’ pictures on Facebook. We can barely get a hold of her on a cell
phone. She has no desire to be any part of that technology. That was a choice. She organized her career around it and her
exit from her career around it. That happens, too, in some organizations and
with some people that are truly resistant to change. You can do all these things, but you can’t
force people to change. Just kind of be aware of the limits of the
scope of what you can do as a business analyst. (We talked about this in more depth on Protecting
Your Emotional Investment.) Do your best. You don’t want a bunch of people retiring
because of your project, but sometimes that happens and that’s okay, and it doesn’t
mean you did a bad job. I hope this answers your question. Great question. We could talk about this topic for a long
time. It’s a good one; it’s a juicy one. I’m looking forward to seeing your engagement
with stakeholders and helping them overcome that resistance to technology. This is the sales process that we do as business
analysts in helping people see a brighter future and change the way that they need to
change, that creates a positive change for organizations as well. You’re doing great work. Thank you for what you do.
