Skip to main content
← Back to Preview Pages

Developing Specifications

Free Preview

Covers developing procurement specifications as assessed in L4M8, focusing on technical, output, and outcome-based specification types.

Developing Specifications in Practice

This is an L4M8 application page. Specification theory — conformance vs performance, document structure, over/under-specification risks, value analysis — is covered in depth in L4M2 LO3. This page focuses on applying specification knowledge in L4M8 scenario answers.

Where Specifications Sit in the Procurement Cycle

Developing the specification is Stage 3 of the CIPS Procurement Cycle, preceding market testing and tendering. The examiner tests whether you can select the right specification type for a given scenario and justify that choice — not whether you can define "conformance specification."

Source cross-references: L4M2 LO3 (specification types, structure, risks, value analysis); L4M3 LO2 (specification as a contractual document; KPIs and SLAs); L4M8 LO1 (integrated procurement cycle application).

Specification Types: Application Rules

Conformance specification — prescribes exactly how the product must be made (dimensions, materials, tolerances, process steps).

Choose when: safety-critical items, proprietary IP, identical replaceable units across an estate, or exact legacy interoperability is required.

Risk: over-specification — tighter tolerances than function demands reduce competition and increase cost. Remedy: value analysis or shift to performance specification.

Performance specification — describes what the product or service must achieve, leaving the supplier free to choose how.

Choose when: complex or innovative requirements, the market has better technical knowledge than the buyer, or the contract duration is long and technology will evolve.

Risk: under-specification — outcomes that are not precisely measurable lead to contractual disputes over whether acceptance criteria are met.

Functional specification — a variant of performance specification focused on the function to be performed. Useful for services: "provide a nutritionally balanced meal for 500 staff on each working day" without specifying menus or staffing.

The Spec Development Process: Four Applied Steps

Step 1 — Define the functional need. Separate the genuine requirement from the current delivery method. A council specifying "the same diesel refuse vehicles we currently use" is specifying a solution, not a need. Framing it as "collection of domestic waste from X households per week, transported to a transfer station" opens the field to alternative vehicle configurations.

Step 2 — Gather stakeholder input. Name the stakeholders and state what each provides: end users (functional requirements and usability constraints), technical experts (safety and compliance standards), finance (affordability), legal/compliance (PA-2023 obligations for public bodies), and suppliers via RFI (early supplier involvement to identify requirements that add cost without adding value before the ITT is issued).

Step 3 — Set the specification sections. A complete specification covers: scope and purpose; technical requirements and standards references; testing and acceptance criteria; change control and remedies; ESG criteria (sustainability, Modern Slavery Act compliance — required for public contracts under the Social Value Act 2012 and PA-2023).

Step 4 — Validate against the market. Before finalising, test via RFI or supplier day: does the specification exclude qualified suppliers (over-specification) or attract unsuitable ones (under-specification)? This is consistent with PA-2023's competition and transparency principles.

How the Examiner Tests Specifications

Question typeCommand wordWhat a strong answer does
Choose spec typeRecommend / JustifySelects one type, states WHY it fits the scenario, acknowledges what the alternative gives up
Fault the existing specAnalyse / EvaluateIdentifies over- or under-specification with scenario evidence; recommends remedy
Write a specificationDevelop / PrepareUses the four-section framework; includes measurable acceptance criteria
Stakeholder conflictDiscuss / AssessNames conflicting positions; proposes a resolution process

Integration Across Modules

  • L4M3 (Contracting): The specification becomes a Schedule of Requirements. Once signed, it defines the supplier's obligation — the specification must be stable enough to serve as a contractual document.
  • L4M3 KPIs and SLAs: Measurable acceptance criteria in the specification are the foundation for KPIs. A specification without measurable criteria cannot support performance management.
  • L4M4 (Ethical Sourcing): ESG criteria embedded in the specification signal contractual requirements, not aspirations. Reference PA-2023's MAT criterion for public-sector scenarios.
  • L4M6 (Supplier Relationships): Early supplier involvement (ESI) for complex or innovative requirements produces better specifications and a more competitive market.

Common Mistakes

  • Defining specification types without recommending one — scores at definition level only.
  • Omitting acceptance criteria — a specification without them cannot be enforced.
  • Treating specification as a procurement step rather than a contractual document.
  • Missing ESG content in public-sector scenarios — under PA-2023 this will not reach Merit.
  • Ignoring stakeholder conflict — proposing a resolution is a Merit-level skill.

Sources: CIPS L4 Syllabus (Ref 603/3924/X) — L4M2 LO3 AC; L4M8 LO1 indicative content. CIPS L4 Specification. Procurement Act 2023 (commenced 24 February 2025). Social Value Act 2012.

Key Terms

Conformance SpecificationA specification prescribing exact physical characteristics — dimensions, materials, tolerances — giving the supplier no design freedom; used where standardisation is critical.
Performance SpecificationA specification defining required outputs or outcomes, allowing the supplier freedom to determine how to achieve them — encourages innovation and supplier expertise.
Early Supplier Involvement (ESI)Engaging potential suppliers during the specification or design stage to leverage their expertise, reduce specification errors, and improve value for money.
Over-SpecificationIncluding unnecessarily precise or excessive requirements that increase cost and restrict competition without adding value — as problematic as under-specification.
Statement of Requirements (SoR)A high-level document capturing an organisation's needs in functional/outcome terms before a detailed technical specification is developed — used to invite market dialogue.
Output SpecificationA specification defining the measurable results a supplier must deliver (e.g., system uptime 99.9%), without dictating inputs or methods — common in service contracts.
Input SpecificationA specification that prescribes the resources, materials, or processes the supplier must use — limits innovation but provides control over delivery method.
Specification BiasWriting a specification so precisely that it effectively limits competition to one supplier — potentially anti-competitive and unlawful in public procurement.
Market EngagementDialogue with potential suppliers before issuing a specification to understand market capabilities, test assumptions, and refine requirements — permitted under public procurement rules.
Scope CreepThe gradual, uncontrolled expansion of a specification or project requirements beyond the original agreed scope — leads to cost overruns and delays.
Functional SpecificationA specification describing what a product or service must do (its function), rather than how it must be made — a type of performance specification.
Brand or Proprietary SpecificationSpecifying a named brand or product — can be anti-competitive unless an 'or equivalent' clause is included; generally discouraged in public procurement.

Common Traps

  • Conformance = WHAT it is (physical); Performance = what it DOES (outcome) — this is one of the most tested distinctions in L4M8.
  • Over-specification is as dangerous as under-specification — always mention both risks when advising on specification development.
  • ESI can improve specifications but introduces IP leakage risk and potential lock-in — acknowledge both benefits and risks in exam answers.
  • Specification bias in public procurement can breach competition law — flag the legal/regulatory dimension when recommending specification approaches.
  • In case study questions, always link your specification recommendation to the TYPE of product/service and the market conditions shown in the scenario.

Ready to study more?

Create a free account to access all study pages and practice questions.

Get Started FreeTry Demo Exam