I came to ISO 9001 quite early on – my first programming job being a developer on core telecoms switching software. When even a minute’s downtime can lose tens of thousands of pounds, quality assurance takes on a higher priority than in some other cases. Right after this, I had a ringside seat for the implementation of ISO 9001 at my division in Unisys – a three month secondment abroad found me as a drinking buddy for the only other guy from the London office who visited regularly – the QA lead, who was helping my temporary hosts roll out ISO 9001. The main thing was that it didn’t turn out to be too onerous. Sure, there were a few extra hoops to jump through, but it largely just formalized what we already would do anyway as part of best practice.
Fast forward a few years and I’m working at a software company in Canada, and the question of possible ISO 9001 came up… and I was thrown by the strength of the negative reputation it had amongst my colleagues. It was, in their eyes, a mechanism by which busybodies with no real-world experience went on a colossal power trip by trying to legislate every aspect of how people's jobs were performed. My boss, who was also previously from Unisys, confirmed that they had good reason to think this – when the Unisys division in the USA that we had both worked with got ISO 9001 certified, they brought in consultants from the Republic of Ireland to do it, purely because US-based consultants were seen as unrealistic while the Irish were seen as pragmatists.
This was my first introduction into how the same standard can be seen in wildly different ways by different cultures. There have been others. When I first got ITIL certified, the trainer explained that ITIL had great trouble getting traction in the USA because managers there wanted something that you could simply adopt wholesale off the shelf (“OK, I'm sold. How do we buy ITIL then?”)
It's something that you notice working in different cultures. Some cultures are inclined to see any specification as an immutable rulebook that must be followed. Others see them as more what you'd call "guidelines" than actual rules. Where does this difference come from?
Part of the confusion here does seem to stem from a confusion on what a standard is. Even technical standards can often have optional components – witness how RFCs, the standards that are the building blocks of the internet, use the MoSCoW method (must /should /can/ won't) to prioritize different parts of their requirements. The difference is that with publications such as TOGAF, there are no 'must' parts of the standard that I'm aware of.
I think the other part comes from civics. It's noticeable that this tendency to treat specifications as gospel is most pronounced in countries that have formal constitutions and an inbuilt reverence for them. Perhaps the culture of respect for defined laws translates?