Most failed initiatives don’t fail because the strategy was wrong or the technology didn’t work. They fail because the organization didn’t change.
The new system gets implemented, but people find workarounds to keep doing things the old way. The process redesign gets rolled out, but adoption stalls at 30%. The strategic priority gets announced, but six months later, daily work looks exactly the same.
This is the change management blindspot: the assumption that good solutions will be adopted simply because they’re good. They won’t. Adoption is a separate problem that requires separate attention.
Why Change Fails
Organizations are complex systems with significant inertia. People have established routines, relationships, and mental models. Systems have embedded assumptions and interdependencies. Culture has unwritten rules about how things get done.
Change initiatives collide with this inertia, and inertia usually wins.
Habits are powerful. People don’t consciously choose to resist change. They default to familiar patterns because that’s how habits work. The old way of doing things is automatic; the new way requires conscious effort. Under pressure, people revert to what they know.
Incentives don’t align. The change may benefit the organization, but does it benefit the individuals asked to change? If the new process creates more work for someone without corresponding reward, they’ll resist, not out of malice but out of rational self-interest.
The case isn’t clear. Leadership understands why change is necessary. The people who have to change often don’t. Without understanding the “why,” change feels arbitrary: something imposed from above rather than something worth doing.
Capabilities are missing. Change often requires new skills. If people don’t know how to operate in the new way, they can’t adopt it even if they want to. Training is often underinvested or delivered too early to stick.
Systems reinforce the old way. Processes, tools, reporting structures, and performance metrics were designed for the old way of working. Until these systems change, they create friction against new behaviors and support for old ones.
Research from McKinsey consistently finds that 70% of change programs fail to achieve their goals.1 The failure rate hasn’t improved significantly despite decades of attention to change management. The problem persists because organizations consistently underestimate how hard change actually is.
The Blindspot in Practice
Change management is often treated as a communication problem. Leadership announces the change, HR sends emails, there’s a town hall meeting, maybe some training. Then the organization expects adoption to happen.
This approach addresses one factor (clarity on what’s changing) while ignoring the others. It assumes that if people know about the change, they’ll make the change. That assumption is almost always wrong.
Consider a common scenario: a new CRM system implementation. The technology works. The data is migrated. Training is delivered. Go-live happens on schedule. Success, by project metrics.
Six months later, adoption is partial at best. Sales reps maintain their own spreadsheets alongside the CRM. Data quality is poor because fields aren’t being filled out consistently. The reporting that justified the investment isn’t reliable because the underlying data isn’t there. The system is technically live but operationally failed.
What went wrong? The project delivered software. It didn’t deliver change.
The sales reps weren’t involved in defining requirements, so the system doesn’t fit their workflow. Their compensation isn’t tied to CRM usage, so there’s no incentive to adopt. Their managers don’t use CRM data in reviews, so there’s no accountability. The old spreadsheets still work, so there’s an easy alternative. Every force is pushing against adoption.
Building Change Into Initiatives
Effective change management isn’t a phase at the end of a project. It’s a design consideration from the beginning.
Involve affected parties early. People support what they help create. Involving end users in requirements, design, and testing creates ownership that communication alone cannot. It also produces better solutions because the people who do the work understand it better than anyone.
Design for adoption, not just functionality. A solution that’s technically optimal but practically unadoptable delivers no value. Consider adoption requirements alongside functional requirements. How will people learn this? What will make them want to use it? What barriers will they encounter?
Align incentives explicitly. What’s in it for the people who have to change? If the answer is “nothing” or “more work,” adoption will struggle. Find ways to make the change beneficial, or at least not harmful, to the individuals involved. Remove disincentives where possible.
Invest in capability building. Training is necessary but rarely sufficient. People need practice, support, and reinforcement over time, not a one-time session weeks before go-live. Build learning into the transition period and provide ongoing support as people encounter real-world challenges.
Change the surrounding systems. If you want new behaviors, change the systems that shape behavior. Update metrics to reflect new expectations. Modify processes to support new workflows. Adjust reporting to use new data. When the environment reinforces the new way, adoption becomes easier.
Make the old way harder. Sometimes adoption requires removing the alternative. If the old spreadsheets remain available and functional, they’ll continue to be used. Retiring legacy systems, even when uncomfortable, can be necessary to force transition.
Leading Through Change
Change management isn’t only about systems and processes. It’s fundamentally about leadership.
Model the change visibly. If leaders don’t use the new system, attend the new meetings, or follow the new process, why should anyone else? Visible adoption by leadership signals that the change is real and expected.
Acknowledge the difficulty. Change is hard. Pretending it isn’t breeds cynicism. Leaders who acknowledge the challenges, validate frustrations, and recognize effort build trust that enables persistence through difficulty.
Maintain consistent attention. Change initiatives often start with energy that dissipates over time. Leadership attention moves to the next priority; the organization interprets this as permission to deprioritize adoption. Sustained attention (asking about progress, addressing obstacles, recognizing success) signals that the change matters beyond the announcement.
Address resistance directly. Resistance isn’t always irrational. Sometimes it signals legitimate problems with the change itself. Sometimes it reflects fears that need to be addressed. Sometimes it’s simply habit that needs to be broken. Diagnosing the source of resistance enables appropriate response.
Create accountability. Ultimately, change requires expectation. If adoption is optional, many will opt out. Clear expectations, measured progress, and accountability for results make change a requirement rather than a suggestion.
The Real Work
The change management blindspot persists because the real work of change is harder and less glamorous than the technical work it accompanies. Building a system is tangible; changing behavior is ambiguous. Implementing a process is finite; sustaining adoption is ongoing.
Organizations that succeed at change treat it as the primary challenge, not a secondary consideration. They staff for it, plan for it, and lead through it with the same rigor they apply to technical delivery.
The initiative isn’t done when the system goes live or the process is documented. It’s done when the organization has actually changed.
Citations
1 McKinsey & Company, "How to beat the transformation odds," 2015; updated findings in subsequent research confirm similar failure rates.