Prioritising PIM requirements with MoSCoW and weights

What is MoSCoW prioritisation for PIM requirements?

MoSCoW prioritisation sorts every PIM requirement into must, should, could or won't have this time. In a PIM selection, the categories decide what is a knockout and what is negotiable. This page is part of the PIM requirements guide, and it builds on writing testable PIM requirements.

The method comes from DSDM, the agile project framework maintained by the Agile Business Consortium. DSDM applies it to delivery effort. In a selection, the same logic applies to the requirement set. Every must adds a knockout test that the committee has to run and defend.

The published checklist sets a default priority for each requirement, aimed at a typical mid-market manufacturer. Treat it as the opening position for your own workshop.

How many must-have requirements should a PIM selection have?

Keep musts to a clear minority of the requirement set, and admit only requirements that pass two tests. When musts dominate, they stop separating vendors.

DSDM guidance keeps Must Have effort at no more than about 60 percent of total effort, with around 20 percent in Could Haves as contingency. In the published PIMvendors set, 86 of 240 requirements carry a default must, about 36 percent. Platform requirements on security, contracts and exit account for 22 of those musts.

PIMvendors applies two tests to every proposed must.

1. The walk-away test: would the committee reject a vendor that fails this requirement, even if it wins on everything else.
2. The proof test: can the vendor prove it in a demo, a document or a contract clause.

A requirement that fails the walk-away test becomes a should with a high weight. A requirement that fails the proof test needs rewriting before it can be prioritised at all. Both tests take a few minutes per requirement and remove most priority debates in the scoring session.

How do weights feed the demo scorecard?

Weights translate priorities into a score that ranks the vendors that pass all musts. The scorecard multiplies how well each requirement is met by its priority and the weight of its domain.

A practical model uses three inputs. Each requirement gets a fulfilment score after the demo or document check. Shoulds and coulds get a priority multiplier. Each domain gets a weight that reflects the business case. The table is an illustrative example, with weights that you set for your own selection.

The domain score is the sum of fulfilment times multiplier, divided by the maximum possible. The total is the weighted sum of domain scores. Musts are scored separately as pass, conditional pass or fail.

The demo scorecard gives the full template. In PIMvendors selections, the same IDs run through the checklist, the scenarios, the scorecard and the contract annex. Every score traces back to a requirement.

Who sets priorities and weights?

The buying committee sets domain weights, and the requirements owner sets priorities with each process owner. Splitting the decision this way keeps strategic choices at committee level and detailed choices with the people who know the process.

Domain weights express the business case. A distributor with hundreds of suppliers may weight process and integration above data model. A manufacturer facing PPWR and passport obligations may raise data model and platform. Agree weights in one committee session, with the business case on the table. The committee itself is described in aligning the buying committee.

Priorities are set requirement by requirement in domain workshops. The requirements owner chairs, applies the walk-away and proof tests, and records the reason for each must.

Two rules protect the outcome. Weights and priorities are fixed before vendors receive the scenarios. Changes after the freeze need a written reason and the owner's approval. Without these rules, priorities drift towards the vendor the committee liked best in the demo.

How should regulatory and won't-have requirements be treated?

Treat regulatory requirements as musts by default and list won't-haves explicitly. Both reduce debate later in the selection.

Regulatory requirements have fixed dates. PPWR applies generally from 12 August 2026, and GPSR has applied since 13 December 2024. A PIM that cannot hold the required data creates a compliance gap, whatever its other strengths. The checklist tags 20 published requirements with a regulation. Review each against your product scope, keep the applicable ones as musts and record the regulation as the reason.

Won't-haves deserve the same discipline. Typical examples are print catalogue production, a B2B ordering portal or pricing management. Listing them stops vendors from spending demo time on out-of-scope functions. It also stops scorers from rewarding those functions.

Keep won't-haves in the requirement sheet with the status won't and the target phase. They become the starting point for the second phase of the roadmap once the core PIM is live.

Common prioritisation errors

Most prioritisation errors come from deciding too late or too uniformly. The table lists the patterns PIMvendors sees most often and the fix for each.

Prioritisation is quick when the requirements are well written. Each step in this page assumes testable requirements with a process trace, as described in the PIM requirements checklist.