up front p.s. Ah it's one of these again, so the by now possibly infamous Jean_B TLDR:
Quality policy is "you can be called on this from within the organization" cards and the focal lens of external requirements into internally specified implementations of them. They are also a last resort, when all else is absent.
Objectives are "what is seen gets done", applied based on knowing what people will do without objectives and adding only the non-superfluous ones, while employing the framework in generating objectives that counter the human tendency to not follow something they cannot understand or is intangible.
All long post readers be warned. No i'm not making a discussion, but the following isn't something that comes out in a conversation.
------
I agree with the people here and Jack Sparrow when he says "
Wherever we want to go, we go. That's what a ship
is, you know. It's not just a keel and hull and a deck and sails. That's what a ship
needs. But what a ship is... what the Black pearl really is...
is freedom." Except Quality Sparrow would probably say that about a Quality Management System and Quality Policy, not a ship.
Fact is, most standards state just requirements. Short, to the point, mostly unambiguous. But for all that, they hardly ever add any intent to clarify what it is trying to achieve. Often this is because a single requirement doesn't achieve its effect like a single wheel isn't able to really steer or carry the weight of a car by itself. Their true functions (plural) are often achieved through synergy. That would become a hefty document, possible but not really practical for most companies to teach or use. Then we look at guidance, but those often are a pool of more defined common sense good ideas more than an explanation of underlying intent or reason for requirement. Those guidances are downstream of requirements, explaining how you can meet them, but rarely whatfor or why. And what and how just don't inspire. Then keep in mind that when you track back requirements, they changed over time with compromise, translation, 'refinement' except for the uninitiated, fit more with less and you really need to want to dig if you're going to get the gains out of such things.
Now for the quality policy. I'll play ISO 900X and ISO 13485 for contrast.
In 9001:2015 it has the following things pushing on it from upstream:
The context of the organization (5.1.1); the Strategic direction of the organization (5.1.1) and purpose of the organization (5.2.1) [it should be compatible with them or be appropriate for them, so they set the rules]. {ISO 13485 as Medical device QMS wants you to review the policy for need of change or improvement possibilities in management review}
As a
ship quality policy, it has
hull, sail, rudder:
- a framework for setting quality objectives {medical devices wants you to review them as well}
- a commitment to satisfy applicable requirements
- a commitment to continual improvement (of the thing it is the policy of) {Medical device QMS has effectiveness, and reviewing suitability of policy, against the things before this list, which are unstated in ISO 13485}
Downstream:
- Quality objectives must be consistent with it (6.2.1)
- Persons doing work under the organization are aware of it (7.3) {Medical device QMS wants you to communicate it (send) and have it understood (receive)}
The contrast shows you that continual improvement and/or effectiveness can be contained in it, but it doesn't define it. Anecdotally medical device QMS abstains from continual improvement as a goal as things that aren't thought out fully but tried out to find out if they are improvements are feared for inducing risk leading to patient harm. Yet, the system must improve to meet expectations from a changing world around it, and reducing (patient) risk lower is a core requirement of regulations, so it is technically doing the same thing with a different focus.
That leaves the rest: commitments to meet as well as objectives to reach (and a way of rolling them out).
So if these are the things it has, then what is its effect on the world? What does it make 'go', what does it 'stop'.
I have found the commitments to satisfy applicable requirements can best be done as if specific. Mention a group of requirements (a regulation with multiple clauses, etc), and you bind yourself to it. It allows someone to call you on it from within the system. Hell, go a step further. Mentioning them in the policy means you commit yourself to having an implementation matrix that goes through each of the requirements in it, and states whether you must (partial applicability exists), and how you comply with it. Helps a bunch with auditing and ensuring things are present and remain in system as well, as removing the reference from that document should raise some higher management flags. "This is policy level stuff, sir. You need to make the call.". It also helps in explaining where those odd tidbits come from like that weird engineering manager function that Japan used to have, or that the statistical analysis procedure that seems to be a college-level textbook more than a useful document is intended to satisfy the FDA's requirement on it (oddly absent for a long time). Or why you're maintaining and old-fashioned list while you have this fancy search engine (Brazil). But again, a lot of work to keep hardwired into the system if it's in full detail. They give some intent to requirements, though not always the end-result in the world.
With commitments out of the way, what are objectives for? And why the emphasis on a framework for this, or rolling them out at relevant places or levels?
Framework: make them SMART. Solved? No.
Framework: each process must have a SMART objective. Solved? No.
Framework: each procedure level (not work instruction; haha not diving into that here) must have a SMART objective. Solved? No.
Framework: feed data back into a data analysis/visualization tool, put some control charts in there and steer it based on SCIENCE. Solved? No.
Framework: we'll benchmark against other companies, measure whether we meet or exceed them and call it a day based on that. Solved? No.
Let's look at the other end. What do people do with objectives? Game them. Hopefully in the way you want them to, but else at least they actually care about your authority. If there's objectives but no one cares, that's also a useful signal: "hello pile of open nc's my old friend, you're telling me they don't care about controlling their process, or your (lack of) authority".
What do people do in the absence of objectives? That which gets them to a) keep their job & b) get a better job & c) keeps Ted from accounting from being happy. Most of those motivations are tied to people that can influence their job (or Ted): their direct manager usually, perhaps someone one level higher, and the people that influence those peoples. Objectives are those things that keep this honest where it cannot be avoided, add the light where it was dark (which can differ per person/field), and clarify what something means when translated to a specific arena.
Example: On-Time-In-Full is a generic policy to keep customers satisfied. But the objectives are not only have all that is wanted and deliver it on time no matter the cost, it could be (after study) be split in objectives of improving stock while keeping time-on-shelf below some measure, increasing yield as that's quicker than reworking, also improve rework process as that's a non-trivial factor, improving the quote process so there's less time lost on communication/negotation of 95% 'the usual' and more time left for manufacture, manage customer expectation to try and widen what they ask for as a time. You could go further down. In the end i'll just say read up on how commander's intent works (or try the books Team of Teams / One Mission) and there's dozens of videos that explain it better than I can. That also links in nicely into top management's
intention.
In the end policies (in general) grab back onto something very human. The tendency to rationalize exceptional circumstances as being grounds for exceptional actions. Policies take that out of the equation. Any deviation from policy is a grave matter indeed. It was (should have been) thought out well, and you'll need to do more than quick thinking to reason why you're not following it. Of course it doesn't hold for the policies that weren't thought out.
"Never negotiate with terrorists" is a policy. Serves people/nations well in not making enemies because you're making the wrong kind of friends or creating perceived unfairness or painting yourself as a piggybank target if pressured enough. No need to twiddle 20 parameters to say why this time we are doing it, and last time we were not and the inevitable paradoxes and inconsistencies that arise due to human judgement. The high chief gets it, the lowly policeman gets it. That's good awareness. Same with the risk acceptability policy (though you'll see them game it, but the inconsistencies show, since they only adjust the out of bounds items, and don't usually retroactively fit the rest that wasn't a problem to follow the fix).
"Don't take or give personally focused compensation in a business context" is a good rule to avoid being implicated in bribery, unfair advantage lawsuits etc. It's also why that same policy doesn't work in economies which thrive on it. The example i think of is when the Dutch Consulat or some other official Dutch organization advised people to pay the bribe asked for by Indian policeman as the rest was too hard for them to deal with. Remember to suit the context.
The brevity of a policy helps in removing the room that will create nuance and grey areas. The awareness of a policy allows people to make a call or abstain from making the call when all else fails or is absent. When there's no procedure, when there's no manager on the evening shift, when you're alone in the dark; you're not lost, just execute the policy and you won't be personally at fault, and probably (if its a just policy in the context where the organization is operating) not even the company. You do need to clean up, but there's no punishment to it. Daniel Kahneman goes into it a tiny bit in his book Thinking Fast, Slow, but given the rest of his book you can understand the place of policies in management systems.
The best test of a policy is a hypothetical:
- Ask an employee "if you're in this extraordinary situation (which just isn't covered in procedures, or is on the edge when it's in scope; but is traceably related to a policy matter), what would you do?".
- Get answer. Have it go a bit back and forth to be clear and get them into a solid position on the matter.
- Ask "Does that fit with the quality policy as you understand it?"
- I'm not going into the typical answers like "what?" or a citation of the policy without understanding. Those are obvious.
- Verify whether a substantive answer meshes with the intent of the policy.
- Verify whether that intent is what was actually intended to be achieved by the management that authorized the policy.
- If management can't give an intent for the policy statement other than "the standard says it needs to be in there" tell them a monkey with an overall and a tool-wrench isn't a mechanic.
