Pangaea Life Science Solutions

Why Most MES Projects Miss the Mark

The three failure patterns that account for most of it, and what the projects that succeed do differently

Picture of Ryan McInerney

Ryan McInerney

Chief Operating Officer

Published 19th August 2026

ON THIS PAGE

The most instructive MES failure I have seen was, by every metric the project team reported, a success.

Last quarter I watched an AI tool generate 184 batch record steps from a stack of paper MBRs and SOPs in under an hour. It would have taken our team three weeks, but about 30 of those steps shouldn’t have existed. 

It went live on schedule. It came in close to budget. Validation completed without a major finding. The steering committee held a closing meeting, thanked everyone, and stood the project down.
 
Eighteen months later, operators on two of the four lines were maintaining parallel paper records alongside the MES, not because anyone had sanctioned it, but because the electronic record was slower to execute than the process it replaced, and the shift needed to hit its numbers. Batch review times had gone up, not down, because reviewers were now checking two sources instead of one. The business case had promised an improvement in right-first-time performance and a reduction in documentation deviations. Documentation deviations rose by 20% in the first year, most of them errors caused by prompt fatigue.
 
Nobody called it a failed project. There was no crisis, no write-off, no post-mortem. The project had delivered exactly what it was scoped to deliver. It just hadn’t delivered what the business had wanted, which was never quite the same thing.
This is what MES failure usually looks like. Not a collapse. A quiet, expensive miss.

The number behind the pattern

Gartner’s research on digital transformation puts the failure rate at around 70%, driven substantially by a disconnect between what the business wanted and what the IT organisation delivered. That figure spans digital transformation generally rather than MES specifically, but the mechanism it describes is precisely the one that governs MES outcomes.

 

MES sits at an unusually difficult intersection. It is an IT system with deep OT dependencies, executed by operations, governed by quality, and justified with a business case owned by a fifth party, usually site leadership or a corporate programme. Each of those groups holds a different definition of what a successful go-live means. Absent a deliberate effort to reconcile them, the project defaults to the definition that is easiest to measure, which is almost always schedule and budget.

 

A project measured on schedule and budget will deliver schedule and budget. It will do that by trading away the things nobody is measuring, process simplification, execution speed on the floor, review efficiency, deviation reduction, because those are the only variables available once the timeline is fixed.

 

Most MES projects don’t fail because the team executed badly. They miss because the project was set up to optimise for the wrong things from the first steering meeting.
 
Across the projects we have delivered and inherited, three patterns account for the overwhelming majority of misses. Customisation debt and integration governance cause their share of damage too, and both deserve their own treatment, but these three are where the value is usually lost first.

1. The scope trap

Phase 1 is defined as “core batch execution on one line,” which is sensible. Then scope grows during design, because every stakeholder who reviews the specification finds something they need. Weighing and dispensing gets pulled in. Then equipment integration on two additional assets. Then a reporting requirement from corporate quality. The timeline doesn’t move, because the timeline was announced to the board.
 
What gets sacrificed is never the newly added scope, it is design depth on the original scope. Process challenge sessions get shortened. Operator usability review gets deferred to “post-go-live optimisation,” which never receives a budget. The project delivers more functionality, less well.
 
If your scope has grown but your timeline hasn’t, you are not managing scope. You are silently reallocating quality.

2. The validation trap

Validation is where MES projects lose the most time for the least benefit, and it fails in both directions.
 
Over-validation is the more common failure in our experience: treating every configuration item as high-risk, scripting every conceivable path, and generating documentation volume that correlates with effort rather than with patient risk. That is expensive in itself, but the deeper cost is rigidity. A site that has validated several hundred test scripts against one specific configuration becomes structurally unwilling to change that configuration, which means the MES stops improving the day it goes live.
 
Under-validation is rarer and more damaging when it happens, usually the product of a compressed final few weeks in which testing of integration edge cases and exception paths gets trimmed. Those are precisely the paths that generate deviations in production.
 
The guidance has moved further than most sites’ practice. GAMP 5 second edition (ISPE, 2022) puts critical thinking and risk-based effort at the centre of computerised system validation. The FDA’s Computer Software Assurance guidance, finalised in September 2025 and updated in February 2026, formalises the same least-burdensome logic, though it is worth being precise about its scope: CSA is issued by CDRH and CBER and applies to software used in medical device production and quality systems, not to drug GMP manufacturing. It is directionally influential for pharma validation thinking rather than directly applicable to it. GAMP 5 remains the operative reference for an MES in a drug manufacturing environment.
 
Either way, the practical question is the same: is your validation effort concentrated where patient risk actually sits, or distributed evenly across everything the system does?

3. The people trap

The most underestimated pattern, and the hardest to recover from.
 
MES projects run on a small number of site SMEs who understand the process deeply enough to design against it. Those people also have day jobs. When the project asks for 40% of their time and their line manager has committed them to full production support, the project gets whatever is left, which is usually meeting attendance rather than genuine design contribution.
 
The consequence appears at go-live. The design reflects what the project team assumed the process was, rather than what the process is. Operators encounter an electronic record that doesn’t match how the work is actually done, and they route around it, with workarounds, with paper, with informal sequences nobody has documented. Within a year, the site is running a shadow process alongside the MES.
 
There is also a handover dimension. A project that ends when the vendor leaves, with no resourced internal capability to own configuration, EBR authoring, and continuous improvement, is a project whose value peaks on day one and declines from there.

What the projects that hit the mark do differently

The projects we have seen deliver on their business case are not the ones with more budget or better software. They differ in four specific, unglamorous ways.
 
They define success in operational terms before design starts. Not “go live in Q3” but “reduce batch review time by 30%,” “halve documentation deviations,” “cut execution time per batch by 20 minutes.” Measurable, owned by the business, and reported after go-live rather than at it. This single change reframes every design trade-off the project makes.
 
They protect design depth over scope breadth. When something must give, they cut scope, not design rigour. A narrower phase 1 done properly builds the internal capability and credibility to deliver phases 2 and 3 quickly. A broad phase 1 done shallowly poisons the appetite for anything further.
 
They resource SMEs properly and in writing. Named individuals, committed percentages, backfilled by agreement with their line managers before the project starts. Where backfill isn’t possible, they narrow scope to the capacity actually available rather than the capacity they wish they had.
 
They plan for life after go-live. A named internal owner for EBR configuration. A budget line for post-go-live optimisation in the first year. A review at three and twelve months against the operational metrics defined at the start. An MES that keeps improving after go-live is worth several times one that is frozen the day the project closes.

The quiet miss

The site I described at the start eventually recovered. It took a second, smaller programme eighteen months after go-live: a re-examination of the EBR design, removal of a substantial number of prompts and verifications carried over from the paper process without challenge, and a rebuild of the review workflow. The shadow paper records disappeared within a quarter.

 

That remediation cost roughly a fifth of the original project. It would have cost almost nothing if the work had been done during the original design phase, when the team had budget, sponsorship, and everyone in the same room.

 

The most expensive MES projects are not the ones that fail visibly. They are the ones that succeed on paper and are quietly remediated for the next five years.

REFERENCES

About Pangaea Life Science Solutions

Pangaea Life Science Solutions is a Cork-based technology and consulting firm helping pharma and biotech manufacturers design, deploy, and optimise Manufacturing Execution Systems. We work with CIOs and operations leaders to convert paper batch records, modernise legacy MES platforms, and integrate AI into authoring and execution workflows without inheriting the process debt of the past.