I'm a former manufacturing engineer who made the leap to programming. I started my own software company last year, and it has been an interesting experience from a process perspective.
One of the first books recommended to me was The E-Myth Revisited by Michael Gerber. For those not familiar with it, it's a book about not making the mistakes that most entrepreneurs make. In short - making sure you own the business - not letting the business own you. The major point of the book is that you need to standardize and document your business processes.
Having made a career as a process wonk, this book struck me as 200 pages of "Duh!"
Then one day that "Duh!" came around and smacked me in the forehead. I'd been having a bad week. First, I hadn't automated my builds yet for a new product in development, and I forgot a step - costing me several hours to figure out what the problem was. Then, I spent several hours sorting out support document version discrepancies because I hadn't standardized my file synchronization between my laptop and desktop. After that I had several more problems, when it dawned on me that none of them would have happened if I standardized, documented, and/or automated my business processes.
A few years ago I stumbled upon The Joel Test, 12 Steps to Better Code, written by Joel Spolsky of Fog Creek Software:
1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?
So I adopted this list as a starting point for standardizing my business processes. Not all of these apply to me as a single developer, and I've added a lot of my own, especially in regards to testing. I've found by keeping a simple set of standard processes I have less errors and my productivity goes up accordingly. This basic stuff, of course, but it's a little harder to step back and look at your processes objectively when you run your own businesses.
So, after all this rambling, what's my point?
Um, I'm not sure. It's been so long since I started typing that I forgot. No, wait. I remember now ... my point is that when you start to focus on quality for it's own sake, then implementing ISO seems more like a cargo cult[1] actvity than a real quality enhancement.
[1]
http://www.physics.brocku.ca/etc/cargo_cult_science.html