2

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?

Stephen Collings
  • 597
  • 5
  • 8
  • At our company, we wrote a streamlined software development process that maps to ISO9000, but is customized to our particular way of doing business. You should do the same. – Robert Harvey Jan 23 '14 at 17:13
  • 1
    This might be useful for you: http://programmers.stackexchange.com/questions/81427/can-agile-and-iso-9001-interact-well – DXM Jan 23 '14 at 17:40
  • @DXM don't know why that didn't come up in my pre-question searches. Great info! Thanks. – Stephen Collings Jan 23 '14 at 17:56
  • Larger companies are *not* "typically" ISO9000/9001 certified. Larger companies don't tend to do any more than they need to in the course of being productive and effective. While some may say ISO practices help in this goal, large companies would often rather use the parts that make sense to them and not worry about meeting a fixed criteria as necessary to get such certification. As such, ISO certification is much more common among companies that have specific reasons to have a focus on formal quality; medical/healthcare, aeronautical, and manufacturing sectors it's common for instance. – Jimmy Hoffa Jan 23 '14 at 18:25
  • @JimmyHoffa That's my experience too. The only reason the company I work for is ISO certified is because a lot of government contracts require it. It's honestly a pretty horrible process for software development imo and one of the main reasons why our "scrum" process is a horrible joke. I see next to no advantage in voluntarily adopting ISO if you don't need it for contract purposes. – Evicatos Jan 23 '14 at 18:54
  • 2
    This question appears to be off-topic because it applies to companies in any industry. – GrandmasterB Jan 23 '14 at 19:42
  • @GrandmasterB fair enough. Wasn't sure whether questions that applied to programmers, but also to others, were in scope. – Stephen Collings Jan 23 '14 at 19:48
  • Its not a bad question at all. Maybe you can focus it more on software development processes? For example, if followed, what techniques can be used to 'measure' a software dev process? – GrandmasterB Jan 23 '14 at 19:49

2 Answers2

3

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
0

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.

Evicatos
  • 662
  • 6
  • 12