Key Takeaways
Chapter 37: Change Management for Compliance Transformation
The Essentials
-
Technology transformations fail at the human level, not the technical level. Research consistently shows that 70% of digital transformations fail to meet objectives because of insufficient change management — not because the technology was wrong. RegTech is no exception.
-
Resistance is information, not just obstruction. Expert resistance to new compliance systems often encodes legitimate concerns about edge cases, workflow gaps, and regulatory nuance that the project team has not considered. Engage the skeptics as critical reviewers before treating them as obstacles to overcome.
-
The ADKAR model diagnoses where change stalls. Awareness (why is this happening?), Desire (do I want to support it?), Knowledge (how do I change?), Ability (can I perform the new behaviors?), Reinforcement (is the change sustained?). Each stage requires different interventions.
-
Middle management is the critical transmission layer. Team leads who are skeptical cascade that skepticism to their teams. Team leads who are engaged carry the transformation. Organizations that invest in senior leadership alignment while neglecting middle management routinely encounter implementation failures.
-
Training must build competence, not just attendance. A two-hour system demo on the eve of go-live does not prepare compliance professionals for regulatory-consequence decisions. Competence requires role-based, scenario-based training in a safe practice environment, with assessment — not just attendance tracking.
-
The compliance professional must model the new way of working. If the CCO continues requesting reports from the old system, or asks for manual summaries rather than using the new system's outputs directly, the signal to the team is that the old way is still acceptable.
-
The five change management phases are: Prepare → Build Awareness and Desire → Build Knowledge and Ability → Go-Live and Hypercare → Reinforcement. Each phase has specific activities and success criteria. Skipping any phase increases the probability of reversion.
ADKAR Diagnostic Framework
| Stage | Question | If Stalled Here... |
|---|---|---|
| Awareness | Does the person understand why the change is happening — not just that it is? | Invest in explaining the regulatory and risk drivers, not just the product announcement |
| Desire | Does the person want to support the change (even if they understand why)? | Name the losses honestly; clarify what expertise carries forward; involve in design |
| Knowledge | Does the person know how to perform the new behaviors? | Role-based, workflow-based training; not system feature tours |
| Ability | Can the person perform the new behaviors reliably under production pressure? | Extended practice time in safe environment; second training wave post go-live |
| Reinforcement | Is the change sustained over time without reverting? | Decommission old system; monitor adoption; recognize early adopters; address non-adoption |
Stakeholder Engagement Quick Reference
| Stakeholder | Primary Concern | Engagement Approach |
|---|---|---|
| Senior analysts | Expertise threat; "what's valued changes" | Involve as critical reviewers and UAT leads |
| Junior analysts | Calibration — "when do I trust the system?" | Build calibration skills in training scenarios |
| Team leads | "Will my team be able to perform?" | Engage before program announcement; make them change champions |
| CCO / Compliance leadership | Reputational risk; regulatory consequences of errors | Model the new way of working visibly |
| Business functions | Workflow disruption; onboarding time changes | Early notice; clear information; feedback channels |
| Technology | Architecture conflicts; resource competition | Joint governance; explicit decision authority |
| Regulators | Unannounced changes to material controls | Proactive notification for significant transformations |
Training Design Principles for Compliance Technology
| Principle | Why It Matters | How to Apply |
|---|---|---|
| Role-based, not feature-based | Compliance work is task-specific; feature tours don't build competence | Design training around actual workflows for each role |
| Scenario-based | Edge cases require judgment; judgment must be practiced | Use real-world alert types, customer profiles, reporting situations |
| Safe environment | Mistakes during training should have no regulatory consequences | Dedicated training environment with realistic but non-production data |
| Competence-assessed | Regulatory expectation is demonstrated competence, not attendance | Assessment checkpoints; supervised practice sign-off |
| Two-wave structure | First wave builds understanding; second wave builds operational competence | Plan second training at 2-4 weeks post go-live |
| Calibration training | Junior staff need to recognize when AI outputs may be wrong | Include scenarios where the system's suggestion is incorrect |
Go-Live Checklist
Before Go-Live: - [ ] All procedure documentation updated (old system references removed) - [ ] Super-users designated and given advanced training - [ ] Training environment available for at least 2 weeks prior - [ ] Competence assessments completed for all user roles - [ ] Rollback plan documented and communicated - [ ] Parallel run scope, duration, and thresholds agreed - [ ] Hypercare support staffed (internal + vendor) - [ ] Adoption metrics tracking configured
At Go-Live: - [ ] Management visibly present on go-live day - [ ] Escalation path for technical issues clear and tested - [ ] First-day issues captured and triaged in real time
Post Go-Live (Hypercare Period): - [ ] Adoption metrics reviewed daily for first 30 days - [ ] Second training wave scheduled (2-4 weeks post go-live) - [ ] Reversion indicators monitored (old system access logs) - [ ] Super-user feedback collected weekly - [ ] Formal hypercare closure review at 90 days
Maya's Five Hard-Learned Lessons
-
Involve the people before you decide, not after. Requirements workshops with the team improve the specification AND build ownership of the choice.
-
Name the losses, not just the gains. Honestly acknowledging what will be harder or lost in transition builds more trust than relentlessly positive communication.
-
Training must happen twice. Pre-go-live training builds conceptual understanding. Post-go-live training (2–4 weeks) builds operational competence.
-
The team lead is the most important change agent in the room. Invest more in engaging middle management than in engaging senior leadership.
-
Compliance leadership must visibly model the new way of working. Using the new system's outputs in management conversations and decisions signals that the change is real, not optional.