I admit, when first introduced, it wasn't something I found particularly interesting, however my attitude changed when I realized how closely the items in ISO 9001 parallel software development.
ISO 9001 defines quality as follows
Quality - degree to which a set of inherent characteristics fulfills requirements
In my recent job role incarnation, I preform the role of a business analyst, this means a big part of my job is to identify requirements.
So the better I can correctly identify those requirements, the better I can explain them to those doing the development, the better chance at delivering a solution that meets those requirements.
If only life were that simple! - When I was a quality manager, our company developed policies, procedures, and checklists, all aimed to produce a consistent product. Consistency meant that any 'item' plucked would contain the same set of characteristics. This item may be a physical product, or a service. The way we responded on the phone to a customer, the way we packaged and shipped an item, the way we reviewed/approved our engineering specifications. All deemed to produce consistent results.
Whose requirements are we trying to fulfill? - The answer is 'THE CUSTOMER'S'.
Quality is not about meeting the requirements of the 'policy', or the 'procedure'. If you have a policy that consistently fails to meet the customer's requirements, then you consistency produce a low quality product.
Consistency is not the same as Quality.
But often it is the only thing we can control within business operations
Just like within programming, we can deliver a software product as free from 'bugs' as possible as 'easy to use as possible', we can follow best practices and standards but at the end of the day, a software product that plays checkers will not meet a customer's need to track customer shipments no matter how few bugs it has or how little memory it uses.
Within interpersonal communication, we can deliver a 100 page report on the history of native people and the influence of Europeans on native culture, but this deliverable has no value to a customer trying to improve his/her business process for managing office supplies.
Sounds simple enough right?
I ask again, whose requirements are you trying to solve?
Let's suppose your boss asks you for a specific deliverable, a data flow diagram indicating the input & outputs, the data attributes and the CRUD methods involved as the data flows through various applications.
You need to meet this the customer (who uses this data flow) to identify and determine the information required to create the requested deliverable)
You spend weeks working on the deliverable, going back and forth with the customer to ensure it is validated, that you have identified the information correctly. That the flows are correct, during this process you go back and forth with your boss to ensure your preliminary mock-ups are in align with your boss's expectations. You check and double check that the format matches what he/she had in mind. You suggest alternatives, you receive confirmation of your boss's preferences.
Finally the day comes when you complete the deliverable, only to find out a few days later that it did not meet her requirements.
You sit there scratching you head over and over, trying to figure out what 'you did wrong'? What could you have done better? - Who was your customer?
