At acceptance, one sentence from a frontline key user outweighs ten from the project manager

Is the system any good? At project acceptance, ten sentences from the project manager count for less than one from a frontline key user.

It’s the same after go-live. Most small issues on the floor are handled by the key user, and when efficiency goes up, that comes from them too, not from management.

This post covers key users: how to pick them, when to bring them in, what to ask of them, how to keep them willing, and the three most common traps.

1. How to pick key users: by role, senior and willing to learn

A key user is the person who represents a business role in the project.

We split by role: warehouse, production line, purchasing, planning. Every role needs one. Purchasing and planning are the ones that get left out, yet arrivals, replenishment and order release all come from them. Without them, the warehouse and line requirements are only half the story.

One more person deserves a separate mention: the logistics planner. The roles above use the system; the logistics planner owns the rules inside it. The PFEP table, packaging plans, line-side layout and drop points, delivery methods, logistics routes: mostly defined and maintained by this person. Every kitting, delivery and wave the system runs reads data they maintain. If they’re not in the project, nobody owns the rules. If they are, the PFEP, wave-picking and putaway topics from the earlier posts have someone to carry them.

We pick on two things: seniority, and willingness to learn. Seniority means the floor trusts them; when they say “do it this way,” the team follows. Willingness to learn means the new system actually gets picked up. Seniority without willingness means old habits fighting the new system. Willingness without seniority means they learn it but can’t bring anyone along.

When do they join? From the requirements and blueprint stage, ideally all the way through. If they raised the requirements and watched the blueprint being set, after go-live they treat the system as their own. Someone pulled in at testing sees a system other people already decided, and is quicker to find faults than to use it.

2. Six jobs for a key user, and what they’re worth

A key user isn’t a name on a list. We ask them to do six things:

• Confirm requirements: how this role works every day, and what the system has to support
• User testing: test with real business scenarios, not the test cases the developers wrote
• Get trained: learn it first, then teach others
• Provide data: the business part of opening-stock data and location tables comes from them; rule data like PFEP comes from the logistics planner
• Run it on the floor, then train the frontline: operate it on site at go-live, then teach the shift teams
• First-line diagnosis: when something goes wrong, decide first whether it’s an operating issue, a data issue or a system issue. Operating issues they fix on the spot by teaching; for data issues they know who to ask; only system issues go to the project team

When those six get done, here’s what they’re worth: at acceptance, one sentence from them outweighs ten from you. Most small issues on the floor they can handle, and support workload drops by a lot. More importantly, real efficiency gains on the floor come from frontline key users, not from management.

3. How to keep key users willing, and three traps

Key users already have full-time jobs; the project is extra work. We rely on four things:

• Management backing: their manager recognizes the time they spend on the project
• Real involvement, listening to the floor: when their requirements actually make it into the system, they keep raising them
• Regular contact: don’t wait for a problem before reaching out
• Know who to ask: for people and time, go to the department head; for hands-on work, go straight to the frontline key user

The three most common traps:

• Assigned to tick a box, doesn’t know and doesn’t want to learn: the department sends whoever is free, and that role effectively has no one. So the project manager should take part in picking, using “senior and willing to learn,” instead of leaving it all to the department
• Transferred or resigned mid-project, knowledge lost: the replacement starts from scratch, and nobody remembers why the confirmed requirements were set that way
• Only one person knows, and becomes the bottleneck: after go-live every issue goes to them; when they take a day off, the floor stops. That’s why job five, “train the frontline,” can’t be skipped

---

At your plant, is key-user work written into their performance review?