Requirements: theirs and yours

Quality is often defined as "meeting customer requirements" or "meeting customer expectations." (Longtime readers may recall that I discussed that definition along with others in this early post last year.) But in a post a couple weeks ago, when discussing how to handle ethical questions in your organization, I described the Bosch Product Development Code, an element of the Bosch Code of Business Conduct which states clearly that "Legality and the Bosch values take precedence over customers’ wishes." How can this be Quality? If Quality means "meeting customer requirements," what grounds does any company have for saying that other considerations are more important?

Image by Edar from Pixabay

At one level, this is easy. Any responsible company will review orders before accepting them, to make sure they can actually fulfil what is asked. (ISO 9001:2015 requires such a review in section 8.2.3.) If this review reveals customer requirements that the company is unable or unwilling to fulfil, the latter is generally within its rights to reject the order. The order might be impossible, or it might be illegal, or it might just be a bad fit for the kind of work the company does best: in any of those cases, the right response is, "I'm sorry but that's not for us."

This highlights why it is inadequate to define Quality merely as "meeting customer requirements." Your organization likely has rules or considerations of its own that also have to be taken into account. These organizational considerations are the boundary conditions inside of which you operate. But critically, they count as requirements, and they have to be considered along with the other requirements that come externally, from the customer. Then you evaluate whether the whole package is something you can achieve or not.

Another way to describe your organizational requirements is that they are part of the Context of your Organization (COTO), and they should surface during your COTO analysis. But this means that your COTO analysis is in essence a requirements review for the organization. That is to say, ... well, we all know what a requirements review is for a product: you get the right people together in a room, and you generate a list of everything the product has to fulfil. You work through the list to ensure that it is consistent, that it complies with all applicable regulations or boundary conditions, and that it is achievable.

But that's exactly what you do in your COTO analysis: you identify all the interested parties who want something from you, list what they want, itemize any other issues you have to address, and then figure out what you are really going to do. In the end, your final list of constraints that form the framework of your management system has to be consistent (or else different departments will pull in different directions, guaranteeing failure); it has to comply with applicable regulations (if only to ensure nobody goes to jail); and it has to be achievable (or else, again, you guarantee failure). In other words, your COTO is the requirements list for your organization.

And that means that, conceptually, the rejection of this or that customer requirement on the grounds of ethics—or legality, or profitability, or anything else—is no big deal. It's just a case where one requirement conflicts with another. This happens all the time, and the answer is always to analyze the conflict until you figure out which requirement takes priority. That's what you are doing here.