Month: January 2019

I’ve seen the same pattern more than I can count: an organization attempts a major technology implementation — ERP system, product platform overhaul, digital transformation initiative — it fails, and two years later they try again. Same system, same organization, different consultants. Same result.

The technology wasn’t the problem the first time. It wasn’t the problem the second time either. The problem was change management, or more precisely, the lack of it — and the failure to understand why change management isn’t a soft skill added to a hard technical project. It’s the difference between a successful implementation and an expensive, trust-destroying failure.

The Hidden Costs of Implementation Failure

When a major technology or process implementation fails, the obvious costs get tallied quickly: sunk project costs, missed timeline penalties, rework expenses, consultant fees. These are painful and visible.

The costs that organizations consistently underestimate are the organizational ones, and they compound over time in ways that make the next change effort significantly harder:

Leadership credibility decreases. When a senior team sponsors a major initiative that fails, the implicit contract between leadership and the organization frays. People watched leadership commit to something, invest resources, and deliver failure. The next time leadership asks for commitment to a change initiative, the organization will move slower, push back harder, and require more proof before investing. This isn’t cynicism — it’s rational self-protection. And it directly reduces the organization’s capacity for future change.

Resistance to change increases. Every failed implementation adds to the organizational body’s immune response to change. Future initiatives — even well-designed, appropriately resourced ones — will encounter stronger resistance because the organization has learned, experientially, that change initiatives hurt. You cannot logic your way around this with a better deck or a stronger business case. The resistance is embodied, not rational.

Future implementations become more expensive. Perhaps the most counterintuitive cost: a failed implementation doesn’t just cost you the project. It costs you a premium on every future project. More stakeholder management time, more political overhead, longer buy-in cycles, higher tolerance thresholds before people will actually change behavior. Organizations that have failed at change repeatedly don’t need better technology — they need a change methodology that addresses the organizational damage first.

The Business Case for Change Management Methodology

Change management methodology is the structured approach to moving an organization from a current state to a desired future state — not just technically, but behaviorally and culturally. It’s the difference between a system going live and a system actually being used.

The business case for investing in it comes down to three levers:

Delivering on timeline. In most competitive markets, speed is the multiplier. The organization that implements a strategic change faster than its competitors captures the first-mover advantage. Organizations that don’t manage change effectively consistently miss timelines — not because of technical delays, but because behavioral adoption lags behind technical deployment. The system goes live; the workflows don’t change. The result is a parallel system running alongside the old one at full cost with none of the intended benefit.

Delivering within budget. Change is one of the most resource-intensive activities an organization undertakes. The software cost is typically the smallest part — implementation cost, training cost, productivity loss during transition, and the cost of prolonged adoption curves all dwarf the license fee. Organizations with mature change management capability spend significantly less on the non-technical costs of implementation because they’ve learned how to move people efficiently.

Meeting the actual strategic objective. Most strategic change initiatives are designed to deliver a specific business outcome — improved efficiency, better data quality, faster decision-making, lower costs. The technical implementation is a means to that outcome, not the outcome itself. Change management methodology keeps the team focused on the behavioral adoption that actually delivers the business outcome rather than the technical go-live that creates the illusion of success. The research on this is clear: Prosci’s change management ROI research consistently shows that projects with excellent change management are six times more likely to meet their objectives than projects with poor or no change management.

What a Change Management Methodology Actually Does

A change management methodology isn’t a communication plan and a training schedule. Those are components. A methodology is a structured approach that addresses the full behavioral adoption curve — from initial awareness that change is coming, through active resistance, to genuine adoption, through to institutionalization of the new behavior as the default.

The organizations that are consistently good at implementing major changes share a few characteristics: they start change management planning at the project design phase, not after the technical team has already built the solution. They invest in understanding the specific resistance patterns that will emerge in their particular organization, rather than applying a generic communication template. They measure behavioral adoption, not just technical deployment — and they treat lagging adoption as a project problem requiring active intervention, not as a user training failure.

Most importantly, they’ve stopped treating change management as optional overhead that gets cut when the project is over budget. They’ve learned, usually through expensive failures, that the change management is the implementation. The technology is the tool. The behavior change is the project.

Your Turn: Apply This Today

Whether you’re leading a major change initiative or planning one, here’s how to strengthen the change management foundation:

• Audit your last three failed or underperforming change initiatives. For each one, identify specifically where adoption broke down — was it awareness, willingness, or capability? The diagnosis determines the intervention. Most teams blame the wrong failure mode and design the wrong solution.
• Start change management planning at the project design phase. If you’re currently starting change management after the technical team has built the solution, you’re six months behind. The change management plan should be drafted alongside the project charter, not after the go-live date is set.
• Build behavioral adoption metrics into your project dashboard. Define explicitly what “success” means in behavioral terms — not “system is live” but “X% of users have completed Y key workflow in the new system by Z date.” Track it from day one post-launch. Treat it with the same urgency as technical performance metrics.
• Identify your resistance pattern before the announcement. Before any major change initiative is announced, map the likely sources and drivers of resistance in your organization. Which groups will object? What are their legitimate concerns? Design the engagement plan around the actual resistance, not a generic one.
• Calculate the organizational debt from previous failures. Estimate the premium your organization pays on change initiatives because of past failures — the extra stakeholder management time, the longer buy-in cycles, the higher proof threshold. Make this cost visible to leadership. It’s the most powerful argument for investing in change management methodology upfront.
• Establish a “change management review” before major project commits. Add a standing agenda item to major project approvals: “What is our change management plan, and what is our adoption success metric?” If the project can’t answer both questions before it’s approved, it’s not ready to start.

Change management at the organizational level connects directly to product leadership transitions — the first 100 days as a product leader in a legacy institution requires the same behavioral adoption discipline applied to your own stakeholders. And the ethics dimension of product decisions is often where change management fails — when the change being managed isn’t actually in the organization’s or users’ best interests.

Leading a major change initiative or product transformation and finding that the technical implementation is ahead of the behavioral adoption? I consult with organizations on change management strategy, adoption acceleration, and building the organizational capacity for sustained change. Let’s talk.