From Pushback to Buy-In: Change Management that Actually Works | Episode 531

Unpacking Project Failure: The Need for Change Management What if you delivered a successful project and then nobody uses it? Let's Hello, and welcome back to the Project Management podcast at pm-podcast.com. I am Cornelius Fischner, This is episode 531. Thank you so much for joining us today. If you are listening to this audio only and if you would like to watch the video of this episode, you could do so at pm-podcast.com slash 531 or pm-podcast.com/youtube. And if you are on YouTube, a quick like a quick subscribe, it really helps. Thank you so much. So as project managers, we know that even the best solution can fail if nobody uses it. Successful delivery isn't just about hitting deadlines and budgets. Instead, it's about getting real adoption from real people. And that's where change management comes in. In the coming minutes, we will explore how to manage resistance, engage skeptical stakeholders, and build momentum through early wins. You'll hear practical strategies to help you guide your team and users through change with clarity and confidence. Joining us from Madrid in Spain is Mario Gonzalez. He currently manages public sector projects at T Systems and brings over 15 years of experience leading agile transformations and digital initiatives. With a hands on people centered approach, Mario offers practical insights into the human side of project success, especially when it comes to managing change resistant and stakeholder engagement. Let's bring him in accordingly. Alo Maria Hola Mario ES UN plus certain tenerte con nosotros. You can tell that Spanish is not my number one language. I have rudimentary knowledge of it. Hola, Mario. Speaker 2 Hello everybody, Cornelius and the rest of the people in the audience and nice to meet you. I'm here to answer your questions. Speaker 1 Wonderful. We already have our first comment here from Ryan. Thank you for covering this topic. Very timely for me, which is perfect that you did this Ryan, because of course we are live. We are live on YouTube X, Facebook, LinkedIn, So if you have a question or a comment like Ryan just did, please do go ahead, type it into the chat and we will answer your question here live on the program, right? We are starting with the adoption gap reality. How to Identify and Address the Adoption Gap We're trying to look into why projects may succeed technically, but they fail because users never adopt them. So Mario, in your work, how do you define the adoption gap in simple terms? Speaker 2 Well, you have mentioned this is one of the key things because for example, if you develop and implement some kind of system or tool for whatever client you may think of and they don't use it, it doesn't make any kind of sense. So the earliest you detect this situation, this the better. And that's for me the the the main thing, how to detect and spoke this gap and how to solve it or what kind of measures we might have in order to avoid that. Speaker 1 What is an immediate step that listeners can take in order to identify such an adoption gap? How do I notice that the users aren't using it? Is it just looking at it or or what's? What's your approach here? How do I identify? How do you identify this? Speaker 2 I can identify different ideas, for example, one of them to monitor KPIs, for example, how many people access the system, how many locks, insurance, how many or the the, the general duration of connections, etcetera. That's one of the main topics. You might conduct a survey, a user within a survey in order to know how they feel, what they feel, how they are going to use the system, or maybe quite they don't, just they don't use the system. The third one kind of idea or issue is to listen to informal feedback. This is very important because when you have some kind of meeting or some training, maybe people don't say to you what they think of you or about the system or about the tool or about these topics. But if you listen to them, if you have one to one sessions with them, if you want to identify what they really think in small groups, this is better because you know exactly what they think. But there are other indicators, for example, when they change their behavior or for example, they change from being a supporter to being neutral, maybe to be against the solution. This is very typical and you need to detect that. On the other hand, the management layer or maybe the sponsor, are they rightly engaging people in order to use the tool? Are they doing enough or they need to take some measures, maybe to accompany the client, maybe accompany the stakeholders? Are they doing their job or not? Training and workshops is fundamental or vital because you need to show the the benefits that the solution or this tool provide to people. And if you don't sell got the tool is intended to, maybe you have a problem. And this is very important. Are you providing them with support, help the support if they have doubts if they want to solve different issues or not? And maybe the last indicator for me, if you are developing one kind of tool or one system for different departments in one company, are they using them in the same way? Or maybe are some departments that use it and others not? Because some some sorts are global for one company. And maybe if some department uses more time or maybe in a better way with respect to others, where's the problem when it is intended to be global for the company? So more or less this seven ideas that I have mentioned are the main ideas in order to identify this adoption in my opinion. Speaker 1 In your work, have you found? Have you done a root cause analysis and maybe found a few reasons that swim to the top? Why many people just, you know, don't use the solution and why we get this adoption gap? Speaker 2 Yes, exactly. Sometimes because they don't perceive the idea of the tool or why you are developing or deploying or doing the roll out of something. They don't see the, the, the, the why it is beneficial for them, or maybe because nobody has explained deeply what it consists of. And that's the main reason. So you need some kind of, you need to accompany them in the, in the trip. So you need to roll out and then to be with them to explain why it's going to be better for them, why they have to change, why they have to use the tool that you are intended to deploy. But maybe this idea comes from their own company because they want to change the mindset about people, and that's the most difficult part of the job. So it's not only a matter of deploying. You have said that in the interaction very well. So it's not only a matter of developing something technically perfect, but also the change management that it implies. And it depends on the sector sometimes. Classifying and Tracking Stakeholders: Supporters, Neutrals, Resistors From the adoption cap reality here, we're moving on to the stakeholder radar. You mentioned 3 terms earlier, supporters, neutrals and resistors. Walk us through your approach. You know, how can you tell if somebody is a supporter, whether they're neutral, whether they are resisting the solution that we are building? How do you do this? How do you do identify them? Speaker 2 First of all, you need to know how many different stakeholders you have and the power that they have. This is very important. So the, the, the first idea consists of identifying them, or at least the most influential of them from different departments, from different positions, different jobs. And then you have to register that in a kind of table. So the, the maybe these stakeholders change in the time and you have to update this identification because they might show up and maybe disappear in some time because they have changed their position, they have changed their role or whatever reason. So you need to keep this solution updated at every moment. And this is difficult because you have a lot of. Speaker 1 Yeah, you mentioned table. So in in order to map them initially, is it just, you know, in in a team meeting, I put up 3 flip charts on the on the wall and then we go through everybody and we say, OK, this is a resistor, this is a supporter. Oh, I think this person is neutral and we add them in there. Is is this really it? Speaker 2 Yeah, exactly. Something like that. And you need to keep in mind that fact that they might change a long time and time. And this is very important. And there are possible movements from one person being a supporter and then neutral or maybe in the end to be against your solution just because you have not paid enough attention to them. And engagement is very important in this case and to keep an eye on what they are doing, what they are saying, what they comment maybe directly to you or the rest of the team, maybe this informal behavior that I have said before. So this is one of the main ideas. Speaker 1 And how do you know that somebody has changed from, from, from one column to the other? Is it just, you know, oh, I'm noticing this person is suddenly very supportive, so I need to move them from the neutral to the supportive? Or is it a formal activity? You know, every so often we meet as a team and we review them and, and we move them around. Or is it both? Speaker 2 In my case, I trust my intuition and especially body language. This is very important and there are some facts. For example, when we are in an online meeting, for example, as we are at this moment, when somebody stops switching on the camera, that shows a lack of interest. And maybe if at the very beginning they were showing their faces and they were behaving proactively and taking part in the meeting, and after some moment or some days or some weeks, they stopped doing that. That's the main idea. Maybe a change in tone because if they especially if they move or if they drift toward being unsupportive, there is a change in tone and their tone is harder because they are against the solution for whatever reason. And you need to know the the why, why this is happening. Speaker 1 Would I be correct in assuming that this is not a public list that you share with people? This is something that is more, you know, you keep this close to yourself because you probably don't want this to be on. I don't know your your Internet right, where everybody can see where you put them, right. And so this is. Speaker 2 It's internal for the team. Speaker 1 Delicate. Speaker 2 Team. Exactly. Exactly. Yeah, this is something internal confidential for us. Speaker 1 OK, got it. So we've got the stakeholder radar going and of course we want to spot resistance early. All right, you said, OK, I can, I can figure out my my intuition helps me here when I have somebody not turning on their video. But in the beginning, you know, what are some of the small signs that you look for that help you identify where somebody falls? Speaker 2 For example, their attitude, how you are trying, you are trying at the very beginning to say what this tool or this system is intended to. And the tone how they address to you is very important because in that precise moment you know their attitude or if they are supporters or they are not supporters. And if they saw some kind of resistance from the very beginning, so you see it from from minutes one, what they are going to do, how they are going to behave, if they are going to comply to their bosses because they are against the solution or the tool or something like that. And I insist in this in this idea, body language is very important. If you do it in person, that's better. But if you need to use some kind of video conference tool, that's another option. But in person, it's better because people take part in these conversations. Or maybe they come close to you at the end of the meeting and tell you, OK, I haven't said anything in the meeting formally speaking, but you have to know that blah blah blah blah. Speaker 1 OK, now here's the thing. You you talked about body language. What about cultural factors? You're in Spain. I'm, I'm a Swiss person living in the USA. Here in the US, generally speaking, you know, the Americans are, are thought to be, you know, more open and more vocal and more immediate with their feedback. How is it for you? Do you have teams primarily in Spain? Do you have international teams? How does the culture here fit into this for you? Speaker 2 This is another issue because cultures are very, very different from one another, not only in Spain, because as you know, we have different regions and people from one part of Spain don't behave in the same ways as others, and they're the same with the rest of the world. So for us in a team, in a distributed team where you live, you're accustomed to some kind of attitudes, but people in another place are accustomed to other attitudes and you need to know how they behave in order to engage them in the project and to know generally what they are thinking about it. So yes, this is another issue for projects, but not only for projects, for clients too. Maybe the situation for them is the same. They are distributed and you have to address messages in some way when you deal with people closer to you, to the, the, the area where you live and in another way with people that live in, in other parts of the world. But this is part of us, all of us, and this is very important. Speaker 1 And and what about artifacts and events that happen and and are developed during a project? Risk logs, Retrospectives, Dashboards. Are there any hard tools that you look at in order to determine whether or not somebody is a resistor or, or is it really it's it it you know, it comes from experience from within you. Your intuition is really the number one tool that you personally use. Speaker 2 Yes, in this case retrospectives, you have mentioned that they are very, very important as well as creating or setting up some workshops based on design thinking or something like that. So you can identify exactly which pinpoints everybody has, everybody have and why they control of the solution, why not, what problems or potential problems they see and things of the sort. So yes, in these retrospectives for me or even 1 to one sessions, team sessions or something like that is where you detect that and you have to do it on a daily basis. Speaker 1 I would expect that also during solution demos, when you show them, you can easily spot if somebody likes the what they see or what they know, right? So that's the moment when body language really becomes important, right? Speaker 2 Exactly. And sometimes there is a lack of communication in that sense, because if that happens, you have a big problem because you are developing or implementing something, you have some demos or something like that and the client is not satisfied because you have developed a completely different thing. And why this thing or this event happens? Because you have not engaged in in the right way to the client or different stakeholders or maybe internally in your own company, you need to show some kind of report or whatever and you present something that doesn't have any kind of value. So why have you done that? You have not asked, you have not got the right requirements. Somebody has not explained to you what you have to do. That's typical too. And. Speaker 1 I'm already thinking towards the end of our conversation because you've seen my slide deck, right? So you know what's coming at the end. I have a meme at the end. And, and what you have just said is, is exactly what that that meme is, is pointing towards. But we'll get there. We'll get there. Turning Resistance into Buy-In: Tactics for Opposers Right now we talked about, you know, spotting resistance early and we're moving on to engage early opposers. And this is a completely rhetorical question, or maybe somewhat rhetorical question. But why should we target the toughest critics 1st instead of loss? So why should we go to those people who are really vocal and loud 1st and not wait until later? Speaker 2 To be honest, this is the first thing that you have to do because otherwise your project might fall apart or be derailed. So it's more or less the same so. There are people who try to apply this technique the other way around. So as I know that this stakeholder is an opposer, maybe I don't want to talk to him, I don't want to engage him. But in the end, you will find him or her for sure. So the later you do that, the worse. And the problem is that in the meantime, this, this person you don't know or maybe you know the kind of power that he has or she has, your project might fall apart. And that's the problem. So the earlier you engage them, they need to feel part of the project, the better. That's it. Yeah. Speaker 1 You mentioned Design Thinking workshop there. Do you have any other hands on tactics and, and approaches that you personally use in order to engage with your loudest critics? What how do you get them to really, you know, voice their, their concerns and, and help them see no, no, we are going in the right direction and, and this is how all of this will help you. Speaker 2 I have mentioned this idea before too, this one to one sessions or maybe this informal feedback that you might ask him. This is very important because you need to get close to them in order to know what they think about the project, the system or whatever idea that you have And you have to implement and to align expectations from both sides. So if somebody shows resistance, you need to know or to ask him or her, why do you show this resistance? What can I do for you? How can I engage you? What should we change in order to that, that you feel better with this project or what's the lack in the project, if you know what I mean? So you need to engage them. They need to feel part of the project and they need to support you in the end with the rest of the stakeholders. Speaker 1 What do you do if you seem to have exhausted everything that you normally do? You know, you engaged with them one-on-one conversations, you listen to their feedback, but they just don't seem to become supportive. How do you escalate it? Where do you escalate this to? What is your approach here? How do you how do you approach these situations? Speaker 2 Well, for example, if you are a provider, for example, like in my case, the first thing that you have to do is to escalate it internally. Because maybe your boss or the boss of your boss, or maybe the, the response, the, the person in charge of the contract or the person in charge of the client needs to talk to the sponsors from the other side and approach or, or settle the approaches that they they want to, to have. For example, if this order comes from the government or comes from the different regulations, they need to implement that and you have to do that. So there, there's no discussion. But in other situations, it is something that the company wants to implement among the different employees. And there is some possibility of discussing of changing the project or if, if not everybody feels comfortable with the project or not. And this is the idea, you have to escalate internally. And after that one discussion comes or some discussions come, maybe you have to change the requirements, but they have to do the same internally in their client because somebody or a group of people don't want the project for whatever reason. So they need to or to conduct this service in order to know or change requirements if needed. And after that they should convey the results of the survey to you because you are the provider. Or maybe you have to change? Speaker 1 Do you get the situation where you find these early opposers, you work with them, you you discuss their concerns with them and then they flip, They become, you know, from the early opposer, they go to a total supporter. What? What does that look like for you here? Speaker 2 Yes. And sometimes it happens and it is, it is funny because from the beginning they saw one attitude for example, and they changed in three months time. And the question is, why have they done that made it? Is that you have settled or fixed these expectations? It's possible that you know the feedback about the project, about the team, about the client, about the provider or, or whatever feedback you might think of. And after that, there is a kind of alignment. And this is surprising because from the very beginning, maybe the, the, the tone was very, very hard. And in the end, he's one of your supporters. And I have seen these these actions sometimes in some clients and in some projects, but you need this approach to them. This is vital for me. Overcoming Resistance in a Real-World DevOps Implementation All right, And this is actually the moment, I think this is the perfect moment to talk about the project case study. When we originally discussed what are we going to do here, you said, oh, I have a case study that I want to share with the listeners, with the audience here. So let's do this. Mario set the scene for us. What was the project, its stakes? How did you manage the adoption and the change in all of this? Speaker 2 OK, I have a clear example in my mind. And in this case the client has different regulations they need to implement in different moments of the year. They don't have the possibility of changing a lot and sometimes they want to improve the procedures and this is very important too, because they want to save time or maybe they want to perform automation and so on. In this case, it was a DeVos project and they were not accustomed to these projects. Why? Because they they were using the old school and for example, when you go there, you tell them about the DevOps philosophy. It is directly related to ideal methodologies. And for them it was a very revolutionary change. And the teams that were working there, they were developing and deploying solutions. The old school for sure were not ready for that change. And these people, these developers belong to our own company. So we were trying to change the mindset of the client with people working for us in the client. And this was far more difficult because we had this. These people who didn't believe in the project didn't support us. They thought that we were trying to provoke problems internally with this philosophy and so on. So this was very difficult because we had the enemy in our house, in our house. That's part of the problem, OK? At the very beginning, we prepare one proposal for the client with the idea, the main idea of the project. And we spotted the first person in the client that didn't want to know anything about the breed, especially in the testing part. And the person who was in charge of explaining that had to shut up because the other person didn't let her to continue with the presentation. So we needed to skip that part and go 10 slides later in order to continue with the presentation. So something like that. From the very beginning, the first contact with the client was very embarrassing to say the least. For us, that's one of the examples. But in the end, it was a matter of trust. They didn't trust us. They didn't know how we were working the kind of projects that we were accustomed to roll out to rolling out. And after three or four or five years that trust was fixed and everything was easier because, for example, Cornelius, they didn't want to listen the word cloud, everything on premise. So cloud was a forbidden word for them because of the relations. And in the end, they have, they haven't fallen behind others and they are trying to move little by little to these kind of concepts. But you have resistance from minute one and this happens a lot of times. Speaker 1 Right. I understood the opening then you skipped five years. Everything, everything works now, right. So I think that the important bit is that, that, that one to two months, maybe 3 months, they're at the beginning, right? You are at the client, it's clear they don't want you. What did you do? How did you get the conversation started? What? What was it at at that point? Did you, was it just constant communication? Was it was it presentations? Was it talking to the sponsors? What did you do there at that crucial moment when you realized, Oh my God, they don't want us, but we have to do this? How did you approach it? Speaker 2 Well, this is very important. The task that for example the contract manager in this case with the different sponsors in the other side have to expose what's currently happening, why this opening has been in that way or not. And after that, from our side, we need to approach to the direct stakeholders that we have at the moment. So they need to be our main supporters. They are supporters too, but they have resistance within the company. And the, the, the main idea is to go with them with different stakeholders, try to sell the solution. Why this is beneficial or not? The lack of advantages or features that they need in order to perform the the the jobs. Maybe the reasons why they have to change or in training is vital to in this case. So you need to spend one session, 2 sessions, even 3 sessions when they write to you, when they text you, this is not working. What can I do? Maybe there are a lot of possibilities. The first one is, I have said to you this thing five times and you are asking me again the same. Yes, that's one possible option. But if you do that, you are generating this resistance. So the main idea is to be with them, try to solve their problems, try to show yourself supportive, try to understand what they have, the problems that they have, how can I help you and something like that. So there is a lot of effort in trainings, in approaches, in meetings, internal meetings with with a client for sure. And these your direct supporters, your sponsors. Speaker 1 OK. Speaker 2 And this in the middle five times time, Cornelius. Speaker 1 Yeah, it takes time, obviously, right. So that's your project case story, your success story, and I think where we're going next is probably one of the most important places we need to go. Cultivating Empathy and Patience: Core Change Leader Skills And that is the change leader skills, because it's easy to talk about, oh, you have to do this, you have to do that. In your opinion, what are the core skills that really separate an effective change leader from somebody who is just a A technical project manager, shall we say here? Speaker 2 In this case, for me, it's, it's very important what software skills mean. I mean empathy, patience, active listening, productivity. That's what we call a coach or something like that. Because if you don't have that skills, the project might fall apart, as I have said before. And not everything or not everyone has or possess these abilities. And, and yes, you have mentioned that, for example, technical career leaders don't have these qualities. And that's real because sometimes clients prefer technical career leaders because they know about technology, they understand perfectly the reasons. But in this case, you don't need that because if you don't have those abilities, that's a failure for sure. And I have had a lot of conversations with clients with respect to this because they wanted a technical career leader. But you have that maybe technically everything is perfect, but in the end, they don't have the ability to communicate or to convey to different audiences from the same company the same message. And then, and that's another topic, yes, but in a nutshell, what you need is soft skills. Try to understand the client and accompany him or her or a lot of stakeholders and try to do your best. That's a main idea sometimes. How? Speaker 1 Do I build? Yeah, go ahead. Speaker 2 They don't know what they want. Speaker 1 That's the clients. Speaker 2 Exactly. Maybe they give you some general requirements but the change in time, but they don't, they don't know what they want. And this is very important too. So you need to help them find what they really want. And it takes some time, two months, two weeks or even 2 years if needed, depending on the client. And that's part of the problem too. Speaker 1 So these skills that I need to be still a good technical project leader, but also have the soft skills that bring me more into the change leader area of of managing the project. How did you acquire them? What did you do personally? Do you have any recommendations from your own experience for our listeners here? This is how I strengthened my listening skills. This is how I strengthened my conversational skills with the client. What did you do that our audience can take from you and learn from you? Speaker 2 First of all, to stay calm so. Speaker 1 Everything. Speaker 2 This is very important and you need to understand that you are trying to build something for someone else and you need to adapt to them and adoption. This mindset is very important. It has to do with agility too, because in AI we're accustomed to changing things on a daily basis or in a minute basis if needed. And that's very difficult for some people because they don't want to change. They don't have these skills, and this is part of your personal traits. Sometimes I think that it's very difficult to acquire them with time. Some people might have it because of experience, because of the aids, but if you don't have them, I guess that it is very difficult to have them in the long run. In the long run, yes. Speaker 1 Thank you very much. Thank you very much. We have come to the end. Engage Early, Stay Calm: Post-Launch Support and Final Wisdom We are on my take action slide here with the arrow pointing us into the right direction. So the arrow, that's you Mario. Please point our, our audience into the right direction. Share maybe 2 ideas with us. What can we do to embrace what you have suggested and move forward? Speaker 2 For me, we have discussed about this topic in this 37 minutes and the most important thing is to engage everyone from minute one because you don't know what you are going to face in the future. So the sooner the better. And the second one is the sentence that I have said in the last minute is to stay calm. You need patience. You need to understand what the other wants. And this is a service mentality. So you serve the others depending on the role that you have, but you have to serve them to build something for them. You need to get paid in the end. That's the idea. So these are my main ideas. Identify all the stakeholders from the very beginning and keep calm. Speaker 1 All right. Thank you very much. Before we part ways and say our goodbyes, we just had a comment. Comment, not a question, just a comment from Jean Bourgos. Mario, it's funny you mentioned the customer doesn't know what they want. Meeting requirements on paper and delivering on the need may not scratch the itch. And this is something that all of us have seen so many times. You work with a customer that the requirements are down and then you realize, you know what, this is probably not exactly what they want and need because nobody is supporting what we are doing here. Is that about it? Speaker 2 Exactly. In this case, this is very typical. Or maybe they have written that in the paper, but maybe they don't. They didn't want to write that. Or maybe they have changed their mind along the time. Maybe they deny what they have said to you. If it is written, they can't deny it, but if it is oral, they say that. So you need to keep track in of different meetings with minutes and so on in order to know what they have said in the past. Speaker 1 Wonderful, Mario. Thank you so much for joining us today and showing us the importance of staying calm. Much appreciated. Speaker 2 Thank you very much, Cornelius, and the rest of the audience. Speaker 1 All right, everybody, thank you so much for being here. As always, please do visit pm-podcast.com slash 531 for show notes, transcripts, and our e-mail addresses [email protected]. You will be able to claim PD US in the power skills area. Looks like about half APDU that you can get and without having read it before or got another comment that just arrived here. Let me bring this up and read it live on the air by Crystal Sharp. Great session. I've been in my fair share of implementations where support after a project's completion is not kept up as it should be. I love Mario's perspective on how to keep the feedback loop open in the event additional resources or amendments are necessary after project completion. So Mario, we're going back. Welcome back to the program. So even though we've, we've already closed things off, thank you, Crystal for the question. So Mario, your perspective, how do you keep the feedback loop open in the event of additional resources amendments are necessary after the project is already completed. What is your? What is your take here? Speaker 2 In my my take on my stance in this case we have to do what the client wants. That's my idea. So if they want to add additional resources or amendments, in the end, that's good for us because that means new job, new works and new money. That's it. Yeah. So. Speaker 1 Exactly. Yes, it's an additional project, right. So in, in my perspective as well, you've closed off your project, they come back and you're like, well, yes, this is a new project. Let's develop the new project plan together and, and have a contract and sign it and, and, and move forward from here. That's kind of how I see it. Speaker 2 I have to raise one issue, for example, Cornelius, because technical people don't understand this change in a very good way because they are accustomed to developing something and when the client comes and says to them you have to change it, yes, but I don't want to change it because it has taken me a lot of time. Yes, for sure. But the client is the person who has, who is paying for you. So if you have to change it, you need to change it. Speaker 1 Right. Speaker 2 And depending on the lead, you understand this message better or worse in my opinion. Speaker 1 I agree. Yes. All right, once again, thank you, Mario. And we are moving on with closing our episode here and we have reached the and finally we have this. This time it's a meme. If you're listening to this in audio again, you may want to watch this as a video. It's a 2 button meme that every project manager faces when resistance knocks. Button one is labeled Engage stakeholders early. Button 2 is labeled Avoid awkward conversation until the go live. Which one would you press until next time?