Every large ERP program has them: a handful of key users who know not just their module, but the story behind it — why a process runs the way it does, and which exception in the legacy system was never documented. These people are worth their weight in gold. And that's exactly why they're the single biggest risk in the project.

The invisible load-bearing pillars

Knowledge concentrates. In practice, four or five people often carry a disproportionate share of the rollout load — as translators between the business and the project, as trainers, as the last line of escalation. As long as they're available, their effort masks structural gaps. The project feels stable. It isn't.

A key person who drops out mid-rollout takes knowledge that sits in no system.

Why overload is missing from reporting

Overload shows up in no project plan. It shows up in slower response times, in tasks that pile up on one person, in a calendar with no gaps. Classic reporting captures work packages, not the load-bearing capacity of the people behind them. By the time the issue becomes visible, the person is usually already at the limit — or already on the way out.

Three questions to ask today

  • Concentration: on how few people does your most critical module really depend?
  • Failure scenario: what happens, concretely, on go-live day if one of them drops out?
  • Knowledge transfer: does the process knowledge exist anywhere but in one person's head?
Leading indicator, not an obituary: interviewing key users confidentially reveals overload and attrition risk before a key person leaves — and lets you redistribute the load while there's still time.

From single point of failure to resilient structure

The fix isn't to load individual heroes even more heavily — it's to make dependencies visible and distribute knowledge. That starts with an honest inventory: who carries what, who's at the limit, where redundancy is missing. Once that's on the table, a silent risk becomes a manageable variable.