Everybody signs the training roster. The vendor rep runs a slick two-hour demo, the crew nods along, somebody brings donuts, and the sign-in sheet goes in a binder that proves the training "happened." Then three weeks later you walk the trailer and the foremen are still building next week's plan on a whiteboard and texting photos of it to their subs. The software you paid for is sitting there with two logins and no data in it.
Training that gets attended is not the same as training that works. If you're rolling out scheduling software to a field crew, the question that matters isn't "did they show up" — it's "can they now do the job with the tool, and are they actually doing it." This is a guide to answering that question honestly, so you catch the gaps while you can still fix them instead of six months in when adoption has quietly died.
Why You Assess At All
Field software fails for boring reasons. Not because the app is bad — because nobody confirmed the people using it could actually use it, and by the time that became obvious the momentum was gone. A superintendent who's rolled out anything knows the pattern: enthusiasm on day one, confusion by day five, and a quiet drift back to the whiteboard by week three.
Assessing training is how you stay ahead of that drift. Done right, it does three things: it tells you which people are competent and which need another pass, it tells you where your training itself is weak so you can fix it for the next crew, and it gives you an early warning that adoption is stalling before it's terminal. You're not grading people to punish them. You're finding the gap between "sat through it" and "can do it" while there's still time to close it.
The Three Levels You Actually Need To Measure
There's a real difference between knowing something, being able to do it in a quiet room, and doing it under pressure on a live job. Most training programs only ever check the first one and then act surprised when the field doesn't follow. Measure all three.
Knowledge — Do They Understand The Concept
Before anyone touches the software, they need to understand the practice it supports. If a foreman doesn't understand what a look-ahead schedule is — a rolling three-to-six-week window of committed, constraint-free work — no amount of button-clicking training will save you. You'll have someone who can enter tasks but can't tell you why the drywall crew shouldn't be on the plan until the framing inspection clears.
Knowledge checks are cheap. A five-question conversation does it: What's the difference between the master schedule and the weekly work plan? What makes an activity "ready" to pull into next week? Why do we sequence trade flows the way we do? If they can answer those in their own words, the concept landed. If they parrot a definition but can't apply it, it didn't.
Skill — Can They Do It In A Controlled Setting
This is the one most programs skip, and it's the most predictive. Sit the person down and have them build something real from scratch while you watch. Not "click where I click" — give them a scenario and let them work it.
A good practical exercise: "Here's a project that's mid-framing on the second floor. Build me next week's plan. Get the framers, the rough-in trades, and the inspector on it in the right sequence, in the right locations." Then watch. Can they create the activities? Do they put them in the right areas? Do they connect the trade-flow sequence so drywall doesn't show up before electrical rough-in and inspection? Do they know how to publish it so the subs can see it? Watching someone do this for ten minutes tells you more than a fifty-question written test ever will.
Performance — Are They Doing It On The Real Job
Knowledge and skill are what they can do. Performance is what they actually do when you're not standing over them. This is the level that determines whether your rollout succeeded, and it's the one you can only measure on the live job over time.
You don't need a formal test here — the software leaves a trail. Is the person actually building weekly work plans in the tool, or is real planning still happening somewhere else and getting copied in after the fact? Are the plans updated when the job changes, or frozen from week one? Are trade flows connected, or is everything a flat list of tasks with no sequence? Are subs actually being sent the schedule through the system? A tool like LookAheadWall makes this visible without you playing detective — you can see whose plans are current and whose went stale two Fridays ago. That's your real adoption signal.
Matching The Method To What You're Measuring
Use the right instrument for each level. A written quiz measures knowledge fine and measures skill terribly. Here's the pairing that works:
- Knowledge — a short verbal Q&A or a handful of written questions. Keep it conversational; you're checking understanding, not administering the SAT.
- Skill — a hands-on exercise you observe directly, scored against a simple checklist of what a correct plan looks like.
- Performance — direct observation on the job plus the usage data the software already collects. Walk the trailer, look at real plans, check whether they're current.
The observation checklist for the skill assessment doesn't need to be fancy. Five or six line items: created the activities, placed them in the correct locations, sequenced the trades correctly, set realistic durations, connected the flow, published to the subs. Check or no-check. If someone misses the same item that three other people missed, that's not a people problem — that's a hole in your training, and you just found it.
Timing — When To Check
Assess at the wrong time and the results lie to you. There are four moments that matter, and each one answers a different question.
- Before training (baseline). Quick check of what people already know. A twenty-year super who's used three other scheduling tools does not need the same session as a first-year foreman who's never planned past tomorrow. Skip the baseline and you either bore the veterans or lose the rookies.
- Right after training. This confirms the material landed in the room. It's necessary but it's the weakest signal — people can pass a test at the end of a session and forget half of it by Monday. Don't mistake a good post-training score for a successful rollout.
- Two to four weeks later (retention). This is the honest one. Now they've had to use it on a real job, or avoid using it, and you find out which. This is where you catch the drift back to the whiteboard while it's still reversible.
- Ongoing. Adoption isn't a finish line, it's a habit that has to hold. Glance at usage every couple of weeks for the first quarter. A plan that stopped getting updated is telling you something.
If you only do one of these, do the two-to-four-week retention check. That single follow-up catches more failed rollouts than all the day-one quizzes combined.
The Failure Modes To Watch For
A few patterns show up on nearly every rollout. Knowing them ahead of time is half the battle.
The shadow schedule. The plan the crew actually works from lives on a whiteboard or in someone's head, and the software gets updated after the fact — or not at all — just to satisfy the office. This is the most common failure and the most dangerous, because usage data looks fine while the real planning happens somewhere you can't see. You catch it by walking the job and asking "show me where you decided this week's sequence." If the answer isn't the screen, you have a shadow schedule.
The data-entry clerk. Someone learned the buttons but never learned the practice. Their plans are technically complete and completely wrong — trades out of sequence, no buffers, inspections missing. They passed the skill check on mechanics and failed on judgment. Fix it by teaching the sequencing logic, not more clicks.
The one-person bottleneck. One tech-comfortable person on the crew does all the entry and everyone else stays hands-off. Feels like adoption; isn't. The day that person is off, the schedule freezes. Assess everyone who's supposed to be planning, not just the volunteer who likes computers.
Silent confusion. Nobody asks questions in training because nobody wants to look slow in front of the crew. They nod, they leave, they never log in. The only way to surface this is the hands-on assessment — put them at the keyboard and the confusion becomes visible in about ninety seconds.
Closing The Loop
Assessment is worthless if the results just go in a binder. The whole point is to change something. Every gap you find points at one of two fixes: a specific person needs another pass, or your training itself needs work.
When one person misses something, that's coaching — a fifteen-minute one-on-one usually does it, and it's far cheaper than losing them to the whiteboard. When several people miss the same thing, that's a curriculum problem. Maybe you rushed trade-flow sequencing because you were watching the clock. Maybe the exercise you used didn't match how the job actually runs. Rewrite that part before the next crew comes through. Good training programs aren't written once — they get sharper every time you run them, because every assessment tells you where the last version was thin.
And ask the learners directly. Not a corporate satisfaction survey — a straight question at the retention check: "What part of this still feels clunky?" Field people will tell you exactly where the tool or the training is fighting them, and that's gold. Some of it is training you can fix. Some of it is workflow you can adjust. Either way you only learn it by asking.
The Bottom Line
The measure of a software rollout isn't the sign-in sheet — it's whether next Friday's work is being planned in the tool by the people who are supposed to plan it, sequenced correctly, and shared with the subs who need it. Everything in this guide is just a way of finding out whether you're there yet, and where the gaps are while they're still cheap to close. Check knowledge before you invest in skill. Watch people actually build a plan before you trust that they can. And come back at three weeks, because that's when the truth shows up. Do that, and you'll spend your training budget on the crews that stick instead of the ones that quietly drift back to the whiteboard.