Therapy of a CIO Round 2

0:00Welcome to Digital Stratosphere, the podcast that helps organizations throughout the world with their digital transformation journeys. Here, you will find independent and technology agnostic advice with no software vendor sales spend to help you make the best decisions for your organization. Whether you are in the process of selecting technology, in the midst of your transformation, or trying to get your initiative back on track, Digital Stratosphere provides expertise and best practices to help. Welcome back. It's good to see you again. Now things have been since our last session. Honestly, a lot worse. Sorry to hear that. Last time we talked, we were feeling overwhelmed by the ERP project, the vendor pressure, the internal politics, the lack of alignment. Did any of the things we discussed help? Some of it did actually. I tried pushing back on the system integrator. I tried taking more ownership of the project, but then a whole set of new problems showed up that I wasn't expecting, and some of the old problems got worse.

1:02Now tell me about that. What's gotten worse? Mainly change management, or should I say the complete lack of change management. When we first kicked off the project, the vendor assured us they would handle organizational change management. They said it was built under their methodology. They said they had it all covered, and they didn't. Not even close. Their idea of change management turned out to be sending a few company-wide emails, pulling together some generic system training materials, and checking a box on the project plan. That's it. No stakeholder engagement strategy, no communication plan, tailored to different groups. No effort to actually understand how the change would impact people's day-to-day work. Nothing. So what happened? Exactly what you just expect. The people weren't prepared. The training was boilerplate, generic screenshots, and clipped through guys that didn't reflect what our business actually operates. Employees showed up on day one of testing, and they had no idea what they were doing. They didn't understand what processes were changing. They didn't understand what was expected of them.

2:02And when things got confusing, there wasn't adequate support to help them through it. That sounds like a recipe for resistance. It is, and that's where it gets frustrating, because the vendor is turning around and blaming our people. They're telling the steering committee that the problem is user resistance, and that our employees just don't want to change. They're literally labeling our people as the problem when the reality is that nobody ever prepared them for what was to be coming. So they failed to prepare people, and they're blaming your people for not being prepared? Yeah, exactly. That's the cycle we're stuck in, and it gets worse. Every time we flag a gap, the training isn't relevant, the communications are too generic. People don't understand the new processes. The vendor response is always the same. They just say, your people are resistant to change. It's become the new catch excuse, catch phrase for everything that seems to go wrong. The software doesn't work the way we need it to. It must be resistance to change. The new process is actually less efficient than the old one, resistant to change. People are confused because nobody explained the why behind any of this. They must be resistant to change. It's the same refrain through and through. That sounds like gas lighting.

3:09Yeah, that's exactly what it is, and the worst part is it's working. The board is starting to believe it. The vendor has direct access to our executives, and they're telling them that the technology is fine, the methodology is fine, and that the real issue is the organizational culture. So now I've got my own leadership team questioning whether or not our people are the problem. How does that make you feel? It's infuriating because I know the people. They're not resistant to change. They're resistant to bad change, but they're not resistant to change. They're resistant to being told to adopt new processes that nobody bother to explain. They're resistant to training materials. They have nothing to do with how they do their actual jobs. They're resistant to being ignored when they raise legitimate concerns, and then being told that the problem is their attitude. It just doesn't make sense. That's an important distinction. There's a difference between people who don't want to change and people who haven't been given the tools to change. Right, and the research backs us up. The number one root cause of ERP failures and the technology, it's that the people aren't prepared to adapt new processes. The technology usually works, but it's the human side that gets neglected, and that's exactly what's happening here with us.

4:11So the vendor took responsibility for change management, underdelivered, and is now deflecting the consequences on to your team. What about the systems integrate? Are they doing any better? They're part of the problem too. They're masters of avoiding accountability. They know we don't have the internal experience to look behind the curtain of how they're managing the project. So they control the narrative. The status reports all green until suddenly it's a red one day. Risk that should have been flagged months ago, show up out of nowhere. Milestones get missed and nobody escalates it to the steering committee until it's too late. It sounds like the fox guarding the head and house. You said something similar last time. It is, and I did say something about that last time. They've gotten even more aggressive since our last session. They're pushing incredibly hard to go live on the original date, even though we're not anywhere close to being ready. Our people aren't trained. Our data hasn't been migrated cleanly. We haven't done adequate user acceptance testing, but the integrator keeps telling us that we're ready and keeps pushing us into this goal live. Why do you think they would push so hard to go live if you're not ready? Well, because their contract is structured around milestones.

5:16The faster we go live, the faster they get paid, and they move on to the next client. They don't bear the consequences of a bad goal live. We do, but they don't. They'll be long gone by the time things hit the fan. We're the ones dealing with the operational disruption, confused employees, angry customers, and a system that doesn't work the way it should. And the software vendor, same incentives? Yeah, even more so. Once we go live, the subscription revenue kicks in, they start collecting their annual fees whether the system works or not. So they're just pushing us just as hard. The vendor and the integrator are actually aligned on this. Just go live as fast as possible. That's what they want regardless of whether or not we're actually ready. And what's your incentive? Well, our incentive is to get it right. We want to minimize operational disruption, make sure people can actually do their jobs in the new system, get real business value from the investment, you know, the things that should matter. Those are two very fundamentally conflicting incentives. They are, and nobody talks about it openly. It's this unspoken dynamic that drives the entire project. The vendor and the SI are optimizing for speed and revenue.

6:22We're trying to optimize for outcomes. And when those two things collide, we lose because they control the project plan, the milestone, and the narrative to the executives. If you are trying to achieve digital transformation success, turn to third stage consulting group. Third stage is independent and technology agnostic consulting team, helps clients define their digital strategies, select the right software, and manage their implementations. With offices in the US, Europe and Australia, our team helps the world's most forward thinking organizations through their transformation pitfalls and risks, whether you are embarking on an ERP, HCM, CRM, Supply Chain Management, or any other digital transformation. Contact third stage consulting to see how we can help you reach the third stage of transformation success.

7:24Let's go back to change management for a moment. You said the vendor's approach was inadequate. If you could design it yourself, what would real change management look like? It would start much earlier for one thing. You can't wait until three or four weeks before we go live before we start preparing people. It needs to begin during planning, helping people understand what's changing, why it's changing, what it means to their specific roles, not generic, company-wide blast, targeted, relevant communication for different audiences. What else? Real training, hands-on training, and realistic scenarios reflect our actual business processes, not just how to click through the software and do transactions in the system. People need to understand the end-to-end process, not just their individual screen, and you need ongoing support for GoLive, not just to help desk email that nobody responds to. You need champions, people that are embedded in the business who can help their colleagues through the transition day to day. It sounds like you've thought about this quite a bit. I have, because I've seen what happens when you get it wrong. People lose confidence, they lose trust, they start doing work-arounds, and go back to the old way of doing things. And then leadership looks at the adoption numbers and wonders why the multi-million dollar system isn't being used.

8:27The technology works, the people were just never set up to succeed. Okay. Now, you mentioned earlier that the board is starting to buy the vendor's narrative about resistance. How are you handling that? Pretty badly, actually, because the vendor has more access to the board than I'd like. They do these executive steering committee presentations where everything looks polished and under control. They use all the right buzzwords. They talk about organizational readiness and adoption curves and business value. Without actually doing the work behind the concepts, and then the board eats it up, it sounds like it's very professional and reassuring when they hear it. And what happens when you present a different picture? I look like the pessimist. I'm not the expert in these projects, and so I must be wrong. And that's the perception that they give. I look like I'm the one who's slowing things down. The vendor has positioned themselves as the expert, so when I push back, it comes across as me not trusting the process. But I'm not pushing back because I don't trust the process. I'm pushing back because there is no process. Not a real one that works for us anyway. That's a very isolating position to be in. It sounds like it is, and the integrator makes it worse.

9:30They've got the subtle way of undermining our internal team. They frame everything as the client's responsibility when it fails and our methodology when it succeeds. They do things to the organization rather than with the organization. And when they eventually leave, we won't have built any internal capability. Everything will fall apart because they never transferred the knowledge to our team. They just executed tasks and they moved on. And that's a pattern you've seen in these relationships before? Yeah, constantly. When a vendor owns everything, you've got nothing but risk. You become completely dependent on them and they know it. The dependency is just part of their business model. The more dependent you are, the harder it is to hold them accountable or to let them walk away. Now, have you considered bringing someone independent, someone whose incentives are aligned with yours rather than the software vendors and the system integrators? I've thought about it. Last time we talked, you suggested the same thing. The problem is the integrator fights it. The last thing they want is an independent set of eyes looking at how they're running the project. They'll push back hard on any sort of third party oversight.

10:33Wow. Why do you think that is? Because I think they know what an independent review would find. The gaps in change management, the mis milestones that were escalated. The training that was compressed by 50% because of the milestone and the timeline skip shifting. The status reports that painted a rosy picture while the project was quietly falling apart underneath. They don't want someone pulling back the curtain. So their resistance itself is a red flag. A massive one. And I think that's the thing I've struggled with the most. I keep second guessing myself because the vendor and the integrator are so confident and they're so polished, they're so certain that they're right. And when you're outnumbered and everyone around seems to agree with them, start to wonder if maybe you're the problem. Maybe you're the one that's resistant. Maybe you're not being flexible enough. Maybe you just don't underestimate or understand how the projects are supposed to work. But you do understand how they work. You've seen the data. You know the failure rates. You've lived through the consequences of what happens when you skip the hard work of preparing people for change. That's not resistance. That's wisdom.

11:33I appreciate you saying that. It's hard to hold on to that perspective when you're in the middle of it. Well, let me tell you what I'm hearing. You're not dealing with a team that's resistant to change. You're dealing with a team that was set up to fail by partners who overpromised on change management under delivered on training communication. And they're now deflecting the blame onto the people they were supposed to support. That's not an organizational problem. That's a vendor accountability problem. Well, when you put it that way, it does seem so obvious. It usually does from the outside. The hard part is seeing it clearly when you're inside the pressure cooker. So knowing what you know now, what are you going to do about it? I think I'm going to stop accepting the vendor's narrative. I need to go to the board with data, not opinions, but real data about where change management has failed, why adoption is low, and what needs to happen to fix it. And I need to push for an independent assessment of the project before we get much further. And what about the go-live date? Well, we know it needs to move. I know that's going to be an uncomfortable conversation. The vendor will fight it. The integrator will fight it. The board won't love it.

12:37But going live before a ready will cost us 10 times more than a delayed go-live. I've seen the research over half of the projects experience some sort of operational disruption after go-live. And the ones that are hardest hit are the ones that are rushed before the people are ready. That takes a lot of courage. Are you prepared for the pushback that you think you might get? I think I have to be. This is our company. This is my team. These are real people whose jobs and livelihoods are affected by whether or not we get this right. The vendor in the integrator will move on to the next client where the ones that have to live with the consequences. That's exactly right. And I want you to remember something else. When someone tells you that every problem is your fault and that you just need to trust the process, that's not a partnership. That's control. A real partner helps you build the capability to succeed on your own. They work with you, not to you. That's a real powerful way to put it. I think I've been so deep in this that I lost what a healthy vendor relationship is actually supposed to look like. That's understandable. These dynamics are designed to keep you off balance, but you're seeing it clearly now and that's the first step to changing it.

13:39Thank you, Doctor. I actually feel a little better this time. No good. So see you the same time next week. Absolutely. Assuming the integrator doesn't try to build me for that session too. Let's hold that. Learn more about us and download independent reports, videos, and other best practices at thirdstage-consulting.com.