I'm reading this cool little book titled 201 Principles of Software Development. It's a fun read - I get through five or six principles each morning waiting for the bus.
I've long seen parallel principles among software development, technical communication, and instructional design. I'm still convinced that there are a set of universal principles that apply to all design/development disciplines. The few principles in the book that address quality remind me that there are core considerations all designers/developers need to work from.
In technical communications (and software development), the word "quality" does not have a singular meaning. The subjective nature of seeing quality in an information product makes measuring quality a moving target. And this is something that technical communicators need to understand. On some projects, quality might be an elegant document design or logical information structure. On a lot of projects, quality might be delivering a solid, functional product in a timely and cost-effective manner. The issue for technical communicators is that not all definitions of quality are compatible. That's where the fun in the project meetings begins.