I work for a company of <60 people. I understand that larger companies typically are ISO9000/9001 certified, as a matter of quality assurance. I also understand that for a company my size, such certification is not cost-effective. However, one could still make a case that as a matter of QA best-practice, I think it makes sense to try to follow the ISO standards anyway, at least insofar as reasonably practical. Am I correct in all these beliefs? If all the above is correct, are there any "high points" that would be particularly beneficial for a company my size to follow, or any parts of the standards that seem less relevant?
closed as off-topic by Robert Harvey, GrandmasterB, Jimmy Hoffa, World Engineer Jan 23 '14 at 19:56
- This question does not appear to be about software engineering within the scope defined in the help center.
Here's ISO9000 in a nutshell:
- Have a measurable process to develop things
- Make sure everyone involved understands and follows the measurable process
- Build things following the measurable process
- Measure your progress while you follow the process of building things
- Finish building things
- Evaluate how the things measure against what the process said they should be
- If there are issues then either fix the process or fix the thing or both
- Rinse & repeat
Nothing within that nutshell says anything about the size of the organization. Which is intentional because company size really has no bearing on whether or not it can meet ISO9000 requirements. Larger companies have an advantage because they have more resources and can potentially better afford the overhead of all that measuring, but small companies can do the same thing too.
So how can you follow ISO9000? Look at the summary steps above and go from there. The key elements are:
- have a process
- measure building progress based upon the process
- Fix the thing or the process when stuff is broken
I am actually going to suggest that you don't touch ISO at all if you're really interested in QA best practices. What ISO really boils down to is making sure that you "say what you do" and is completely unconcerned with whether or not what you say actually has any impact on the quality of what you produce. It's the quintessential example of a bureaucratic process that is more concerned with making sure that the process itself is followed rather than that it make sense (probably why it's so popular with the government).
We actually had an official auditor tell us that he didn't care if our documented deployment process was to burn our software to a disk and throw it out of a 3rd story window so long as we followed it.
To answer some of your actual questions: the big benefit you'd gain from ISO is that it would force you to actually sit down, think about, and document all your processes and periodically revisit them to see if you're sticking to them (and ideally revise them if necessary). There would be benefit to that but honestly, you really don't need ISO for any of that unless the only way to get the time and resources to do so is to sell upper management on it by use of a buzzword.