PLM Requirements and RFP: How to Write Them Well

Short answer

A PLM request for proposal (RFP) is a structured document that describes a company's product processes, data volumes, system landscape and weighted requirements, and asks vendors to respond in a fixed format. Good PLM requirements are written as testable scenarios with acceptance criteria, typically 150 to 400 items, grouped by domain and prioritised.

Key takeaways

Write requirements as scenarios with measurable acceptance criteria so vendors can be differentiated.
A typical PLM catalogue holds 150 to 400 requirements, with Must items kept below 30%.
Fixed response codes with mandatory evidence make vendor answers comparable.
Include data volumes and a 5-year commercial template to allow like-for-like cost comparison.

Requirements describe outcomes, scenarios and constraints

Weak PLM requirements read like feature checklists: "the system shall support BOMs". Every vendor answers yes, and the RFP produces no differentiation. Strong requirements describe a business outcome, the scenario in which it occurs and the measurable acceptance criterion. Compare these two versions:

Weak: "Support engineering change management."
Strong: "An engineer raises a change request on a released part used in 40 assemblies. The system shows all affected assemblies, open orders and documents, routes the request to a change board of 3 roles, and records the decision with a timestamp. Acceptance: impact list generated in under 1 minute."

The strong version can be scored, demonstrated and later tested in user acceptance testing. Background on change processes is in engineering change management.

Structure the requirements catalogue

A typical PLM catalogue holds 150 to 400 requirements (estimate). More than 500 usually signals duplication or copied templates. Group them in a stable structure so that vendors can respond consistently:

Domain	Examples	Share of catalogue (typical)
Product structure	Part numbering, EBOM, MBOM, variants	20 to 25%
Change and release	ECR, ECO, effectivity, approvals	15 to 20%
Documents and CAD	Vaulting, viewers, CAD integrations	10 to 15%
Compliance and sustainability	Substances, carbon data, product passport fields	10 to 15%
Integration	ERP, PIM, MES, supplier portals, APIs	10 to 15%
Non-functional	Security, hosting, performance, data residency	10 to 15%
Commercial and service	Licensing, support, roadmap, partner network	5 to 10%

Compliance requirements have grown since 2024. The Ecodesign for Sustainable Products Regulation (EU) 2024/1781 and the Packaging and Packaging Waste Regulation (EU) 2025/40 both create product data obligations that PLM often feeds. See Digital Product Passport requirements for the fields typically requested.

Prioritise with MoSCoW and weights

Tag each requirement as Must, Should, Could or Won't. Keep Must items below 30% of the catalogue, otherwise the category stops discriminating. Then apply domain weights from the selection scoring model described in how to select a PLM system. Ask vendors to answer each line with a fixed code:

4: standard functionality, available today, configuration only
3: standard with minor configuration or low-code extension
2: available through a certified partner add-on
1: requires custom development (vendor provides effort estimate)
0: not supported

Require a short explanation and a document reference for every answer of 3 or 4. Answers without evidence are scored one level lower.

Assemble the RFP document

A complete PLM RFP usually contains six parts:

Company profile, product portfolio, sites and user numbers per role
Current system landscape and integration diagram
Scope, out-of-scope items and target timeline
Requirements catalogue in a spreadsheet with response codes
Commercial template: licences, subscription tiers, implementation, support, 5-year cost
Process rules: deadlines, contact person, evaluation method, confidentiality

Give vendors 3 to 4 weeks to respond and hold one clarification round with written answers shared with all bidders. Public bodies and some utilities must follow Directive 2014/24/EU on public procurement, which governs publication, equal treatment and award criteria.

Evaluate responses consistently

Have at least two evaluators score each domain independently, then reconcile differences in a moderation session. Flag responses where many Must items rely on partner add-ons or custom development, because these drive cost and upgrade risk. The commercial template allows a like-for-like comparison of total cost of ownership over the same period.

Common mistakes include copying a requirements list from another company, leaving data volumes out (vendors then cannot size performance or price), and asking for a fixed implementation price before the scope is stable. Scenarios from the requirements catalogue become the script for scripted vendor demos, which test whether written answers hold up.

Keep the catalogue alive after selection

The requirements catalogue does not end with contract signature. Implementation partners use it to plan configuration sprints, test managers derive acceptance tests from its criteria, and the steering committee uses it to decide change requests. Maintaining version control on the catalogue avoids disputes about what was promised during the tender.

Frequently asked questions

How many requirements should a PLM RFP contain?

Most effective PLM RFPs contain 150 to 400 requirements, depending on scope and industry. This is a typical range. Catalogues above 500 lines tend to contain duplicates and generic items that every vendor confirms, which makes scoring slower without improving the decision.

Should the RFP ask for a fixed implementation price?

A fixed price is only meaningful once scope, data migration volume and integrations are stable. At RFP stage, ask for an indicative estimate with stated assumptions, a day-rate card and a phased plan. Fixed pricing fits better after a proof of concept or a short paid scoping phase.

Who should write the PLM requirements?

Process owners from engineering, manufacturing, quality, compliance and product data management write the functional requirements. IT architecture covers integration and non-functional items, and procurement owns commercial terms. A neutral facilitator often consolidates wording so that each requirement follows the same scenario and acceptance format.

Sources

Reviewed 16 October 2026 by the PLM Vendors editorial team. Regulatory dates and vendor details change; check the sources for the latest position.