Why the pilot looked good and the rollout did not
Pilots often succeed because a small, motivated team gets close support and a manager who champions the change. Rollout removes both at the same time the audience grows, so the same tool meets less attention and more resistance. The fix is to remove support gradually across the rollout, not all at once after the pilot ends.
The pilot hit every target. The rollout has not. Nothing about the software changed between the two, which is usually the clue.
Three things a pilot has that a rollout does not
| Factor | Pilot | Rollout |
|---|---|---|
| Team selection | Volunteers, often already motivated | Everyone, including sceptics |
| Support ratio | High, near one-to-one | Diluted across the wider group |
| Visibility | Leadership watching closely | Attention has moved on |
The mistake in scaling
Teams treat the pilot as proof the tool works and the rollout as a distribution exercise. It is really a second adoption project with a harder audience.
The pilot proved the tool could work. It never proved the organisation would use it without help.
What to do differently
- Stage rollout in waves that mirror pilot support ratios as closely as budget allows
- Recruit pilot participants as peer coaches for the next wave
- Re-baseline usage targets for rollout separately from pilot results
Empley's ROI calculators for hours saved and attrition reduction assume the tool is actually used at rollout scale; a stalled rollout breaks that assumption before any efficiency case can be tested.
Underlag
- Our assessment
Pilot teams typically receive more direct support per person than rollout teams, which affects usage independent of the tool itself.
Common questions
- Should we run a bigger pilot instead?
- A bigger pilot only tests one more wave of motivated volunteers; it does not test rollout to sceptical or low-attention teams.
- How do we budget for rollout support?
- Plan declining but non-zero support per wave rather than assuming support ends when the pilot does.