ISO 9001 - repris
Well, I've just got back from a period of internet isolation due to the inability of BT to fix an ISDN connection... Here's hoping!
Catching up on the important stuff I was touched by the irony of Alex's posting on European Software Development, which turned into a flame of ISO 9001, alongside Poor, poor me's horror story.
I'm not an ISO 9000 consultant, but I do have the experience of having introduced an ISO 9001/TickIT certified process into my own company. All I can say is that it was a Good Thing.
First thing, ISO 9001 is a standard that is applicable to the design and manufacture of anything. So if you're going to apply it you first need to profile it, in the sense of shaping it to the specific needs you have. There is a 'canned' profile for software development (at least in the UK) called TickIT, so anyone looking for a consultant to help formulate a process should look for that label, not just ISO 9001.
Second, it needn't be difficult and it most definitely needn't be bureaucratic. All ISO 9001/TickIT really requires is that you have in place a describable process that, when correctly applied, will allow you to create the product that you want; and that this process has sufficient traceability to be auditable.
In practice the overhead (i.e. the work over and above the processes needed to carry out any form of controlled software development) can be very little. We built our quality system around an issue management system that we used to collate requirements, log the creation of 'artefacts' (UML/ERD/spec documents and code/object modules/applications etc.) and create and track bug reports/ test feedback. From what I've heard of FogBUGZ, I think it could be highly applicable. In addition all you'll absolutely need is a code control / configuration management system (we used RCS 'cos it was free).
Having ISO 9001/TickIT certification will only be bureaucratic if you make your software development process bureaucratic. We didn't. It wasn't. All of the 'quality manual' - which is really just the description of how the development process works - was on our intranet. (In fact our process stated that the intranet version was the definitive version, so print outs etc. could always be binned)As the system developed we also included a lot 'how to' documents - how to name classes, methods, files etc., how to check code out and in, how to build etc. This stuff was really useful for new hires.
Why was 9001 so useful? First, because getting the certification made us look carefully at what we did and how we could do it better. Second, and more importantly, because to get certification one thing that is needed is a CEO / Board level statement of their commitment to quality. Once you've got that you've pinned a leg of the quality - time - cost triangle.
Marketing can be guaranteed to shout 'ISO 9001 certified' from the rooftops, which means that when they try to force product creep you can point out (a) that there is an agreed process by which features are introduced into products, (b) that the process must be used and (c) that failure to use that process could (in fact should) result in the company losing its 9001 certification. This is way serious for any publicly quoted (or pre-IPO) company as it's market sensitive information that will affect the share price. Touche!
Finally, ISO 9001 has a requirement for a feedback loop, so if you're trapped in a company that implements a highly bureaucratic process, raise process issues through the system itself. Make it clear that the bureaucracy is leading to subversion of the system. The owner of the process (our quality manager was actually our management accountant!). I would suggest that the response will be rapid because the first thing the certification authority will do in the next audit will be to check the efficacy of the system. Outstanding problems with the QA system itself go into the bucket of Very Bad Things. In fact the chances are that if you raise an issue the auditor will ask you whether it's been adressed to your satisfaction.
We used this feed back loop in what, I hope, was a very positive way. We started with a very lightweight quality manual which was then periodically improved, usually because one of the developers came up with a good idea - like wouldn't it be useful to have a naming convention for RCS changesets? Or, can someone please tell me how I build this on both Windows and Solaris?
Absolutely finally, if you are working in a company that doesn't have a certified process, try to get one. More important still, try to be involved in its creation; that way you can ensure that good practices (like unit testing) are incorporated and bad ones (name your own pet hate here...) are not.
Anyone wanting more details on what we did, e-mail me direct.
P.S. I meant to mention that the expensive part of 9001 certification tends to be setting up the system in the first place - which must be where Joel gets spooked about "paying bogus ISO 9000 consultants a kings ransom to certify them". You can, however, do almost all of the work yourself using a consultant simply to guide the process and to run a 'mock certification'. The actual certification agency costs are fairly small and can easily be fixed in advance (we used Det Norske Veritas, but Lloyd's Register and BSI are about the same price) .
Thursday, July 17, 2003
I work for an ISO 9000 certified company - a major telco manufacturer. The area I work in (simulation and modelling) is now improving its process. I have to agree with you that it needn't be a chore.
To praece your post even further. Processes are a good thing when implemented by smart people who understand the goal of the process. They are a bad thing when implemented as a layer of mindless beaurocracy :-)
Friday, July 18, 2003
BT isdn? What are you, a millionaire?
Much cheaper on the continong
Friday, July 18, 2003
Would that I were! I work a lot from home, needed a better connection than a 56K modem and have no chance of getting ADSL.
Ironically there is a plaque on the wall of my local exchange commemorating the fact that it was the site of the first digital exchange in Scotland. By my reckoning it must have been a test installation of the infamous Plessey System X and the exchange was selected because it served a handful of teuchters (now that's a good, local word) who never used the phone and consequently were unlikely to break it!
Maybe I should put up a prize for naming the exchange and the best translation of teuchter.
Friday, July 18, 2003
Fog Creek Home