PROSCI in M&A: Beyond the Certification

The team had done everything right. Sponsor identified. Stakeholder analysis complete. Change network activated. Communications calendar populated with a color-coded content plan stretching three months into the future. Textbook execution. Beautiful, even. The kind of deliverable set that would earn a standing ovation in a certification class.

Adoption cratered six weeks after go-live.

The post-mortem was illuminating. The sponsor had signed the charter but never once walked the floor. The change network existed on paper but hadn’t met since training ended. The communications were grammatically perfect and strategically useless: they described the system in detail and the impact on people not at all. The methodology was followed with religious precision. The craft was entirely absent.

I’ve been PROSCI certified since 2012. I believe in the framework. But after dozens of enterprise transformations, I’ve learned that the distance between “certified” and “effective” is vast, and it’s populated almost entirely by things the certification doesn’t cover. Here’s what experience teaches that the three-day course doesn’t.

Most sponsors don’t know how to sponsor

PROSCI’s research is clear: active executive sponsorship is the top predictor of success. Projects with strong sponsors succeed nearly 80% of the time. Projects with weak sponsors fail at the same rate. (We built a sponsor effectiveness scorecard to measure this, because gut feelings about sponsorship quality are worth exactly what you’d expect.) This finding is cited in every certification class, every keynote, every consulting proposal ever written. It’s one of the reasons 70% of transformations fail.

And yet, in my experience, maybe one in five sponsors actually sponsors effectively. They show up at kickoff. They record the launch video. They appear at the town hall, read three slides that someone else wrote, take two questions from people who were planted in the audience, and then vanish into their real jobs while the project team fights the organization alone.

The uncomfortable truth is that most executives have never been taught to sponsor. They’ve rarely seen it modeled. Nobody sponsors well instinctively, for the same reason that nobody manages well instinctively: it’s a skill that requires practice, feedback, and a willingness to be bad at it for a while. And the change team is usually too intimidated, or too politically savvy, to name the gap. Telling a SVP that they’re bad at sponsorship is a career decision. Most people choose the career.

What does real sponsorship look like in practice? Decisions made weekly, not monthly. Peer relationships actively managed behind closed doors. Convincing skeptical SVPs over coffee, neutralizing blockers before they become public opponents, building coalitions that the project team never sees and shouldn’t have to. Consistent messaging when things get hard, especially when things get hard. And most importantly: actually talking to impacted people. Not staged town halls with screened questions. Break rooms. Slack threads. The hallway after a difficult meeting where someone is visibly upset. That’s where sponsorship happens.

If your sponsor isn’t doing these things, you don’t have a sponsorship problem. You have a project viability problem. No methodology compensates for absent leadership. PROSCI can’t fix this. Kotter can’t fix this. Nothing in any framework fixes the fundamental issue of a leader who agreed to sponsor a program and then didn’t.

ADKAR is a diagnostic, not a recipe

The ADKAR model (Awareness, Desire, Knowledge, Ability, Reinforcement) is genuinely useful. When adoption lags, it helps you locate the sticking point. People don’t understand why we’re changing? That’s an Awareness gap. They understand but don’t want to participate? Desire. They’re willing but can’t execute? Ability. It’s a good lens. I use it constantly.

The problem is when practitioners treat ADKAR like a sequential recipe: first create awareness, then build desire, then deliver training, then reinforce. As though human beings process change in tidy phases, like software with version numbers. That’s not how humans work. That’s not how anything works.

In practice, these elements shift constantly. Someone starts with strong desire that evaporates the moment training reveals how hard the change will actually be. (“You want me to learn what by when?”) Another person builds ability through practice but loses it without reinforcement because nobody checked in after week three. The model is a lens for diagnosis, not a checklist for delivery. The certification teaches it as both. It’s only the first.

I’ve seen teams pour months into awareness campaigns when the real barrier was ability. People knew about the change. They wanted to participate. They’d been trained. But they couldn’t execute in their actual work environment because the training bore no resemblance to the messy reality of their daily jobs. The practice environment had clean data and simple scenarios. The real environment had exceptions, edge cases, and a legacy system that was supposed to be retired but wasn’t. Diagnosis before treatment. Always.

Resistance is usually intelligence

The standard framing: 20% embrace change, 60% wait and see, 20% resist. Change management should convert the middle and manage the resisters.

Different take: resistance is often the most valuable signal in the system. And managing it is often the worst thing you can do with it.

When a tenured employee pushes back on a new process, they’re usually not being difficult. They’re surfacing information the design team missed because the design team has been in a conference room for four months and hasn’t done the actual job since the Clinton administration. “This won’t work because customer X always needs exception Y” isn’t resistance. It’s requirements. “We tried something similar in 2019 and here’s what happened” isn’t cynicism. It’s institutional memory. The people closest to the work understand its complexity better than anyone designing from two floors up.

Instead of resistance management, think intelligence gathering. Create channels for concerns to surface and be genuinely evaluated, not captured and categorized and filed in a tracker that nobody reads. When people see their input changing outcomes, commitment follows. When they see their input going into a box labeled “stakeholder concerns” that gets reviewed monthly by someone they’ve never met, resistance hardens. Can’t imagine why.

Training is necessary but wildly insufficient

Knowledge and Ability are the ADKAR phases that get the most budget and the least impact. Organizations love training because it’s visible, measurable, and feels productive. You can count the hours. You can track completion rates. You can put a pie chart on a slide. None of this tells you whether people can do their jobs after go-live.

The pattern I see: elaborate training programs. Thousands of hours invested. Completion rates tracked obsessively. (“97% of impacted users have completed training!” Great. Did it work? “…97% completed it!”) Then go-live happens and people can’t do the work. The training taught the system. It didn’t teach the job. Those are different things.

Effective capability building looks different. It starts with impact analysis by role. Not generic overviews but specific “here’s what changes for you on Tuesday.” It includes manager enablement so supervisors can coach their teams through the rough patches instead of forwarding the help desk number. It builds practice environments that mirror real work, with all the ugly exceptions intact. And it continues past go-live with just-in-time support when people get stuck in the middle of their actual day on their actual tasks.

The methodology isn’t the point

PROSCI is a good framework. So is Kotter. So is ADKAR on its own. The methodology you choose matters less than the craft you bring to it, in the same way that the programming language matters less than whether the engineer understands the problem.

What matters: understanding human psychology. Building genuine relationships with people who have no obligation to trust you. Navigating organizational politics without becoming political. Communicating clearly under pressure. Adapting when the plan meets reality and reality wins, which it always does, usually around week three. The first 100 days of an integration are where methodology meets craft, and craft wins every time.

The practitioners I respect most use frameworks lightly. As thinking tools, not religious texts. They adapt to context, challenge orthodoxy when it doesn’t fit, and ultimately measure success by outcomes rather than process compliance. “We followed the methodology perfectly” is not a defense when adoption is at 40%.

PROSCI certification teaches you the model. Experience teaches you when to deviate from it. The certification takes three days. The experience takes years. I wish the ratio were different, but it isn’t.

---

If you’re planning a transformation and want experienced guidance, not just methodology but judgment, let’s talk. We also offer advisory services for organizations navigating complex integrations.