8.3.2 Design and development planning

When tackling this clause, it is important to clearly identify how and where it is applicable within your organization to avoid confusion.  For example, last week we discussed how many organizations do not actually do any type of design or development of their product/service, but may defer to their customer’s design.  But, we also discussed that while we may not do product design, we do design our processes for our QMS and “product realization” or order fulfillment, and therefore, we do, in fact, have a design process of sorts.

The design process may be the same for both types of design, or they may be quite different.  Designing a process may be (or may have been) a one time thing when the organization was established.  There may be periodic reviews of the process to look for opportunities for improvement.  And the organization may choose to employ the same process should additional products/services be added to their offerings.  However, design of a process may differ significantly from design of a product/service, and these two ideas should therefore be addressed separately, depending on the complexity of both processes.

In any case, the requirements are these:

“In determining the stages and controls for design and development, the organization shall consider:

a)  the nature, duration and complexity of the design and development activities;”

Again, there is no longer an option to “exclude” this requirement, even if the organization does not design its products/services, there is an expectation that some type of design process be defined for design of processes.

“b)  requirements that specify particular process stages, including applicable design and development reviews;”

This may be very simple or complex depending on its applicability (what is being designed)

“c)  the required design and development verification and validation;”

This is obviously a very important requirement in design, because every design should be verified and validated.

“d)  the responsibilities and authorities involved in the design and development process;”

e)  the need to control interfaces between individuals and parties involved in the design and development process;

f)  the need for involvement of customer and user groups in the design and development process; ”

As in any process, responsibilities and interactions should always be clearly defined to ensure the integrity of the process.  And finally,

“g)  the necessary documented information to confirm that design and development requirements have been met.”

This is a reference to what type of records will be kept, and it is at the discretion of the organization to define this for themselves (in the absence of regulatory, statutory or customer requirements).

THIS WEEK’S HOMEWORK

First, take a look at your current QMS structure.  Did your organization previously “exclude” the design clauses?  If so, it’s time to get to work defining a design process that would be applicable to the design of processes within your organization.  It needn’t be complicated, wordy, over-documented or cumbersome.  But it should clearly lay out the steps that you and your organization would determine to be appropriate to your needs.  Be sure to address each of the bulleted items above and you’ll have what you need to ensure your compliance.

If your organization did historically have a formal design process, be sure these requirements are all included.  And also have a look to see whether that design process would apply to the design of processes as well.  Make modifications where necessary.

And finally, do a quick check of your “documented information” to ensure you’re following your system and everything is in order.  Good luck!

Stay involved and engaged – SUBSCRIBE!

8.3 Design and development of products and services

I’d like to start this week’s discussion with a big thank you to one of my readers who brought to my attention a mistake I made last week.  Somehow, as I wrapped up week 27 with 8.2.1, and began week 28 with 8.2.3, I skipped over 8.2.2.  These two sections are so similar, with 8.2.2 being the “determination” of requirements and 8.2.3 being the “review” of requirements, I mistakenly skipped over 8.2.2.  Suffice it to say, there is first the determination of requirements, which is fairly well covered in 8.2.1, followed by their review.  If any of you have any additional discussion or questions relative to 8.2.2, please feel free to bring them up this week.  Thanks R Botha for reading and thanks for the heads up!

Now onto 8.3.  8.3.1 General states:

“Where the detailed requirements of the organization’s products and services are not already established or not defined by the customer or by other interested parties, such that they are adequate for subsequent production or service provision, the organization shall establish, implement and maintain a design and development process.”

In the past, companies could exclude this clause if they had no responsibility for design or development of their products.  In other words, if their products or services were designed by their customers, and the organization simply produced them to their specifications, a design process was not required.

However, the clarifying notes now suggest there should be some type of design discipline as it pertains to the design of processes to produce their products and services.

“NOTE 1  The organization can also apply the requirements given in 8.3 to the development of processes for production and services provision

NOTE 2  For services, design and development planning can address the whole service delivery process.  The organization can therefore choose to consider the requirements of clauses 8.3 and 8.5 together. ”

8.3 uses the logic of including “inputs”, “controls” and “outputs” in the design of processes and then goes on to tackle the control of externally provided products and services.

8.5 takes a slightly different approach, but there is a lot of overlap between these two sections in regard to laying out a process.  It goes on to address additional logistics of order fulfillment such as product traceability, customer owned property, preservation and delivery of product while in possession by the organization, etc.

This is a nice clarification, in my opinion, in this revision.  This is because previously, an organization had the prerogative to exclude the design section (and of course, many organizations did).  But there was some good stuff in that section that, if excluded, was not included in the quality management system.

Now, the ability to wrap these two sections together in the approach to a solid design process – be it for product/service or simply for the process of producing the product or service, is a plus and adds something substantial to the quality system.

THIS WEEK’S HOMEWORK

Evaluate the structure of your current QMS.  If you previously excluded “design”, you’ll need to incorporate it somewhere.  In the beginning, your organization identified the necessary processes and perhaps even described them as process flow diagrams with inputs and outputs and their interaction was clearly defined.  It’s a little awkward that now they tell us more about the requirements of design of the processes, but there has been discussion right along and there will continue to be more discussion about this topic.  Because, after all, the focus of the standard is to be process focused.  The creators of this new revision have done a much better job designing the right requirements to make that happen.

You may combine the two requirements into your own unique process, or address them separately, it’s your preference.  It’s your organization’s QMS and it should work for you!

Stay involved and engaged – SUBSCRIBE!

8.2.3 Review of requirements related to products and services

Last week, we established our methods of communication with customers and soliciting input regarding their needs.  Now it’s time to talk about understanding and reviewing those needs in order to fulfill them.

Let’s have a look at each requirement individually.

“The organization shall review, as applicable:

a)  requirements specified by the customer, including the requirements for delivery and post-delivery activities;”

This is a general statement by the customer of what they’re looking for.  It may be in the form of a request for quote, inquiry, or even skipping right to the chase and right to a purchase order.  In any case, it’s the first step in understanding the customer’s requirements.  Some companies accept verbal inquiries and orders.  In this case, the organization should be sure to have a very robust process to ensure all necessary information is gathered proactively.  Regarding “delivery and post-delivery activities”, this requirement is designed to ensure all requirements are clearly understood by both parties prior to entering into a contract.

“b)  requirements not stated by the customer, but necessary for the customers’ specified or intended use, when known;”

This is a real trick bag!  So, the customer may or may not state a requirement, and the onus is on the organization to solicit needs on behalf of the customer, whether or not the customer knows their own requirements.  It’s important that when we are in the role of customer, we be a “good customer’ and know what we need and communicate it clearly to a supplier so that a contract can be successfully executed.  However, not all customers rise to this challenge, and a supplier bears a responsibility for doing their best to understand the customer’s intentions and then make their best recommendation for the customer’s approval.

“c)  additional statutory and regulatory requirements applicable to the products and services;”

Again, there is a great deal of responsibility on the part of the supplier to understand their industry and the requirements applicable to the products they’re selling, and also, all potential applications of their products and the impacts of associated statutory and regulatory requirements.

“d)  contract or order requirements differing from those previously expressed.”

This requirement is intended to make both parties responsible for stating and reviewing contract requirements which may become important later.  Buyers and sellers should clearly state, negotiate and agree upon all requirements and expectations.

“NOTE:  Requirements can also include those arising from relevant interested parties.”

This note points back to statutory and regulatory requirements, but also to requirements within the supply chain, both up and downstream.  In some cases, both consumers and suppliers in the network may have requirements that are fulfilled either up or downstream.  These must be communicated and captured.

“This review shall be conducted prior to the organization’s commitment to supply products and services to the customer and shall ensure contract or order requirements differing from those previously defined are resolved.

Where the customer does not provide a documented statement of their requirements, the customer requirements shall be confirmed by the organization before acceptance.

Documented information describing the results of the review, including any new or changed requirements for the products and services, shall be retained.”

This is really puts a stake in the ground that makes verbal and handshake orders difficult to be considered compliant to the standard.  It’s a good requirement that any and all exceptions should be expressly noted and settled, rather than arbitrary substitutions.  And the requirement of “documented information” pretty much requires that all orders be documented.  That is not to say that verbal orders may not be accepted, but they must be documented by someone.

“Where requirements for products and services are changed, the organization shall ensure that relevant documented information is amended and that relevant personnel are made aware of the changed requirements.”

This is perhaps the most important requirement of them all.  Typically, taking an order and fulfilling it is the easy part.  It’s changes that trip us up.  If a customer makes modifications to their requirements, for even something as simple as quantity or delivery date, the changes must be carefully controlled, communicated and executed.

All in all, this section is very clear and easy to understand.  In fact, it is clearer and more detailed than some of the other sections.  As I noted last week, there is some repetition and weird structure here, but the content is easily understood and therefore, easy to meet.

THIS WEEK’S HOMEWORK

What is your customer order review process?  Does your organization proactively solicit all necessary information to fulfill your customers’ requirements (stated and unstated)?  Does your organization maintain “documented information” about these reviews?  Be sure your organization has these bases covered and you will have confidence in your compliance.

Stay involved and engaged – SUBSCRIBE!

8.2 Determination of requirements for products and services

8.2.1 Customer communication

This week’s discussion is about customer communication, and the requirement is that first, there must be a defined process for how the organization will communicate with a customer.  Once again, I must point out the awkwardness of the structure of ISO9001:2015.  This section jumps around separating first having a process, then determining and then reviewing the requirements, using a lot more words than necessary in my opinion.  But let’s have a look at the first requirement, 8.2.1 Customer communication.

“8.2.1 Customer communication

The organization shall establish the processes for communicating with customers in relation to:

a)  information relating to products and services;

b)  enquiries, contracts or order handling, including changes;

c)  obtaining customer views and perceptions, including customer complaints;

d)  the handling or treatment of customer property, if applicable;

e)  specific requirements for contingency actions, when relevant.”

So, the requirement is clear, there must be established processes for these types of customer interactions.  Customers play a large role in the determination of these processes, particularly with regard to information and inquiries.  And it is important to have internal processes to supplement the customers’ preferred processes when they may be, shall we say, quite entrepreneurial and/or requiring a smidge more discipline.  Verbal requests, emails and so forth can work well in many situations, but can also lead to confusion and miscommunication.  This is especially true regarding changes.

Requirements a) and b) above address the subject of inquiries becoming orders in an important process that should be carefully defined.  That’s not to say an organization must put so many procedures and policies in place as to discourage a customer or negatively impact their experience, but rather to ensure the organization has a process to clearly define what the customer wants and their ability to fulfill those requirements.

Requirement c) is oddly placed in my opinion, because customer satisfaction and nonconformity are addressed elsewhere and in greater detail.  But, as there should be processes for determining what the customer “likes”, there should also be a way to determine also what they “don’t like”.

Requirement d) is a contract requirement that should not be overlooked.  Should the organization hold inventory or equipment as part of the product or service they provide, the expectations for the care for those items should be clearly defined.

And finally, requirement e) is a simple requirement for an agreement to ensure fulfillment of customer needs in case of emergency.  There is an expectation that there be a “contingency plan” of some sort in place, should foreseeable obstacles be encountered.  Simple, right?  One could also argue that requirement e) is bait for the anticipated “risk” debate that is sure to ensue upon release of the standard.  However, the requirement for defining contingency plans has been around a long time.  Most organizations have at least a cursory plan (written or unwritten), should an emergency occur.

THIS WEEK’S HOMEWORK

Assess your organization’s processes.  Are there processes for communicating with your customers and do they ensure all necessary information is captured?  (Stay tuned, because as we continue this next week, 8.2.2 adds an additional requirement that the organization “shall review requirements not state by the customer, but necessary for the customer specified or intended use, when known”.  That’s a tough one, but we’ll tackle it next week.  Meantime, do your current communication processes foster a clear understanding of your customers’ needs and your ability to fulfill them?

Stay involved and engaged – SUBSCRIBE!

8.1 Operational planning and control

This week, we change gears from higher level planning of the quality management system overall, to the nitty gritty of operational planning and control.  In Week 7 of this challenge, we identified the processes necessary to maintain full control of the quality (or business) management system.  There is some overlap between that section and this new one, so be sure to cross reference back to the processes initially defined as critical to ensure there is a good symmetry and alignment when pushing forward with this clause.

Back in 4.4, we identified our processes and things like “inputs, sequence, performance indicators, resources, responsibilities, risks and opportunities, methods for monitoring/measuring and opportunities for improvement”.  We’re doing much of the same work here, but at a new level of detail as it applies specifically to processes for products and services.  For example, there may be a broad brush approach in the QMS overall to address things like order fulfillment or the manufacturing process.  And now, there may be more detailed processes specific to different product lines or business units.  Just as a business plan may outline main objectives of throughput, acceptable quality levels (AQL), etc, they are later rolled out in greater detail to each department/work cell/operational location with subgoals intended to achieve the overall objectives and desired outputs of the business.

Let’s take a look at the wording in the new revision.  And notice both the points back to 4.4 (QMS and its processes) and 6.1 (Actions to address risks and opportunities).  In my opinion, this is a critical point, and missing these connections when creating a QMS can basically result in something like a “circular reference” error when writing an equation in a spreadsheet.  If the aren’t carefully considered and connected, there’s likely to be a gap in compliance with all of the requirements.  I really don’t like the way this whole thing is structured, because there has always been a struggle with a “process approach”, and this is part of the reason.  I would have preferred all 3 of these sections be integrated in a clear and understandable way rather than referencing one another pages apart.  There, I said it.

“The organization shall plan, implement and control the processes, as outlined in 4.4, needed to meet requirements for the provision of products and services and to implement the actions deteremined in 6.1, by:

a)  determining requirements for the product and services;

b)  establishing criteria for the processes and for the acceptance of products and services;

c)  determining the resources needed to achieve conformity to product and service requirements;

d)  implementing control of the processes in accordance with the criteria;

e)  retaining documented information to the extent necessary to have confidence that the processes have been carried out as planned and to demonstrate conformity of products and services to requirements.

The output of this planning shall be suitable for the organization’s operations.

The organization shall control planned changes and review the consequences of unintended changes, taking action to mitigate any adverse effects, as necessary.

The organization shall ensure that outsourced processes are controlled in accordance with 8.4.”

In addition to circling back to 4.4 and 6.1, the section finishes with a reference to 8.4 (Control of externally provided products and services).  So once we’ve looked at the QMS processes, we must break things down to a detailed plan for controlling product and service fulfillment.  And finally, we must consider the same for externally provided products and services.  So, there you have it.

THIS WEEK’S HOMEWORK

Hopefully, you have created (or reviewed) your QMS thus far with a series of interactive and sequenced processes, and you’ve been able to review each of the processes with the criteria provided.  Look at your system so far.  Are the processes clearly defined?  Are each of the criteria clearly defined and communicated?  If this is done well, other requirements like training, competence, process monitoring, corrective action will clearly roll out with each process and the system will be tidy and simple and easy for all users within your organization.  Unfortunately, these links can often be severed or missing altogether and this is usually where a QMS can become really challenging to manage.

Do your best to streamline and make the proper connections so that your system is lean, easily understood and easy to use.

Stay involved and engaged – SUBSCRIBE!

7.5.3 Control of documented information

Well, well, well.  We’ve finally arrived at the control part of document control.  Last week, we talked about what documents are.  They’re not just paper anymore.  We talked about having a system for creating them with a standard minimum of information which must be included – date, author, revision number, perhaps?  And then how they will be reviewed and approved (this should also include by whom and how often).

Once they are created and approved, then what do we do with them?  We must control them.  Let’s take the ISO9001:2015 requirements one at a time.  First, 7.5.3.1:

“7.5.3.1  Documented information required by the quality management system and this International Standard shall be controlled to ensure:

a)  it is available and suitable for use, where and when it is needed;

b)  it is adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity);”

The first sentence tells us what – any documented information that the organization needs for its quality management system PLUS all the specific items named in the standard.  Next is availability – however we control the documents, they must also be available for use.  This is the first part of documentation that’s tricky.  How do we keep the documents pure, but still let people use them?  And finally, we must protect them from harm or misuse.  Could one make a comparison between our documented information and a zoo?  I say YES.  Our documents, like wild animals, should be kept in a closure, but visible and available to enjoy.  But they must also be protected so that we may continue to interact with them and learn from them on an ongoing basis.

For our documented information, we must first build the enclosure or place of residency, and then make it safe, with limited (but varying) access to ensure our documented information is protected and safe.

And now let’s talk about 7.5.3.2:

“7.5.3.2  For the control of documented information, the organization shall address the following activities, as applicable:

a)  distribution, access, retrieval and use;

b)  storage and preservation, including preservation of legibility;

c)  control of changes (e.g. version control);

d)  retention and disposition.”

So, we must next define how our documented information is distributed and accessed.  Also, how is it stored and preserved?  And, how do we control changes (and indicate where changes have been made and provide a sure way to know we have the correct version)?  And finally, what happens to documented information when it is no longer needed or relevant?  Boy, this stuff is detailed.  But it’s detailed, not just to trip us up with regard to compliance, but also because it matters.  Processes can be significantly affected when information is out of date or when changes are made but not communicated.

So, a whole process must be created to address all these issues.  Documentation is the most talked about part of this standard, and for decades, organizations have struggled with it.  It can certainly start by documenting too many things, but really, it is a control issue. Most organizations do a pretty good job of controlling, say, their employee handbook.  Why?  Because it’s considered to be important.  Important that it clearly communicate expectations.  Important in that it must contain all information pertinent to an employee and his relationship with the company.  Important in that, should it be misunderstood, it could get someone into trouble.  Important in that, should changes in policy be made, but not communicated, it may be difficult to find accountability for noncompliance.  So, how do organizations typically treat this important document?  With care, that’s how!  POOF – the organization figures out how to define who approves it, how it is distributed, how changes are made, how changes are communicated (and to whom), and the organization even figures out how to keep records of this critical communication.  There typically is a master copy kept tightly under the control of the human resource director.  A copy is carefully reviewed (and signed for by the recipient).  A list of who has copies is kept up to date.  And new lists are made whenever new versions are distributed.  Ah, if only we treated our quality system documentation as carefully!

This section of standard, finishes with two important points.

“Documented information of external origin determined by the organization to be necessary for the planning and operation of the quality management system shall be identified as appropriate, and controlled.”  This scoops up anything not created within the organization, but still used and necessary.  We don’t get off the hook just because it’s someone else’s document.  But it also can give heartburn when we have no influence on whether the document we use, but don’t own, is kept up to date.  But we should at least do our due diligence to have a method for keeping tabs on the document to ensure that the people who have access to it through our system have the best information available to them (or are notified when to stop using it).

And finally, there’s this little number, which in my opinion, is an interpretation and clarification of many-a-nonconformance-past.

“NOTE  Access can imply a decision regarding the permission to view the documented information only, or the permission and authority to view and change the documented information.”  (Which definition of “access” do you use?)

THIS WEEK’S HOMEWORK

Have a gander at your document control process.  Are all forms of documentation included?  Are all the necessary controls in place?  Is external information included?  This may end up to be quite a project for some.  Good luck this week!

Stay involved and engaged – SUBSCRIBE!

7.5.2 Creating and updating (documented information)

ISO9001:2015 changes terminology from “documents” to “documented information” in an attempt to clarify to the last remaining users who have yet to pry their paper documents out of their hands, the wide assortment of other media available for use in support of a quality management system.  Most all organizations use other forms of media in their daily operations, communications, training, etc, but do not consider them “documented information” and therefore do not manage them the same as their other documentation.  This clause casts an umbrella over those other forms of documentation and requires they be managed in some way.

This does complicate matters for some.  I imagine a graphic much like the “evolution of man” chart when I think of the history of documentation and ISO9001.  We started with paper documents which often included a revision history printed on the document itself.  Then, we awkwardly evolved into electronic media by using spreadsheets and databases and later, document sharing tools like a “shared drive” on a network, which does provide a multimedia friendly environment.  (But, how’d that work out for ya?)  The use of document management tools like “SharePoint” add a measure of control, and now our horizons are starting open up about the many different ways to document and share our information.  ISO9001:2015 is trying to tell us that this is great, but we mustn’t lose control as our creativity takes the reins.

The standard includes the following simple requirement:

“When creating and updating documented information the organization shall ensure appropriate:

a)  identification and description (e.g. a title, date, author, or reference number);

b)  format (e.g. language, software version, graphics) and media (e.g. paper, electronic);

c)  review and approval for suitability and adequacy.”

This is not an earth shattering development, but I think it might have saved quite a few novice document control people a lot of headaches, had they created their systems with this solid foundation in the first place.  Remember when I made mention of the “shared drive” earlier?  Anyone remember the days of the paper manual + procedures?  No worries, who EVER tried to proactively get a new procedure or document added (that wasn’t directly responsible for the quality management system)?  But with the introduction of the shared drive, all sorts of stuff got dumped in there – forms, handbills, “homemade” procedures (duplicating the controlled ones) – none of which included the standard quality document characteristics like dates, revision numbers, etc.  And it was always a mystery who had created them and who put them there.

So this clause restates the obvious about having a standard process for creating and updating documents.  (The discussion of control comes next week, so we’ll talk more about that then).  For now, it’s simply about deciding how documented information will be created and included.  Then identifying a format (perhaps even defining some structure like templates, masters, etc).  And finally, defining a process for review and approval.

Now back to the less obvious point here – what else may be considered a document, and therefore be subject to these requirements?  Do you use videos, audio, web-based training or instructions?  If they support the quality management system (ie – if they are necessary for any of the key processes you’ve identified), they should be included and managed with these requirements in mind.

THIS WEEK’S HOMEWORK

Review your quality system.  Does it address the creation of documents?  Does it tick all the boxes above?  Does it apply to all the types of media in use in your organization (or have some things been missed or not yet captured)?  Look for other types of documents you may not have previously considered “documents” per se.  Are there guidelines on how they are created?  What they should (or shouldn’t) contain?  Has that been communicated within your organization?  Make any adjustments you feel necessary to improving this part of your quality management system.  We’ll talk control – distribution, storage, control of changes – next week.  Stay tuned!

Stay involved and engaged – SUBSCRIBE!

7.4 Communication

In the immortal words of both Strother Martin and Paul Newman in the movie “Cool Hand Luke”, “What we have here is a failure to communicate!”.

Communication is perhaps the absolute bedrock of every organization.  Poor communication leads to chaos, poor performance, poor morale and other bad things.  Good communication can foster a sense of community, teamwork and a clear sense of purpose and direction.  A whole bunch of just plain old communication, measured only by quantity, is something else altogether.

There are myriad ways to communicate – directly by speaking, through written correspondence, through graphics/photos/videos and also in more subtle ways like “by example”.  We’ve all been told, “do as I say, not as I do”.  Hmmm, I guess that’s the gist of communication in a nutshell.

We all understand the importance of good communication.  Most of us continue to work on it.  Few of us every really master the art.  But, because it is universally recognized as important, ISO9001 has taken it on as a requirement.  What is an organization expected to do?  The standard reads like this:

“The organization shall determine the internal and external communications relevant to the quality management system including:

a)  on what it will communicate;

b)  when to communicate;

c)  with whom to communicate;

d)  how to communicate.”

Now, I being the curmudgeon that I am take issue with the validity of this requirement as actually being auditable, but be that as it may, let’s just have a look at the intent of the requirements.

We must decide what, when, with whom and how we will communicate both internally and externally.  This is expected to be a deliberate decision we make and stick to long term.  How many companies have actually distilled their approach to communication to this fine a point?  I know it makes my head hurt to try to think about.  Isn’t that, after all, the problem?  That we typically do not have such an approach?  That much communication is an afterthought or is done as a correction because rumors and misinformation have circulated in absence of well thought communication to keep our organization informed?

The standard does help by keeping the scope at “relevant to the quality management system”.  So, what does this mean?  I guess it means that if we are to be compliant as an organization, we must all understand our part of the quality management and others’ parts as well.  And we must recognize what the quality system is, when to communicate about it, with whom, and we must have a plan for how we will communicate.  That’s going to be a tough one for the One Man quality systems out there on the shoulders of the lone management representative.  This communication requirement, however cheesy, is as simple as it comes.  And something I think we can all continue to work on.

THIS WEEK’S HOMEWORK

What is the current state of your organization’s communication?  Think about its strengths and weaknesses.  How do those strengths and weaknesses apply to the quality system?  Are a) through d) above addressed or thought of?  What changes, if any, should be made to your quality system to improve communication?

Stay involved and engaged – SUBSCRIBE!

7.3 Awareness

Persons doing work under the organization’s control shall be aware of:

a)  the quality policy;

b)  relevant objectives;

c)  their contribution to the effectiveness of the quality management system, including the benefits of improved quality performance;

d)  the implications of not conforming with the quality management system requirements.

This is one of my favorite structural and fundamental changes with this draft of ISO9001:2015.  It is helpful and elegant in its simplicity to provide a simple explanation and some guidance to organizations (and there are many) who struggle so much with the simple requirement of the quality management system being built upon a central quality policy and people understanding it!

How many ways have organizations tried to meet the requirement of “shall understand the quality policy”?  Hand bills, posters, employee badges with the policy on the back, memorization, chants, bumper stickers, geesh!  And the most success any of these companies can muster is that most of their employees can repeat the policy by rote or at least a catch phrase that closely resembles the policy.  When hit with the follow up question of “and what does that mean to you?” or “and what is your role in the quality policy?”, the employee flushes white and staggers away wearing a cloak of shame for having failed such a simple test.  This is typically because quality policies are overthought and over-engineered and under-understood.

This is ironic because the quality policy is said to be created, adopted and fully supported by top management, and often times, even top management doesn’t understand what they wrote or what it means.  So, how is an “Average Joe (or Jill)” who comes to work just wanting to put in a fair day’s work for a fair day’s pay supposed to understand what it means?  Top management should take guidance from the Einstein quote above and keep this as simple as possible.  Because it is so imperative that the quality policy be understood in order for it to serve its purpose as the bedrock for the quality management system.

I think this particular clause is extremely simply written and straight to the point.  Each of these points was in ISO9001:2008, but not grouped together in this way.  This structure makes the whole requirement much easier to understand and implement.  Tying together that all persons must understand the policy (not just be able to recite it) coupled with the associated objectives as well as an understanding of exactly how their own work may impact the organization’s product/service.  If presented during orientation as a new addition to the organization, or during introduction into a new area or job, this can be so effective in the employee’s understanding of what they are to do, how performance will be evaluated, how to interpret feedback and what they are responsible for in terms of compliance.  And it is management’s responsibility to create a policy that is easily understood, objectives that support the policy and processes that are designed to achieve the objectives presented.  Easy beezy!

THIS WEEK’S HOMEWORK

First, take a good look at your quality policy.  Does it make sense?  Is it easily understood or is it a really wordy, run-on sentence which ticks all the boxes for compliance but has no meaning to its users?  If so, then suggest a retooling of your quality policy.  Yes, I know, we’ll have to reprint the posters, but take the opportunity to do it anyway.  Next, take a good sampling of your team, and try a different approach than the typical pre-audit walkthrough or real time audit approach.  Table the quiz-approach and just chat with several of your team mates about how your quality policy feels to them.  Is it sensible or silly?  Does it really tell a story or is it just a bunch of words?  What is their impression of what a quality policy should be (and whatever they say, write it down word for word and consider incorporating their language into your revision).

Stay involved and engaged – SUBSCRIBE!