You did the research. You sat through the demos. You checked the references. You negotiated the contract. You wrote the check. The new software was going to transform your operations — faster scheduling, better tracking, real-time visibility, fewer errors.
Six months later, half your team is still using the old spreadsheets. The project managers enter data into the new system reluctantly, usually days after the fact, and only because you've asked three times. The field crews have the app on their phones but haven't opened it since the training session. Your office manager has quietly built a parallel tracking system in Excel because "the new system doesn't work the way we need it to."
You didn't buy shelfware on purpose. But shelfware is what you got.
This story plays out with devastating consistency. McKinsey research shows that 70% of change initiatives fail to achieve their intended outcomes. Not because the technology was wrong. Because the humans using the technology were never brought along for the ride.
Why People Resist New Technology
Before you blame your team for being "resistant to change" or "stuck in their ways," understand that their resistance is rational. From their perspective, the new system represents:
More Work, Not Less
The promise of new technology is always efficiency. The reality — at least initially — is additional work. Now they have to learn a new interface, enter data in a new format, follow a new workflow, and keep things running in the old system during the transition. Their workload just doubled, and nobody reduced their existing responsibilities to compensate.
For a field foreman already working 10-hour days, the instruction to "also log your daily progress in the new app" isn't an efficiency improvement. It's an imposition. And they will resist it — not because they're technophobic, but because they're overwhelmed.
Risk Without Reward
Your team sees the risk of the new system clearly: they might look incompetent while learning it, their productivity will drop during transition, and if the system has bugs or gaps, they'll be blamed for the resulting problems.
What they don't see clearly is the reward. "Real-time visibility" benefits the owner and management team. The foreman's daily life might not improve at all — and might get worse. If you can't articulate what's in it for the end user, don't expect them to embrace the change.
A Threat to Their Value
This is the unspoken fear. The warehouse manager who has spent 15 years developing an intricate system of sticky notes, color-coded bins, and mental models for managing inventory sees a new system as a threat to their value. If anyone can manage the warehouse with this software, what makes them special?
This fear isn't always conscious, but it drives powerful resistance. People who have built their professional identity around mastering a particular (often manual) process will not willingly adopt a system that automates their expertise away — unless you show them how the new system elevates their role rather than eliminating it.
Past Failures Set the Tone
If your company has been through a failed technology implementation before — and at 70% failure rates, most have — your team has been immunized against optimism. They watched the last "transformational" system get implemented, struggle, and eventually abandoned. They've heard the promises before. They've learned that the safest strategy is to nod politely, wait for the initiative to lose momentum, and go back to doing things their way.
This institutional cynicism is one of the most challenging obstacles to overcome. And it can only be addressed through sustained, visible commitment from leadership.
The Change Management Framework That Works
Successful technology adoption requires a parallel investment in change management — the deliberate process of preparing, equipping, and supporting people through a transition. Here's the framework:
Step 1: Start With the Problem, Not the Solution
Most technology rollouts start with the solution: "We bought this new system, here's how to use it." This approach fails because it skips the most important step: building agreement on the problem.
Before you introduce the software, get your team aligned on the pain. Hold conversations — not presentations — about what's broken:
- "How many hours per week do you spend looking for information that should be at your fingertips?"
- "When was the last time a communication breakdown cost us money or a client relationship?"
- "What's the most frustrating part of your daily workflow?"
When people articulate the problem in their own words, they become invested in the solution. They're no longer being told to change. They're participating in a fix for something they've been complaining about for years.
Step 2: Design for the End User, Not the Executive
The features that excite the business owner — dashboards, analytics, real-time reporting — are not the features that matter to the people who will use the system daily. The field crew cares about whether the app works on their phone when they have bad cell service. The project manager cares about whether it takes fewer clicks than their current spreadsheet. The office manager cares about whether it handles the exceptions that their current system handles.
Before implementation, map every end user's daily workflow and identify exactly where the new system intersects with their work. Then optimize the system for those specific touchpoints. If the system makes their daily work harder, they won't use it — no matter how great the dashboards look.
At BG Doors & Windows, the operational transformation that delivered 95% error reduction and 3x capacity growth wasn't achieved by deploying a system and hoping for adoption. It was achieved by designing the system around the actual workflows of the people using it — then implementing in focused sprints that addressed specific pain points rather than overwhelming the team with a monolithic rollout.
Step 3: Implement in Phases, Not Big Bangs
The big-bang implementation — where you switch from the old system to the new system on a single "go-live" date — has a dismal track record. It maximizes disruption, maximizes risk, and maximizes resistance.
The alternative is phased implementation:
Phase 1: One team, one process. Start with the team most likely to succeed — the ones who are most frustrated with the current process and most open to change. Implement one process on the new system. Get it working. Get feedback. Iterate.
Phase 2: Expand within the team. Add more processes for the same team. Each successful process builds confidence and creates internal advocates who can speak to the system's value from experience — not from a vendor demo.
Phase 3: Expand to additional teams. Use the first team's success as proof. Let them show their colleagues how the system works and why it's better. Peer-to-peer adoption is dramatically more effective than top-down mandates.
Phase 4: Full deployment. By the time you reach full deployment, the system has been tested, refined, and validated by real users in real workflows. Resistance is minimal because the evidence of success is internal and credible.
This approach takes longer than a big bang — typically 8-16 weeks instead of a single weekend. But the adoption rate is dramatically higher, and the risk of complete failure is dramatically lower.
Step 4: Invest in Training That Sticks
Most technology training is a one-time event: a vendor-led session, usually lasting a few hours, covering every feature of the system in a format that nobody retains. Within a week, people have forgotten 80% of what they learned (this is consistent with Ebbinghaus's forgetting curve research — retention drops to 20% within a week without reinforcement).
Effective training looks different:
Contextual, not comprehensive. Train people on the specific parts of the system they'll use, in the context of their actual workflows. The foreman doesn't need to know about financial reporting. The accountant doesn't need to know about field data capture.
Repeated, not one-time. Short training sessions (15-30 minutes) repeated over several weeks produce dramatically better retention than a single multi-hour marathon. Weekly check-ins during the first month catch confusion before it becomes frustration.
Hands-on, not theoretical. Training should involve real data and real scenarios — not demo environments with fake projects. The first time someone uses the system should be during training, on a real task, with support immediately available.
Peer-delivered, not vendor-delivered. Once your early adopters are comfortable, have them train their colleagues. Peer trainers understand the language, the concerns, and the workarounds that matter to their co-workers. They're also more credible than external trainers.
Step 5: Make the Old Way Impossible
This sounds harsh. It is. But it's necessary.
As long as the old system remains available, people will use it. The spreadsheet, the paper form, the whiteboard — whatever they've been using — is comfortable and familiar. The new system is unfamiliar and effortful. Given a choice, people will choose comfort every time.
At some point — after sufficient training, testing, and phased rollout — you need to sunset the old system. Not "discourage" its use. Eliminate it. Remove access to the old spreadsheet. Stop accepting paper forms. Make the new system the only way to do the work.
This requires courage, because there will be complaints. But it also sends the clearest possible signal that the change is permanent, that leadership is committed, and that going back is not an option.
The timing matters. Do this too early, and you'll create chaos because people aren't ready. Do it too late, and the old system becomes a permanent shadow infrastructure that undermines the new one. The right time is when 70-80% of users are comfortable with the new system — not 100%, because 100% will never happen voluntarily.
Step 6: Measure and Celebrate Wins
Change fatigue is real. Three months into an implementation, the initial excitement has faded and the daily effort of learning the new system is wearing people down. This is the danger zone — the point where many implementations stall and eventually die.
The antidote is visible progress. Measure the outcomes the new system was intended to deliver — fewer errors, faster turnaround, less rework, better data quality — and share those results with the team. Not in a quarterly business review. Weekly. In simple, concrete terms:
- "Scheduling errors dropped from 12 per week to 3 since we went live."
- "Average project reporting time decreased from 4 hours to 20 minutes."
- "We billed $45,000 in change orders this month that would have been missed under the old system."
Celebrate these wins publicly. Acknowledge the people who are making the change work. Make the connection between their effort and the results explicit.
The Leadership Variable
Every piece of change management research arrives at the same conclusion: the single greatest predictor of successful technology adoption is visible, sustained leadership commitment.
Not a kickoff email. Not a townhall announcement. Sustained, daily commitment:
- The owner uses the new system — not just reviews reports from it, but enters data, runs queries, engages with it visibly
- Managers hold their teams accountable for using the new system — consistently, not just during the first week
- Problems with the system are addressed immediately — not added to a backlog for "the next release"
- The investment in training, support, and optimization continues beyond go-live
When leadership treats the new system as optional, the team will treat it as optional. When leadership treats it as the way the company operates, the team will fall in line — perhaps grudgingly at first, but eventually as a new normal.
The Cost of Getting This Wrong
A failed technology implementation doesn't just waste the cost of the software. It wastes:
- The implementation fees (often 2-5x the software cost for mid-market projects)
- The productivity lost during the failed transition
- The organizational trust eroded by another broken promise
- The opportunity cost of the next 12-18 months of continued manual operations
- The ability to attempt change again — because the team's cynicism will be even deeper next time
According to Prosci, projects with excellent change management are six times more likely to meet objectives than those with poor change management. The technology doesn't determine success. The change management does.
The software you bought isn't the problem. The gap between buying it and using it is. Close that gap, and the transformation you were promised actually arrives.
