Quality Management Systems: ISO 9001 and BS 5750

EveryEvery framework covered elsewhere in this series — Waterfall's stage gates, Scrum's sprint cadence, a WBS's decomposition — answers "how do we plan and sequence the work?" This page and its two companions answer a different question: once work is happening, how does an organisation know, systematically rather than by hoping, that what it produces is actually any good? That's the question quality management standards exist to answer, and the best-known one, ISO 9001, has a British origin most people using it today don't know about.

BS 5750: The British Original

BSBS 5750 was published by the British Standards Institution in 1979 as a Quality Management System (QMS) standard, developed from earlier defence-procurement quality guidelines and written, like most quality standards of its era, from a manufacturing viewpoint¹. In 1987, following international interest in adopting a common quality-management standard, the International Organization for Standardization issued ISO 9000/9001/9002/9003 based substantially on BS 5750, and BSI in turn republished BS 5750:1987 to align with the new international standard². BS 5750 was eventually withdrawn in the UK in favour of ISO 9001 outright — so for practical purposes, anyone encountering "BS 5750" today is looking at the direct ancestor of the standard now simply called ISO 9001, not a competing or alternative one.

What a QMS Actually Requires

ISOISO 9001 does not specify what quality a product or service must have — it says nothing about acceptable defect rates or performance thresholds. It specifies that an organisation must have a documented, followed, and continually improved system for managing quality, built around a few recurring ideas:

• Documented processes. How work actually gets done is written down, not tribal knowledge that leaves when a person does.
• The Plan-Do-Check-Act (PDCA) cycle. Plan a process, carry it out, check the results against what was intended, act on the gap — then repeat. This is the same feedback-loop discipline this site's estimation and retrospectives page argues for at the level of individual project learning, applied here at the level of organisational process.
• Traceable records. Evidence that the documented process was actually followed, not just written down and ignored — the same "process over product" distinction this site's Process Over Product page makes for an individual student project applies at organisational scale: a QMS audits the process that produces outcomes, not any single outcome in isolation.
• Third-party certification. An accredited external body audits the organisation's actual practice against its documented system and issues (or withholds, or later revokes) certification — the mechanism that makes "ISO 9001 certified" a claim a customer can trust rather than a company's own assertion about itself.

Why It Doesn't Translate Naturally to Software

BothBoth BS 5750 and the ISO 9001 it produced originated in physical manufacturing and defence-procurement contexts, where "quality" has a relatively direct meaning: does the manufactured part meet its specification, consistently, batch after batch? Software doesn't fail that way. A line of code doesn't wear out, drift out of tolerance, or vary between "units" the way a machined part can — but it can be subtly, catastrophically wrong in ways no physical-inspection vocabulary captures well, and "verification" for software means something closer to "did we prove this does what it's supposed to" than "does this part measure within tolerance." Applying ISO 9001's own generic language directly to software teams tends to produce exactly the failure mode a lot of critics associate with the standard: box-ticking documentation that satisfies an auditor without engaging with what actually makes software good or bad³.

This is precisely the gap the next two pages in this cluster exist to close — not by abandoning ISO 9001's underlying discipline, but by translating it into vocabulary and processes that actually fit how software gets built:

• ISO/IEC/IEEE 90003 and ISO/IEC 12207 — the official ISO-family answer: a direct software-specific guideline for implementing ISO 9001 (90003), and a dedicated software lifecycle-process standard (12207).
• CMMI — the alternative, software-and-systems-native approach: not a pass/fail compliance standard at all, but a five-level maturity model asking how controlled and repeatable an organisation's development process actually is.

Which of the two an organisation reaches for tends to track the same forces discussed in Choosing a Methodology — regulatory and contractual context pulls toward the ISO family's formal certification; a tech-native engineering culture more often reaches for CMMI's maturity framing, or treats quality as continuous engineering practice (testing discipline, code review, CI/CD) without seeking either formal certification at all.

References