September 13, 2026

Why MES Projects Stall When Operations Is Only One Person

By Paul McKinney

Medical device manufacturing team reviewing process documentation on a clean production floor.

Six years ago, I worked on an MES project for a medical device manufacturer.

We had an operations representative assigned to the implementation team. He was sharp, engaged, and unusually quick to learn the software. He understood the screens, the configuration model, and the way the MES would translate production work into controlled electronic workflows.

For a while, that looked like exactly what the project needed.

He provided most of the configuration input. He answered process questions. He helped the project team move quickly. From the outside, it would have been easy to say that operations was involved.

Then the project reached implementation, and the momentum stopped.

The issue was not that operations had been ignored. The issue was that operations had been represented too narrowly. The lead had moved forward largely on his own, without a strong enough communication chain back through supervisors, operators, quality, engineering, and the people who would actually live with the configured process every day.

When the broader operations team finally reviewed the MES workflow in detail, they found problems. Some steps did not match how production really worked. Some exceptions had not been captured. Some handoffs were clear to the person who configured the system but not to the people expected to use it.

The software had been learned. The configuration had been entered. The requirements had not been fully discovered.

That distinction matters.

Operations involvement is not the same as operations alignment

Manufacturing systems are full of hidden knowledge. Some of it is documented in procedures, routers, batch records, work instructions, drawings, and quality plans. A lot of it lives in the daily judgment of the people who know where the process bends, where it must not bend, and where the written process is technically correct but operationally incomplete.

That is especially true in regulated manufacturing. A medical device production process is not just a sequence of tasks. It is a controlled chain of work, evidence, approvals, traceability, exceptions, inspections, and responsibilities.

An MES implementation turns that chain into software.

So the project cannot depend on one operations representative being smart, helpful, or fast. Those things are valuable, but they are not enough. One person can explain a process from one vantage point. One person cannot reliably represent every shift, exception path, training gap, inspection step, material movement, rework scenario, and supervisor decision point.

The common project-management mistake is to treat "operations has a seat at the table" as the finish line. It is only the beginning.

The real question is:

Does the operations representative have a working system for gathering, testing, and confirming requirements with the rest of operations?

If the answer is no, the project has a single point of interpretation.

Why the project looked healthy until it did not

This kind of failure can be hard to see early because the project appears to be moving.

Questions are being answered. Configuration is being completed. Workshops are productive. The operations lead may be one of the most engaged people on the team.

But progress inside the project room can hide silence outside the project room.

The people who will run the line may not know what assumptions are being made. Supervisors may not have seen the configured workflow. Quality may not have reviewed how exceptions are captured. Engineering may not have confirmed that the electronic process handles real equipment constraints. Training may not know what new behaviors the system will require.

Nothing feels wrong until the configured process is shown to a wider group.

Then the comments start:

"That is not how the second shift handles this."
"What happens when the component fails inspection?"
"We cannot require that approval at that step because the supervisor is not always available."
"That data is not available until later in the process."
"The operator will not know which path to choose from that screen."
"This works for the normal build, but not for rework."

Those comments can sound like late resistance. Often they are late discovery.

The team is not necessarily fighting the MES. They are seeing their work accurately represented for the first time and noticing what was missed.

Current research points to the same lesson

The recent digital manufacturing research keeps pointing in the same direction: the hard part is rarely just the technology.

MIT Sloan Management Review's 2026 case study on Pfizer's manufacturing transformation describes the challenge as rebuilding trust, processes, and collaboration between digital and plant teams, not simply deploying new tools (MIT Sloan Management Review).

CESMII's work on scaling smart manufacturing highlights People, Process, and Data foundations as the difference between isolated pilots and enterprise-scale results. It also cites the familiar pattern of manufacturers getting stuck in "pilot purgatory" when those foundations are weak (CESMII).

KPMG's 2026 industrial manufacturing technology report makes the governance problem explicit. It reports that 87% of industrial manufacturing executives say cross-functional collaboration is critical, while unreliable data and fragmented operating models remain major barriers to scaling advanced technology (KPMG).

Those findings match what many project managers see on the ground. Digital manufacturing projects do not stall because teams forgot to invite operations. They stall because the operating model for communication, validation, and decision-making was too thin for the complexity of the work.

In MES projects, the communication chain is part of the system design.

The missing artifact: an operations communication chain

Every MES project needs a clear technical architecture. It also needs a clear operations communication architecture.

That does not have to be complicated, but it does have to be intentional.

For each production area, the project should define:

Who represents operations in project workshops
Which supervisors, operators, leads, and support functions must be consulted
Which decisions the representative can make alone
Which decisions require review by a broader group
How process exceptions and edge cases will be collected
How feedback from each shift will be captured
How configuration decisions will be communicated back to the floor
How signoff will happen before the system reaches validation or go-live

Without that structure, the operations lead becomes a bottleneck even when they are doing excellent work.

They absorb questions from the project team, translate them into their own understanding, and configure or approve the system from that perspective. The broader team may only see the result after the design has hardened.

That is when feedback becomes expensive.

Early feedback changes a requirement. Late feedback reopens design, configuration, testing, training, validation evidence, and sometimes trust.

A better way to run MES requirements

The goal is not to slow the project down with endless consensus. Manufacturing projects still need decisions, owners, and forward motion.

The goal is to make sure the right knowledge reaches the project before the design becomes expensive to change.

A practical MES requirements rhythm looks something like this:

Start with process mapping at the floor level. Do not begin with software screens. Begin with the real production flow, including normal work, exceptions, holds, inspections, rework, scrap, material movement, and supervisor intervention.
Name the assumptions. When someone says "the operator enters the result here," capture the assumption behind it. Which operator? At what station? With what information available? On which shift? Under what exception conditions?
Review with more than the project representative. Bring the configured workflow back to operators, supervisors, quality, engineering, and training before it becomes the baseline. Keep the review focused: "Here is how the MES will ask you to do the work. What is missing?"
Track open questions like project risks. Unanswered process questions should not live in hallway conversations or old meeting notes. They should have owners, dates, decisions, and visibility.
Close the loop publicly. When feedback changes the configuration, communicate the decision back to the people who raised it. When feedback is rejected, explain why. This is how trust survives the implementation.
Validate the communication chain, not just the configuration. Before go-live, ask whether every affected group has seen the relevant workflow, had a chance to identify gaps, and understands what changed.

That rhythm prevents a strong operations lead from becoming the only source of truth.

The project manager's job

On an MES project, the project manager should not assume that assigning an operations lead solves operations engagement.

The PM should keep asking:

Who has not seen this yet?
Which shift has not been heard from?
What exception path are we assuming away?
Which decision was made by one person but affects many?
What needs to be confirmed before validation?
What will surprise the floor if we do not communicate it now?

Those questions are not administrative overhead. They are risk management.

They also create a better relationship between the project team and the plant. When operators and supervisors see their feedback reflected in the system, the MES becomes less like something imposed on them and more like a controlled version of work they recognize.

That recognition matters. Adoption is not just training people where to click. Adoption is the moment people decide the system understands enough of their reality to be worth using carefully.

The lesson from that stalled project

Looking back, the operations representative on that medical device project was not the problem. In many ways, he was one of the project's strengths.

The weakness was the communication design around him.

He learned the software quickly. He configured a lot of the process. He helped the team make progress. But the project treated his involvement as if it were the same as broad operational agreement.

It was not.

The broader operations team found gaps because they had knowledge the project had not pulled into the work early enough.

That is the lesson I would carry into any MES implementation:

Do not just involve operations. Build the path that lets operations speak as a system.

One operations lead can be a champion. They can be a translator. They can be an owner. But they should not be the entire communication chain.

For project managers, this is exactly where structured meeting notes, decisions, open items, and follow-up matter. The risk is not only that someone forgets an action item. The risk is that an entire group of requirements never becomes visible because the project had no reliable way to carry them from the floor to the design team and back again.

That is the kind of work Project Notes Pro is built to support: keeping decisions, open questions, owners, and follow-up visible across meetings, so a project does not confuse one good conversation with complete alignment.

If you are leading an MES project, start there. Before asking whether the configuration is done, ask whether the communication chain is working.

Written by Paul McKinney, founder of Project Notes Pro. Try it free at projectnotespro.com.