The Lab

94% completion. The training worked.
Did it? Or did 94% of your workforce learn to click Next fast enough to avoid a follow-up email from HR?

Completion rate is the most commonly reported learning metric in corporate L&D. It is also the least meaningful. It measures a behaviour — opening and finishing a module — not the behaviour you actually care about, which is doing something differently at work.

Here's how completion rates get inflated without anyone lying:

• Slides are skippable. Learners click through at maximum speed.
• Assessments use recognition-based multiple choice. Learners guess. They pass.
• Time-on-task is not tracked or is tracked but not acted on.
• The "completion" triggers off of the final slide being reached, not assessed performance.

I've audited compliance programmes with 90%+ completion rates where the average time on the highest-stakes module was under 3 minutes — for a module designed to take 12. The data was there the whole time. Nobody looked at it.

What to measure instead

The right metrics depend on what you're trying to change. But as a starting point:

• Time-on-task per module — is it plausible? Is anyone spending 2 minutes on a 12-minute module?
• Assessment question analysis — which questions have suspiciously high pass rates? Which have distractor patterns that suggest guessing?
• Pre/post behaviour data — if the training was about compliance, did compliance incidents change? If it was about sales, did conversion rates move?
• Spaced retrieval scores — if you're using spaced practice, what's the retention curve? Where does knowledge drop off?

Completion rate tells you your LMS is working. It tells you nothing about your training.

The harder question

If completion rate is your primary success metric, ask yourself: who chose that metric, and why? Usually it's because it's easy to measure and easy to report. Easy metrics get used. Useful metrics require more effort.

Start tracking one better metric this quarter. Not ten. One. Decide in advance what a "good" number looks like, and what you'll do if you see a bad one. That discipline — measure, interpret, act — is what separates a learning function from a content factory.

The most valuable thing I can tell a client is: you don't need training.
Half the performance problems I see are process problems, tool problems, or incentive problems dressed up as knowledge gaps.

When a manager says "my team needs training on X," they're usually right that there's a problem. They're often wrong about the cause. And if the cause is wrong, the solution is wrong — and you've spent time, money, and credibility on a course that changes nothing.

The five real causes of underperformance

Thomas Gilbert's Behaviour Engineering Model has been around since 1978. It's still underused. Before designing any training, ask:

• Information: Do people know what's expected? Do they get clear, timely feedback when they do it wrong?
• Resources: Do they have the tools, time, and support to perform correctly?
• Incentives: Is correct performance rewarded? Is incorrect performance penalised? Or is the incentive structure pointing in the wrong direction entirely?
• Knowledge: Do they actually lack the knowledge or skill to perform? (This is the only cause where training helps.)
• Capacity: Are they physically or cognitively capable of the performance?
• Motivation: Do they want to perform correctly? If not, why not?

In my experience, genuine knowledge and skill gaps account for maybe 20-30% of performance problems. The rest are environmental. Training can't fix a bad process. It can't fix a tool that doesn't work. It can't fix a manager who rewards the wrong behaviour.

What to do when training isn't the answer

Say so. Clearly. With evidence.

This is uncomfortable because it can feel like you're talking yourself out of a contract. In my experience, the opposite is true. Clients remember the consultant who told them the truth. They trust them for the next project. They refer them to colleagues.

When you identify that training isn't the answer, give them an alternative recommendation. A process redesign. A job aid. A manager briefing guide. A feedback loop. Something that will actually fix the problem.

The goal isn't to build courses. The goal is to improve performance. Sometimes those are the same thing. Often they're not.

A scenario where the wrong answer is obviously wrong teaches nothing. Real decisions are hard because all the options are defensible. If your learner can guess the right answer without reading it, your scenario is decoration.

Scenario-based learning is everywhere right now. It's in every eLearning template pack. It's the answer to every "how do we make this more engaging?" question. And most of it is doing almost nothing pedagogically useful.

The three signs your scenario is broken

1. The wrong answers are obviously wrong. If one option is "document everything carefully" and another is "ignore the problem and go to lunch," you haven't built a decision — you've built a filter for people who can read. Real decisions involve choosing between options that all have merit. The tension is the learning.

2. Failure leads to a "Try Again" button. In real life, mistakes have consequences that unfold over time. A wrong decision in a compliance scenario doesn't produce a red screen and a "That's incorrect" message. It produces a delayed audit finding, a manager conversation six weeks later, a damaged client relationship. Your scenario should do the same. Delayed consequences are more realistic and more memorable.

3. The scenario is generic. "Sarah, a new employee, is unsure about the company policy" is not a scenario. It's a placeholder. Effective scenarios use specific, named characters in specific, recognisable situations that your audience will see themselves in. The more specific and real, the more transfer.

What makes a scenario actually work

A well-designed scenario has four components that most templates skip:

• Authentic tension — all choices are defensible. The learner has to actually think.
• Plausible characters — people who act the way real people act, with competing agendas and partial information.
• Consequence fidelity — outcomes match what would actually happen, not an idealised version of it.
• Reflective debrief — not "here's the right answer" but "here's what different choices set in motion, and why."

The test I use for every scenario I build: could a competent person choose any of these options and defend their reasoning? If yes, it's a real scenario. If one answer is clearly right to anyone paying attention, it's a dressed-up knowledge check.

Every project I take on starts with the same five questions. Not a needs analysis template. Not a stakeholder form. Five questions that separate a training problem from a performance problem.