Rolling Out New Software to Traffic Control Crews Without Losing the Season

The most common way traffic control software fails is not that it lacks a feature. It is that it was introduced in June, to every crew at once, with a two-hour training session, and abandoned by August because "the guys wouldn't use it."

That outcome is predictable and largely preventable. What follows is a sequencing approach built around the specific constraints of this workforce: seasonal, dispersed, frequently working nights, often on old phones, and entirely justified in being skeptical of anything that slows down a setup.

Start in the right season, in the right direction

Roll out in the shoulder — the weeks when work is picking up but not peaked. Two reasons. First, capacity: crews learning something new need slack, and there is none in July. Second, direction of travel: starting into a rising schedule means adoption matures before volume arrives. Starting into a falling one means the habit never sets, and next spring you begin again with a system nobody remembers.

The corollary is that a mid-season emergency rollout — usually triggered by a dispute or an audit — is the worst possible timing and the most common trigger. If something has just gone wrong and the impulse is to fix it with software immediately, the better move is to fix the immediate problem manually and schedule the rollout for the shoulder.

Pick one crew, and pick the right one

Not the enthusiast, who will make it work regardless and tell you nothing. Not the loudest skeptic, who will produce a fight rather than data. The crew whose judgement other crews respect.

Give them two or three weeks on real jobs. Watch a setup in person — not a demo, an actual setup, ideally in poor conditions. Most of what you learn will be about friction: the ticket takes too long, the equipment list scrolls badly with gloves on, the signature capture fails in direct sunlight. Those are fixable, and they are invisible from the office.

Sequence the capabilities; do not turn everything on

The instinct is to launch the full system. The better path is to launch one capability that produces a visible win, then add.

First: daily tickets. This is where the value is most obvious to everyone. Crews stop hand-writing and hand-delivering; the office stops chasing. It is also the capability that most directly reduces disputes — see preventing daily ticket disputes — which means the first win is legible to the customer as well as internally.

Second: equipment on tickets. Once tickets are habitual, add what went out and what came back. This is where rental billing accuracy starts and where device tracking by job site becomes real rather than aspirational.

Third: scheduling and dispatch. Moving the schedule off the whiteboard is the change that most affects the office, and it goes better once field data is already flowing.

Fourth: quoting, invoicing, and accounting integration. Back-office work last, because it depends on the field data being trustworthy.

Companies that reverse this order — starting with scheduling because it is the office's pain — routinely stall, because the field sees a system that takes from them and gives nothing back.

Give crews the reason, not just the instruction

Field crews are asked to adopt new tools regularly and are rarely told why in terms that matter to them. "The office needs the data" is not a reason a flagger cares about at 5 a.m.

The reason that does land is that the field record is the only evidence of what the crew actually did. When a customer disputes hours, when an agency questions a setup, when a claim arrives about a job from last spring — the crew's own account of events is either documented or it is a memory against someone else's memory. Crews understand that instantly, because most of them have been on the wrong end of it.

The compliance framing helps as well, and it is worth stating plainly rather than gesturing at. The setup itself is governed by MUTCD Part 6, which sets the national provisions for temporary traffic control, and OSHA's construction standard states at 29 CFR 1926.200(g)(2) that "The design and use of all traffic control devices, including signs, signals, markings, barricades, and other devices, for protection of construction workers shall conform to Part 6 of the MUTCD (incorporated by reference, see § 1926.6)". Nobody is going to reconstruct from memory which devices were placed where on a Tuesday in April. A time-stamped, GPS-stamped record does it automatically, and it protects the crew as much as the company.

That framing changes the character of the ask. It is not paperwork for the office. It is the crew's own record of having done the job correctly.

Set the hardware question honestly

Field software runs on whatever phone the crew has. That is frequently an older Android with a cracked screen, used with gloves, in rain, at night, with intermittent signal. Two decisions follow.

Test offline behaviour before rollout, not during. Traffic control happens in cuts, under structures, and in rural corridors. If a ticket cannot be completed and queued without signal, crews will learn that within a week and revert. Ask the vendor directly and then verify it yourself by putting a phone in airplane mode and completing a full ticket.

Decide whether you are supplying devices. Company-supplied phones or tablets remove a category of excuse and a category of genuine problem, at a real cost. Bring-your-own works, but then screen size and OS version are constraints you have accepted, and the workflow has to survive them.

The rule that decides everything

Set a date after which the office stops accepting the old format. Not a suggestion — a date. Until that date exists, paper is a valid path, and any crew that finds the app slower will use it. Adoption stalls exactly at the boundary of preference.

Announce it at the start, well ahead. Make it late enough to be fair and firm enough to be real. Then hold it, including for the crew you can least afford to annoy. Every exception granted after the date resets the message.

Train the way crews actually learn

Classroom training on new field software has poor retention, because the context is wrong. What works better:

Train at the tailgate, in five minutes, on the thing they will do that day. The existing meeting is already the channel for operational change — see tailgate safety meetings for keeping those meaningful.

Ride along for the first ticket. One supervisor, one crew, one real setup. Fifteen minutes of watching removes more friction than an hour of instruction.

Name one person per crew as the go-to. Peer support scales in a way that a help desk does not, particularly at 5 a.m.

Write nothing longer than a page. Documentation crews will actually consult is a laminated card in the truck, not a PDF.

Measure adoption, not activity

The metric that matters is the share of jobs with a complete field record — ticket submitted, equipment recorded, signature or documented refusal, photos where required. Not logins. Not app opens.

Track it weekly and by crew, and treat a low number as a diagnostic rather than a disciplinary matter. A single crew at 30 percent usually has a specific fixable obstacle; all crews at 30 percent means the workflow is too slow and the problem is yours. The broader habit of measuring operational performance rather than assuming it is covered in measuring safety and operational performance.

What a realistic timeline looks like

Weeks 1–3, one crew on tickets only, with a ride-along and weekly friction review. Weeks 4–8, all crews on tickets, with the paper cutoff date announced at the start of week 4 and landing at the end of week 8. Weeks 8–12, add equipment capture. Month 4 onward, scheduling and back-office. Full maturity across a season.

That is slower than a vendor's implementation plan and faster than most companies actually achieve, because most companies attempt everything at once and then restart.

If you want to see what the field workflow looks like before committing a crew to it, the features overview covers the ticket and equipment flow, and a demo can be run on one of your own jobs — including with the phone in airplane mode, which is the test worth insisting on.