Step 9 · Adoption and Change Management

A system that works technically can still fail operationally. Plan for training, communication, shift differences, feedback, reinforcement, support and the normal resistance that accompanies change.

GUIDE · 17 min read
Step 9 · Adoption and Change Management

The short version

This is where the system that tested well fails on C shift. Not because the technology stopped working, but because the crew that was not in the pilot never heard why it mattered, the training happened on a day they were off, and the one person who understood it works opposite them. Adoption is a communications and reinforcement problem far more than a technical one, and it is worth as much planning as the configuration got.

Some technology changes the conditions of work

Technology adoption is not always just a training and communications issue. Depending on the jurisdiction, collective-bargaining agreement, policy environment and how a system is used, technology that affects employee monitoring, location tracking, scheduling, staffing, performance measurement, wearables or working conditions may require consultation with labor, HR, legal counsel or employee representatives.

What is required, and when, differs from place to place. Labor law, bargaining obligations and past practice vary by state and by agreement, and two departments deploying the same product can have genuinely different obligations. Nothing here can tell you what yours are. It can tell you when to go and find out.

If the technology changes what employees are expected to do, how they are measured, what information is collected about them, or how management uses that information, address that question before rollout.

This is among the least expensive problems on the roadmap to handle early and one of the most expensive to handle late. Raised while requirements are being written, it is a conversation. Raised after go-live, it is a grievance, a pause, or a system that gets switched off after the department has already paid for it.

It is also not primarily a legal problem. Most of the damage comes from people discovering after the fact that something is being collected about them that nobody told them about.

Questions to answer early

  • Does this system collect employee location?
  • Does it collect physiological information?
  • Does it measure individual performance?
  • Does it affect staffing or scheduling?
  • Does it change workload?
  • Does it create new documentation requirements?
  • Who can access employee-level information?
  • How long is the information retained?
  • Can it be used for discipline?
  • Have HR, legal and labor relations reviewed the intended use?
  • Do employees understand what is and is not being collected?

Do not sell one purpose and quietly use the technology for another.

A common example makes the point. A vehicle location system introduced for firefighter safety and closest-unit dispatch is usually also capable of producing individual driving reports. Whether it should, who may see them, and what role they play in any performance or disciplinary process are decisions the department makes.

Make those decisions in writing, before the capability is switched on, rather than the first time somebody asks for a report. Tell people what the intended use is. If the intended use later changes, say so before it changes.

See it applied

Start here

If you read one thing on this subject, read this.

Official resourceU.S. Government Accountability Office

Agile Assessment Guide

GAO's guide to incremental delivery, continuous evaluation and user feedback on government technology programs.

Go deeper

Questions to ask your vendor

  1. Has every shift heard the reason, not just the instruction?
  2. Who is the person on each shift that others will ask?
  3. What does someone do at 0300 when it will not work?
  4. How are we collecting complaints, and is anyone acting on them?
  5. What are we measuring to know whether it is genuinely being used?
  6. What old process are we switching off, and when?