Instructions for writing Policies that support a QMS



Hi all,

We have been updating our documentation (as some of you may know from other postings elsewhere).

We are currently developing policies that support our QMS and to which the QMS must refer. We sent a policy out to someone for review, and they really did not understand what was happening. I've been advised that no one has time for a webex, and so, I have written a document that explains to key people just what a policy is, what a SIPOC is, and how to review it.

Background: Division = Parent company; plant = child companies. Each plant has their own quality manual - but they are not currently complying with divisional policies that should be referenced in their QMS, thus the divisional QA policies discussed in the document.

I would like to ask for your comments on this document - is it OK and would you add/change anything?

If it IS OK, would this be a useful resource for the coves? Everyone has been so helpful, and I thought maybe this could be added as something to help others?




One really big problem may be in the use of the word "Policy" and its potential conflict with your QMS policy. I've run into this situation time and time again and all that happens is people get confused with multiple uses for the same word. Break out a Thesaurus and maybe use a different word.
This couldn't be further from my understanding and way of working!

To me, policies are: “the intentions and principles which provide a framework for how an organisation means to operate”. Policies must be relevant to the organisation's mission and plans. They will influence how processes are designed, managed and implemented - or even if they need to exist. Compliance with external standards requires that an organisation has a suitable policy for the achievement of quality / environmental management etc, which must be communicated to and understood by staff. It will also have policies (whether formal or informal) relating to its attitude to staff and their development, the selection of suppliers and a range of other matters. It is important that these are also clear and consistent, so that people can easily apply them to the processes in which they work. But there may still be situations when someone goes against a policy because they assess a particular situation and have the competence to decide that they are better to do something different.

You must have hundreds of "policies"(?) - what you seem to be describing is your processes.

For example, I could understand (but not necessarliy agree with) an inventory policy of "keeping stock levels low", or "always buying at the lowest price", or "transferring stock from other locations rather than buying". But your approach implies that you would have "policies" such as "if the order value is more than £x you must get your manager to sign the requisition", and "every order must be entered into the computer stock system". To me, that is just part of "your process" - what needs to be done from the time someone realises that you are short of something through to the new stock being ready for use. Any allowable regional variations can be described in the process description.

Hopefully, you have one "policy" to maintain a system which meets the requirements of ISO9001, and not separate ones for each section of the standard(!)

And I see no benefit in trying to force every process into "SIPOC" (in fact, I am not sure I see much point to SIPOC in most situations). You can end up with "artificial" constructs which don't give any value to the people who draw them up or who refer to them (why would they refer to them?) The "Simple" phone call example is words for words sake - what value does it add to the person making the call?

I am not too surprised that your people struggled to know what to do with your document(!)

[Sorry for being blunt - I can't help it sometimes!]


Hi Peter,
No apology required.... I think that if someone does not understand the full intent of the documents, a lot can be missed. I could go into a lot of detail as to the why and how of doing this document...

You are correct - the process is being outlined - but the process, as defined in these documents is part of the divisions policy. Certain processes are handeled at the plant level and that document is good enough. However, processes that require Divisional authority, or that are run at the Divisional level, based on Plant inputs also become POLICY - in other words - this is the ONLY way the particular process can work and be acceptable for our QMS.

Those of us using the SIPOC are beginning to appreciate it more and more, as it helps us outline those parts of the process that we are stating must be "written in stone". If someone wants to do things differently, it is possible - but only with proper authorization.

We do not want a product nonconformance, for example, to be handled differently by every plant. They must all use the same process and make sure the same policy associated with the process is observed (WHAT, WHO, WHEN) - the HOW is completely up to them, along with variations in the process.

Example: Product nonconformance does not require ALL plants to perform a particular step if a continue to process decision is made. However, one plant does require that step... THEIR procedure would handle all of the additions and variances from the policy - as long as our policy (which includes the MUST DO of the process) is observed, Division is happy.

To you this may seem confusing. The buy-in from our QA Managers at the plant level is huge... there has simply been confusion as to how to view Divisional policy (the purpose of the document I posted).

Thanks for your comments!


I still don't see why they all need to be "policies" - it makes them sound very grand! Is the process not something like:

Make it.
Check it - if NC then reject it, unless Plant C, in which case apply for dispensation.
Pack it.
Ship it...?

Maybe it is just my way of thinking(!)

Bob Bonville

The choice of the word "Policy" should be very selective in my view and I think thats what has some of the contributors responding they way they are.

Policy, the way I learned it, dealt with a general or specific requirement that comes from top management and amounts to a "thou shall". The policy should never (IMHO) state "how" something will be done, thats the job of lower tier documents.
What we're looking at might be what others call "Directives" or "Procedures"

I cringe when I think about asking how the "policy effects your performance" or "how do you help the company achive its policy". Might take all day to work around this one.


Correct - I completely agree.

We do not have the "HOW" in these policies with SIPOCs - we have statements like,

The Material Review Board will consist of at least the Quality Manager (or equivalent).
Nonconforming material will be quarantied per plant procedure
Customers will be contacted only via their assigned Dvisional representative, etc.

Likewise, the SIPOC is very top level - and gives a picture of the responsibilities, etc...

But no where in our policy do we state "HOW"



Hi Randy,

I can bring these concerns to the QA Manager - but I don't think I'll be able to change the word - this was a standard implemented long before I came here... I'm just getting the documents together.

Though the issues you all raise could be the reason why no one is reading and correcting the "policies" appropriately.

Well, we shall see what happens...


Top Bottom