CMMS Adoption Resistance After Merging Two Facility Teams

I would separate the causes rather than label the technicians as resistant. Structural issues include incomplete asset data, a 10-week timeline that leaves no room for data cleanup, four hours of training for a system that changes daily work, and duplicate contracts that create conflicting priorities. These are real defects in the implementation plan. The pilot finding that closeout takes longer is evidence, not attitude.

Change-management issues include low consultation, high tenure, union relationships, and fear that the new system will be used to monitor individuals rather than manage work. A 54% favorable engagement score and 41% saying they were not consulted indicate that the merger has already used up goodwill. The mandate from corporate increases urgency but does not create commitment.

Using a model such as ADKAR, the gap is likely in awareness and desire, not only knowledge. Training alone will not fix it. I would also check whether the legacy teams have different work-order terminology, pay grades, and shift patterns; those differences can look like resistance when they are actually process conflicts. The response should combine data cleanup and process design with visible sponsorship, union engagement, and role-based training.

Weeks 1–2: form a sponsor group with the COO and union representatives, publish a simple purpose statement, and run a data-cleanup sprint on the assets that matter most-life-safety, HVAC, and elevators. Identify floor-level champions from both legacy teams. Weeks 3–6: deliver role-based training, not four generic hours. Technicians need work-order entry and closeout; supervisors need scheduling and backlog reports; finance needs cost coding. Add quick-reference cards and floor support. Weeks 7–10: go live by site or shift if corporate permits, with two weeks of hypercare, daily issue triage, and a visible fix log.

Stakeholders: COO, HR, union stewards, IT, finance, vendors, and supervisors. The key tradeoff is training depth versus the go-live date. I would not pretend four hours is sufficient; I would ask for additional short sessions and on-the-job coaching, and I would protect the data-cleanup time even if it means a narrower first release. I would defer contract consolidation until after system stability, because changing vendors and systems at once multiplies risk. Success requires visible early wins: faster closeout, fewer duplicate entries, and a working mobile view.

Leading indicators show whether adoption is being built: training completion by role, champion coverage per shift, active users, work orders created per technician, asset-data accuracy from a sample audit, and the number of open issues closed within 48 hours. I would also track whether supervisors are using the reports in daily huddles, because that signals real adoption rather than compliance.

Lagging indicators show whether the consolidation is delivering: PM compliance, backlog aging, mean time to repair, first-time fix rate, overtime, duplicate contract spend, and engagement pulse scores. Turnover and grievance rates matter because the merger is a people event, not only a software event.

I would baseline each metric before go-live and report trends, not single points. A system can show high login counts while work-order quality falls, so I would pair usage data with data-quality audits. The COO should see a small dashboard: adoption, service performance, cost, and people. If the numbers are bad, I would report them early and explain the corrective action rather than wait for a quarterly review.