Canadian organizational change management scoped to technology rollouts, measured in real usage.
One Canadian team deploys the system and gets it used, so technology adoption is our problem too, not a hand-off to someone else.
We find who'll resist, what they'll lose, and which workflow you're about to break. The change readiness pass runs before the rollout starts, and it sometimes changes the rollout.
Role-based sessions on your configuration, not a vendor's demo tenant. Each role gets a live session, a recording, and a one-page reference, so training and enablement matches the system people actually log into.
We watch real usage for thirty days after launch and fix what people work around. Logins and feature use, not attendance sheets.
Rollouts with excellent change management hit their objectives at an 88% rate, against 13% for poor practice (Source: Prosci, 2026). The difference shows up in usage data, not on an attendance sheet.
IN PRODUCTION
A client had bought the licences twice. First rollout, people nodded through training and went back to the spreadsheet. We spent a month before launch finding out why: the new system added four clicks to the one thing their dispatchers do 80 times a day. We fixed the configuration, then trained. The second attempt stuck.
We do the technology half of this discipline. Saying which half matters, so here it is.
Organizational change management covers restructuring, culture, and mergers as well as systems. We don't do those. What we do is the change management plan around a deployment we're delivering: who's affected, what breaks, what training lands, and whether people use the thing afterward. That narrowness is the point. Generic OCM consulting arrives with a framework and no ability to change the system when the system is the problem. We can edit the configuration, so our first move is usually fixing the tool rather than persuading the person. Culture programmes and reorganisations are organisational work of a different kind, and they need a certified practitioner.
Most failed rollouts fail before launch, in the design. Risk sits in three places. The workflow that gets slower for the people doing it most, which no amount of communication fixes. The champion who was never asked and now owns the resentment. And training built on a vendor demo instead of your configuration, so day one doesn't match the slides. We use ADKAR to structure the work because it's the common language most Canadian PMOs already speak, not because a model substitutes for fixing the software.
Attendance sheets and satisfaction surveys tell you people showed up and were polite. We instrument the actual system: logins, feature use, and the workaround still running in parallel. Prosci's benchmarking reports up to 135% higher benefits realisation for projects with excellent change management (Source: Prosci, 2026), and most of that gap is measurement discipline. PIPEDA applies to whatever usage data we collect, so we scope it to the minimum and tell you what's being collected before it's turned on.
Four steps, and the first one can cancel the rollout. Readiness work sometimes finds that the deployment shouldn't ship yet, and we'd rather say so in week two than train people on something that'll be abandoned. That's an awkward conversation and it's cheaper than the alternative. The rest is unglamorous: role-based training on your real configuration, then thirty days of watching what people do instead of what they said they'd do. Whatever they work around gets fixed or gets explained.
We sit with the people who'll use it and count the clicks. Who gets slower, who gets faster, who wasn't asked. That's the change readiness pass, and it ends in a written list of what the rollout breaks.
Configuration changes before communication. If the system's worse for someone, no training plan saves it. Being able to edit the software is the whole reason this ordering works.
A live session, a recording, and a one-page reference per role, built on your tenant rather than the vendor's demo. People learn the screens they'll actually see on Monday.
Thirty days of usage data. We chase the workarounds and either close the gap or tell you why it stays. You get the usage picture, not a training completion rate.
Answers first, including where we stop. An architect takes the call.
LET'S CONNECT
A senior engineer replies within an hour, 24/7.