[caption id="attachment_368" align="alignleft" width="300" caption="Rusty Car"]A rusty car[/caption]

I just finished 'Here Comes Everybody', a must-read for anybody trying to understand what is going on with all this social media stuff. One point Clay Shirky makes, is that  the various web2.0 tools make failing cheap.

If in the 80s you had an idea for a group to form, you had a lot of things to do, many of which cost money: Finding a room to meet, printing fliers or ads to promote your idea and so on. If your idea failed, all that money was wasted.

Compare that to the situation today. Create a webpage, and promote it using facebook, twitter, xing or many of the other tools is free. All you have to invest is your own time. If it fails, nothing is lost. Actually something that fails today might get picked up tomorrow by somebody else and brought to success. Like a wikipedia article which is a stub at first, but then evolves in a well written article, through many mostly small changes an improvements. If one of the changes is bad, again the cost of this is minimal. Somebody will notice it and revert the change. Cost: a couple minutes of online time for bad article and 5 minutes work. Compare that to a typo in a printed encyclopedia. Fixing a typo would cost thousands of euros. So it won't get fixed until the next revision which might take years to come.

So where is the relationship to the title of this post, namely the ISO 9001? One of the corner stones of modern quality management is to prevent errors to happen. This is a good thing under the assumption that fixing errors is way more expensive then preventing them. For building a car, this is probably still true: "Oh the brakes didn't work? Probably because we installed any in the first place. Let me fix that right away. What do you mean, you don't want them anymore? Oh you are dead ... I see." But for building software, for creating documentation for the software, for gathering requirements of the software, this assumption is wrong in many cases.

I am trying to write clean code, tested code, working code all the time and I expect my coworkers to do the same. But that doesn't prevent me from checking in less then perfect code into the version control system. Because as soon as it available for others to see and to use, they might find bugs, or even fix some. They might provide feed back for improvement or further development of the piece. I would not accept a rule that disallows less then perfect code (or documentation) to be seen by others.

So, is ISO 9001 obsolete? I'd say NO for the following reasons:


But there are a couple of things that pop up around ISO 9001: Lengthy specifications and lengthy review processes of that specification. Many companies like to create those, and many people seem to think they are a requirement of the ISO 9001. This is not true. The norm requires that you know what you need, before you build it. A specification of the complete system certainly fits that requirement. But since you don't create a complete new CRM in an afternoon, you don't need the complete specification.

If you agree with a customer on a couple of user stories to be implemented in the next two weeks, and write those down on a whiteboard or in a webbased application or on some sheets of paper, any auditor of ISO 9001 conformance will have a problem criticizing that. If you use a whiteboard, you might want to make a photo of that. And if you write it down as a Fitnesse test, the auditor will probably be impressed.

So no, ISO 9001 is not obsolete. What is obsolete are ways of implementing the ISO 9001 that are damaging the reputation of that norm.