Why Your MES RFP Is Failing Before It Starts
By Andreas Grossman, Christian Berg, Ciera Clayton, Emilee Cook, Ines Kaci, Katherine Farley, Kim Wilson, Kortney Gunther, and Mooch Agirtmis, members of BioPhorum
Many manufacturing execution system (MES) requests for proposals (RFPs) fail long before a contract is signed. Not because vendors cannot deliver or the technology is immature, but because the requirements themselves are written backward.
In regulated manufacturing, RFPs and user requirement specifications (URSs) are often filled with detailed descriptions of architectures, features, and workflows. They read like system design documents rather than expressions of a business or quality need. What is usually missing is a clear description of the problem the organization is trying to solve and the outcome it is trying to achieve.
The MES of the Future Manifesto1 and its 2025 Progress Report2 both concluded that vendor innovation has accelerated while adoption has slowed, primarily due to organizational readiness and legacy practices, i.e., the same dynamics that drive RFP over‑specification.
This is not a new observation. As procurement researchers at Harvard have noted,3 RFPs should begin by clearly defining the problem the organization is trying to solve and the outcomes it is seeking to achieve, rather than specifying particular solutions. Yet when it comes to life sciences manufacturing systems, we repeatedly do the opposite.
When Requirements Describe “How” Instead Of “Why”
It is common to see requirements such as:
- The system shall enforce dual verification at every execution step.
- The system shall follow the current paper‑based process.
- The system shall apply electronic signatures after each operation.
These statements sound precise and defendable, but they are not true requirements. They are implementation decisions.
ISPE guidance has been clear on this point for years. In Pharmaceutical Engineering, ISPE4 states that the URS document should not contain engineering specifications or the means by which user requirements are met. And yet, many URSs still do exactly that.
The result? When requirements dictate solutions, vendors respond to checklists, not needs. Compliance may be achieved but real value is often not.
A requirement such as “The system shall require a username, password, and electronic signature for each critical action” may appear compliant and precise, but in reality, it implicitly eliminates alternative approaches before they are even considered. For example, hardware-based biometric authentication could provide stronger assurance of operator identity, reduce the risk of sharing credentials, and streamline execution by removing repetitive login and signing steps. As one VP of product at an MES vendor company explained to us for this analysis, “If the requirement is written in solution-specific terms, other options are then excluded, regardless of whether it better achieves the underlying goal.”
By contrast, a outcome-led requirement would state the need for high confidence in a user’s identity, nonrepudiation of GMP actions, and minimal disruption to operations, allowing suppliers to propose and justify different mechanisms within regulatory constraints.
Over-specification does not just constrain vendors; it narrows the organization’s own ability to evaluate safer, simpler, or more resilient solutions.
As another MES vendor company expert noted, many RFPs already include architecture diagrams and detail all the systems and how they are connected. “Although this might seem helpful, even if workflows are described, vendors don’t always understand where the real friction is.” For example, they will not know where people perform manual workarounds or where decisions are taken. Without this context, vendors may just replicate the existing process instead of improving it.
Why Solution‑Driven RFPs Persist
This behavior is understandable, especially in regulated environments.
It is because certainty feels safer than ambiguity, a feature can be audited, a configuration can be validated, a checklist can be defended, and describing a problem and trusting the emerging solution can feel risky.
But this perceived “safety” comes at a cost. As Hank Barnes, leader of tech buying dynamics research at Gartner, observed in the context of modern technology buying,5 in a world where outcomes are unclear, an RFP full of detailed requirements is a whole lot of effort for a decision that will most likely come with regret.
Legacy validation practices reinforce this pattern. Over‑specification is often mistaken for risk management, even when it leads to unnecessary testing, brittle configurations, and reduced flexibility. These patterns are not unique to procurement; the MES Industry Challenges and Enablers6 paper highlighted how over‑customization, validation burden, and misaligned expectations slow MES progress across the industry.
The Real Downstream Impact
It’s not just RFPs containing overly solution‑led requirements that cause real harm and limit value. From a validation standpoint, poorly framed URSs are also a known issue. As GMP Insiders7 noted, poorly written URS documents remain a common root cause for project delays, qualification issues, and audit findings. The issue is rarely that too little was specified but that too much of the wrong thing was.
From an innovation perspective, problem/outcome‑based thinking has consistently been shown to work better. Lean Compliance8 summarized this as: when the means are specified rather than the outcomes, innovation is constrained and accountability for results becomes blurred. In MES programs, this often shows up as over‑customization, difficulty upgrading, and systems that are technically compliant but operationally painful.
In addition to this, over‑prescribed and solution‑driven RFPs do not just create clunky requirements, they directly reinforce the industry’s biggest MES challenges, as outlined in the Industry Challenges & Enablers paper,6 which are:
- Higher cost and slower time‑to‑value
When requirements dictate specific solutions, implementations become heavily customized. This drives a higher total cost of ownership and slower value realization because each deployment becomes a bespoke effort requiring significant setup, configuration, and validation. - Longer implementation timelines
Custom workflows and rigid specifications extend configuration and validation cycles. This mirrors one of the industry’s core challenges — slow MES implementations driven by a manual, highly tailored setup. - Integration that is harder, not easier
Prescriptive RFPs frequently lock organizations into brittle, point‑to‑point integrations. This compounds the already significant integration complexity described in the challenges paper,6 where inconsistent data structures and bespoke engineering slow down change and inflate effort. - Reduced ability to evolve or upgrade
Encoding solutions directly into the URS hard‑codes logic into the MES platform. This increases technical debt and makes future upgrades disruptive, because small updates require wide‑ranging regression testing across the entire system. - Increased downtime risk
Every customization increases the validation surface and introduces upgrade fragility. Over time, this leads to deferred upgrades, accumulated technical debt, and larger, riskier change windows — one of the major industry pain points contributing to both planned and unplanned downtime. - Fragmented quality processes and slower batch release
Solution‑heavy RFPs often embed local practices rather than enterprise‑level outcomes. This fuels the fragmentation of data and batch review processes that slows release cycles and prevents review‑by‑exception or automation.
In short, many of the industry’s persistent MES challenges, high cost, slow implementations, fragile integrations, rigid architectures, downtime, and fragmented quality, are unintentionally created at the RFP stage. When we prescribe solutions instead of describing problems, we lock in the very barriers we later struggle to overcome.
Reframing Requirements Around Problems And Outcomes
An outcome-led requirement does not abandon rigor. It redirects it.
Instead of stating: “The system shall enforce operator authorization checks at each step,” an outcome‑led requirement would state: “The organization needs confidence that only appropriately authorized personnel can perform GMP‑critical activities while avoiding unnecessary execution delays or operational complexity.”
This single shift changes the conversation. Vendors can propose different approaches, quality teams can assess risk more meaningfully, and validation effort can be aligned to what actually protects product quality and patient safety.
The Managing Data as a Product paper9 highlights a similar challenge: teams often define data structures, workflows, and system behaviors before articulating the business problem the data must solve. The paper stresses that without a clear statement of purpose, organizations default to replicating existing processes rather than designing for improved outcomes or simplified operations. This reinforces the shift that RFPs must make: from describing how data should be captured to defining what decision, process, or value the data must enable.
This approach is also supported by outcome‑based procurement guidance,10 which cautions that detailed technical specifications may limit options and result in incremental improvements rather than innovative solutions.
A Practical Shift: What To Stop Doing And What To Start Doing In MES RPFs And URSs
Shifting from solution‑led to outcome‑led requirements does not require a complete rewrite of governance models or validation approaches. In practice, it often starts with stopping a few habitual behaviors and replacing them with more intentional ones (see Table 1).
Table 1: The shift from habitual to intentional habits
A senior product manager of MES put it to us as “problem‑focused RFPs allow us to challenge legacy assumptions, modernize execution approaches, and leverage native MES capabilities instead of re-creating outdated paper processes in a digital form.”
When RFPs shift from specifying solutions to describing problems and desired outcomes, vendors can deliver platforms that are more scalable, upgradeable, and process innovation-ready.
RFPs should highlight:
- process variability and where it impacts performance or compliance
- specific operational challenges, rather than predefined screen flows
- critical quality risks and required controls
- desired outcomes and measures of success, not rigid step sequences.
The Navigating the Data Maze11 paper reinforces this shift. It shows that many MES programs struggle because teams attempt to capture or specify far more data than is required for quality, process control, or operational decision‑making. Without clarity on which data points are truly critical, requirements documentation often becomes bloated with low‑value details that increase complexity, validation burden, and solution rigidity. By defining priority data first — which is the information essential for decisions, compliance, or performance — organizations can write RFPs that are clearer, leaner, and more aligned with real business outcomes rather than inherited process habits.
Why This Matters Now
As the industry explores modern MES architectures, increased use of managed services, and early AI‑enabled capabilities, problem definition becomes even more critical. This is highlighted in the paper Mapping the Pathways to MES in the Cloud12, which noted that unclear expectations around ownership, validation, and architectural constraints frequently lead organizations to over‑specify solutions in RFPs as a risk‑avoidance mechanism.
ISPE GAMP13 guidance warned against exactly what we see in many MES RFPs today. In its work on enabling innovation, ISPE noted that “unthinking,” prescriptive, and rigid approaches are often not commensurate with the real risk to the product and the patient.
In other words, over‑control does not equal better quality.
From an MES‑specific perspective, the link to value is clear. As one industry commentary puts it,14 vague or misaligned requirements lead to over‑customization, ballooning costs, and missed return on investment. The more we prescribe solutions up front, the harder it becomes to adapt, upgrade, or adopt new capabilities later.
The Real Purpose Of An RFP
An RFP is not meant to describe the system you already know how to build. It is meant to help you discover the best way to stop living with a problem you have outgrown. If the industry wants faster adoption, clearer business value opportunities/realization, and safer innovation, it must get better at describing problems before prescribing solutions.
The more precisely we dictate solutions in MES RFPs, the less likely we are to get the outcomes we actually want. Instead, the proposed approach has the potential to create a far stronger foundation for collaboration between manufacturer and vendor, giving both sides a shared, transparent understanding of real operational challenges.
That transparency not only enables vendors to propose more innovative and effective design options but it also builds the trust needed for a long‑term, partnership‑based relationship.
References:
- MES of the Future Manifesto. 2022. BioPhorum, IT Digital and Data, MES of the Future
- Advancing MES solutions for biomanufacturing: Manifesto progress report. 2025. BioPhorum, IT Digital and Data, MES of the Future
- Guidebook: Crafting a Results-Driven Request for Proposals. 2021. Harvard Kennedy School – Government Performance Lab
Available from: https://govlab.hks.harvard.edu/wp-content/uploads/2021/02/gpl_rfp_guidebook_2021.pdf - Q&A: User Requirements Specifications Related to Commissioning. Pharmaceutical Engineering. ISPE iSpeak. 2020. International Society for Pharmaceutical Engineering (ISPE)
Available from: https://ispe.org/pharmaceutical-engineering/ispeak/qa-user-requirements-specifications-related-commissioning - The Problem with Requirements Driven Tech Buying. Gartner / LinkedIn Pulse. 2023. Barnes, H
Available from: www.linkedin.com/pulse/problem-requirements-driven-tech-buying-hank-barnes-c3a6c/ - Manufacturing execution systems (MES): industry challenges and enablers. 2025. BioPhorum, IT Digital and Data, MES of the Future
- How to Write a User Requirement Specification (URS). 2025. GMP Insiders
Available from: https://gmpinsiders.com/how-to-write-user-requirement-specification-urs/ - Outcome‑Based Specifications. Lean Compliance
Available from: www.leancompliance.ca/post/outcome-based-specifications - Managing data as a product for digital transformation in the pharmaceutical industry. 2024. BioPhorum, IT Digital and Data, Data Enablement for AI
- Outcome‑Based Specification Guide. 2022. Ontario Centre of Innovation (OCI)
Available from: https://www.oc-innovation.ca/wp-content/uploads/2022/01/05-OCI-IPT-Outcome-Based-Specification-Guide-Jan-2022.pdf - Navigating the data maze: a practical guide to defining priority data in MES. 2024. BioPhorum, IT Digital and Data, MES of the Future
- Mapping the pathways to MES in the cloud: addressing challenges and unveiling opportunities. 2024. BioPhorum, IT Digital and Data, MES of the Future
- GAMP Good Practice Guide: Enabling Innovation. 2021. International Society for Pharmaceutical Engineering (ISPE)
Available from: https://ispe.org/publications/guidance-documents/gamp-good-practice-guide-enabling-innovation - Why MES Success Starts Before the RFP. 2025. Andea
Available from: www.andea.com/resources/blog/why-mes-success-starts-before-the-rfp/