Wednesday, September 25, 2030

Welcome to the "ISO Myth Busters" Blog!


With over 30 years of Quality Management experience, I enjoy sharing my knowledge with those who are seeking answers or a better way to implement ISO 9001 requirements. For too long, there have been myths and legends about how to implement a variety of requirements from the International Standard. These myths and legends often come from the need to pass an ISO Certification audit, and, go along with the "Say what you do, Do what you say" mantra coined during the early 1990s.

In this blog, we'll cover such diverse issues as the myths surrounding document control, equipment calibration, management review and internal auditing. We'll also take a look at the role of the Certification Body/Registrar and what to consider if you're looking for one to work with.

I hope you'll find the posts to be helpful, that people will contribute to the posts and create enjoyable discussions and that we'll all learn. So, let's make a start on busting the first myth:-

ISO 9000 Means 'Say What You Do, Do What You Say'...NOT!

In my view, nothing could be further from the truth! The implementation of a Quality Management System, to meet ISO 9001:2008 requirements, takes a lot more than simply writing down what the organization does!

This phrase was, I believe, taken by early adopters of Third Party Certification. It is true to say that much of what ISO 9001 requires to be included in an organization's Quality Management System, may be based on what's institutional to an organization and should be documented in some form. It is, after all, what's made the organization successful and could be captured as the basis for improvement etc.

As an example, a printed circuit board supplier used by my employer during the 80s, had a phenomenal system for reviewing customers' supplied artworks and specifications. This supplier simply knew, from hard won experience, that what they were given by their customers simply couldn't be used for fault-free manufacture. Once received, their process engineers would review what the customer supplied for clearances, alignments, potential plating problems - in fact all the features that could cause quality problems. They listed these issues and communicated them back to the customer for approval to continue, or allow them to engineer an appropriate solution. In such a case, this process of review would have been satisfactory to document as it was practiced - to meet ISO 9001:2008 7.2.

You Can't Simply Write Anything, Y'know!

By contrast, there are quite a number of specific requirements in ISO 9001:2008 which are not institutional, so there maybe no clearly defined practice, methodology or process to document! Take internal quality management audits for one:

When did any member of an organization leap out of bed, in a "Eureka" moment, and decide that internal quality audits would be worth doing? It took the need to comply with ISO 9001 before the organization found some training (or similar) and started implementing them. Hardly a 'say what you do' scenario!

The same is true for corrective action, for preventive action (rarely is this requirement understood at all well) and the (key) requirement of performing management reviews. Such requirements are not normally practiced sufficiently well to be regarded as needing only a written procedure or process. Typically, processes are incompletely and/or ineffectively implemented, especially when compared to the full ISO 9001 requirements. Therefore, some form of planned action is necessary to ensure these deficiencies are addressed, and subsequently documented, as a means to capture what's now known to work.

Don't Document Things For the Mary Celeste!

In the early versions of ISO 9001 (the 1987 and 1994 revisions) the need for effective management systems was not specified clearly enough to help us. As a result, organizations often created masses of documentation which described, in painful detail, what was actually being done - and without much thought for practicality or effectiveness. Instructions are documented to a level of detail, such that "if everyone got sick, you could hire new people without an impact on quality". How bizarre! To my knowledge such an event only happened once, on the Mary Celeste and I doubt if writing things down would have helped anyone who found her!

With the advent of the year 2000 revisions, the addition of clear quality objectives and measurement of processes, ensures the organization must now be able to demonstrate an effective management system and therefore, actions must be taken to ensure that what is defined and documented actually delivers results.

As much as 20 - 25% of the ISO 9001:2008 requirements may not have been effectively implemented in an organization. Just as an architect designs a building, only when all the client requirements are well understood, along with a detailed understanding of the actual building construction, materials, building codes and usage, does he begin the design process.

It's the same concept with the design of a Quality Management System.  No-one should start to document a process, if you have only a sketchy idea of what's really behind the requirement! We'll cover this topic at a later date.

I hope this initial blog entry has shown "where I'm coming from" on the subject of ISO 9001 implementation and Quality Management Systems. Keep an eye open for more posts with a different twist on ISO Myths

Tuesday, April 30, 2019

All Internal Audits Are Process-based? Er, No...


Since ISO 9001:2000, it’s become increasingly common to consider that an organization’s Internal Quality Audits be performed using the so-called “Process Approach”. At the time of publication, that particular version of the International Standard for Management Systems contained no description of what the process approach was. The recently introduced 2015 version makes the “Process Approach” a lot clearer by describing what is envisaged, in section 0.3 of the Introduction to the Standard – and how it applies to the quality management system development, implementation and improvement. Reading further, the text goes on to describe the Process Approach involving the “systematic definition and management of processes, and their interactions, so as to achieve the intended results.” There’s no mention of anything to do with conducting internal audits in any particular fashion.

Perhaps the Internal Audit requirements, found in clause 9.2, will reveal something…

This particular clause states that “the organization shall:

a)       Plan, establish, implement and maintain an audit programme(s) including the frequency, methods, responsibilities, planning requirements and reporting, which shall take into consideration the importance of the process concerned, changes affecting the organization, and the results of previous audits;

Interestingly, even this statement, which deals with the actual planning and implementation of the internal audits, doesn’t require that those audits shall (or even should) be conducted using the “process approach”.  In basic terms, it simply states that the audit programme has to consider the importance of the (quality management system) process concerned. Nothing requires an actual audit of a process! So, why has the mantra of “Process-based Internal Audits” become so pervasive?

Maybe “mission creep” has occurred from the influence of the Certification Body auditors who were required to change their approach to one of auditing process(es), around the time ISO/TS 16949 was published. This era ushered in the use (by CB auditors) of the “turtle” diagram for audit planning, which has become wide spread throughout their client base, too.

Although not advocating against the internal audits of (only) processes, a risk-based approach to the considerations of what to audit and when can be very useful. Empirically, we know that risks occur in business and they don’t always occur within a process. Traditionally, risks are associated with something new and/or changed or activities affecting an organization:

·         Product designs & specifications

·         Sources of supply

·         Personnel

·         Technology

By reference to the diagram below, adapted from James Reason’s “Managing the Risks of Organizational Accidents”, (ISBN-10: 1840141050), it can be seen that risks occur throughout an Operation.

Clearly, the selection of a specific process may help when considering what part(s) of the management system to audit, however, further planning may reveal that it’s not always the whole process which should fall under the audit spotlight… It may be a relatively simple activity contained within the process; Perhaps a review of a requirement (customer order) and a subsequent change to that requirement may mean that a second review isn’t as robust. In such a case, auditing the entire process may be unnecessary in determining where the change “slipped through the cracks”. Experience also shows that it can be the interaction between processes where issues manifest themselves – at the interface of 2 (or more) processes.

It follows then, that without a clear, specific requirement to audit (only) processes, an organization is free to choose a specific audit “scope” and “criteria” if those define something within the quality management system which represents risk to effectiveness in achieving intended results. In addition to considering a process as the scope of an audit, the following may also be used:

A customer or regulatory requirement - which might be implemented in select parts over one or more process;

A physical area or location - a warehouse, for example

A specific requirement of ISO 9001 - if it is new or changed

A project: improvement, product design, new technology etc

A specific activity as part of a bigger process.

It's quite reasonable - if there's a clear justification - for choosing any focus for your internal audit programme. After all, ISO 9001 does say process MUST be audited and external auditors can't dictate requirements. Try it! You might just like it and find it useful!

Saturday, March 30, 2019

WTH? A Useful Quality Manual?


One of the first things which comes to peoples’ minds when describing Quality Management Systems and “ISO 9000” is documentation, which often includes a Quality Manual. The background to Quality Management Systems started with (big) procurement organizations such as government agencies and Fortune 500 companies making Quality Systems a contractual requirement. Frequently, these requirements included the need for a document, which was often called a “Quality Manual”, a “Quality Plan” or similar. These were used, by a supplier, to describe the approach to be used to fulfil the contract requirements and assure the quality of the deliverables.

Today, a hall mark of ISO 9001 Quality Management Systems documentation is a Quality Manual – one has been a requirement of the International Standard since 1987. Manuals produced by many organizations emulate the format and content of the ISO 9001:2008 clauses (4 through 8) to the extent that the words “The organization shall” have simply been replaced by the name of the company! This often leads to documents which run into 25 or more pages, written in arcane terminology which has little relevance to the business of the organization. The result? People rarely read the document, it’s often only rubber stamped by auditors and it gathers dust on an office shelf somewhere…

Amazingly, the 2015 edition of ISO 9001 dropped the requirement for a quality manual – indeed any type of traditional quality documentation, such as procedures, work instructions etc -  leaving it up to the organization itself to determine what it needs, based on understanding customer, regulatory expectations and its own requirements for documentation.

Based on their experience with Quality Manuals, it might be tempting to an organization to discard theirs, after all, it only sees the light of day when the Registrar auditor is on site – and no-one else reads it!

But wait! Before that particular baby is discarded with the bath water, why is it that no-one reads the Quality Manual? Maybe it’s because it’s not helpful, uses arcane language and is formatted on an ISO document no-one has reason to read!

There’s a better model on which we can base our Quality Manual which might bring some help to users: The “Quick-Start Guide” you get with some items of house hold electrical equipment etc is a clue. These guides cover the basics of what the (new) user needs to know to get “up and running”. For more detailed descriptions, including navigating the complete set of functions, features and also for fault finding etc, reference can be made to the more comprehensive manual which is also included.
Will your upgrade to the 2015 ISO 9001 requirements be heralded by a new, useful Quality Manual “Quick Guide to the Quality System”?

People Got Talent!


Competency is all around us. It pervades our lives. We see competency on t.v, - for example “America’s Got Talent” – talented people, regardless of their age, gender or social background.  performing all manner of stage acts that wow the show’s judges and viewers. “How did they do that?”, we often ask ourselves…

ISO 9001 includes a requirement for an organization’s people, involved in the Quality Management System, to be competent in their work responsibilities. The normative reference (vocabulary) document, ISO 9000, defines competence as “the demonstrated ability to apply skills and knowledge”. Those t.v show contestants could certainly demonstrate skills and knowledge, but how did they become so competent? They weren’t likely to be born with some “gift”, therefore, their performance is most likely to have been the result of combination of factors…

Practice, Practice, Practice…

 Zig Ziglar is credited with this: “Repetition is the mother of learning, the father of action, which makes it the architect of accomplishment.” Most of those performers will likely attribute their abilities to a combination of education (performance “theory”), training (master classes or similar) and practice, practice, practice… Competent performers can usually demonstrate a specific part of their act, and describe the reason and purpose for it, often including some portion of the related theory.

It is the same with many work related activities in manufacturing. A journeyman machining center setter, for example, would be able to demonstrate competencies in terms of:

·         Blueprint reading

·         Geometric Dimensioning and Tolerancing (GD&T)

·         Machine feeds and speeds

·         Material properties

·         CNC Programming

If we analyze these, we can see that some knowledge aspects are going to be education based – for example material properties which affect the way a part is machined, or CNC programming. Some knowledge aspects may be training derived, either from a classroom event and/or “on-the-job”. Furthermore, a significant proportion of competency is experiential – which comes from practice, practice, practice.

When an organization is determining competencies, it’s worth breaking down the required records into these three categories:

·         Education

·         Training

·         Experience

Then, creating some criteria against which a person can then be evaluated, for the job they do, should be relatively straightforward. Creating a record of these criteria and that they were demonstrated would meet the ISO 9001:2015 requirements stated in section 7.2.

Management must prepare themselves, however, to discover that some employees may not be at the same level of competency they were considered to have reached. From Burch’s Learning Model of the 1970s, we can see there are 4 distinct stages of competency:
·         Unconscious Incompetence

·         Conscious Incompetence

·         Conscious Competence

·         Unconscious Competence

It’s important to recognize, however, that these stages are not concrete and changes can affect the person such that they regress from unconscious competence right back to unconscious incompetence. Anyone who has encountered a MS Windows update will attest to experiencing that. 

Tuesday, November 10, 2015

What Will The ISO Auditor Ask?

It seems that, since Third Party Certification became an option to demonstrate compliance to a standard such as ISO 9001, ISO 14001 etc., it's been common for organizations to try and determine what a Certification Body (aka "Registrar) will ask during their audits. As a consultant, I've been asked many many times, "What will the auditor ask for?" or "How will they interpret this requirement?"

The simple - but unhelpful - answer is: "Who knows?"

The fact is, each auditor has their own unique approach to the auditing process, so it's very difficult to predict what any individual is going to ask about the management system.

It has been common, since Certification audits began, to prepare employees to answer a Certification auditor's questions. This preparation might include strict instructions:


  • Answer only the question you're asked
  • Don't elaborate
  • Don't try to answer if you don't understand the question
  • Don't give your opinion
  • If you don't know, refer the auditor to your supervisor
These "rules of engagement with the auditor" are often seen at work stations, posted in office cubes and so on. In a previous career as a Certification Auditor, I can tell you that when this approach is adopted, it can make employees overly anxious and nervous - and frankly - a good auditor will be totally able to overcome this apparent "stone-walling". In many cases, it can bring down what could have been an effective audit because communication becomes ineffective. It really is playing games, whether it's understood that way or not. And even the best of auditors will struggle to keep a smile on their face. Let's face it, this is not supposed to be an interrogation where the Geneva Convention rules apply: "Name, rank and serial number..."

A far better way to answer the imponderable question "What will they ask" and avoid any negativeness from a Certification auditor, by "stonewalling", is to do the following:

  • Take control of the audit, take the auditor to a person to...
  • Have people explain what they do, then
  • Have them demonstrate how they do it
  • Describe how the process is controlled through any applicable documents
  • Explain what they do when things might go wrong (if applicable)
  • What records are generated (if applicable)
  • If the process is performing as planned to the established goals (if applicable)
  • Their contribution to customer satisfaction and improvements
I'm not a big fan of people being able to whip out a card and recite the quality policy - it's often trite and meaningless (the policy, I mean) so what does it prove?

By taking control of the audit in this manner, the outcome of the audit will become more predictable, the auditor doesn't get to ask (obviously) dumb questions, it makes it easier for them to just audit (which is, after all, a listening activity for which they need to remain silent). As a result, the auditor gets a good feeling that this isn't going to be "one of those audits", where people don't answer freely. This automatically raises the auditor's perception in a positive way. They are able to listen, take vital notes and the pressure to be thinking of the "next question" become less of a burden.

In fact, it's less to do with "passing the audit" and more about the organization actually confirming that it has competent people, who know how to control their processes, what to do when something unplanned happens and so on - vitally important to any organization, whether they are going for ISO Certification or not. Every manager and supervisor should have confidence that their employees know their stuff!

I'd suggest that if your organization has prepared for a Certification audit, that you seriously rethink why you are doing it at all. You are probably avoiding a real issue - that of demonstrating leadership and confidence in your process controls. Imagine if a customer was hearing your people answer "just the question asked", instead of confidently describing what's done, why and how it meets their needs. I know which I'd be more impressed with, in all three roles - auditor, manager and customer.

Thursday, October 29, 2015

ISO 9001:2015 Is here! New Myths Being Created While You Read!

Back in September, the latest revision of ISO 9001 was published (technically, September 15th). Since social media is used much more than it was back when the previous revision - the year 2000 - there's been a greater amount of discussions on various platforms such as LinkedIn, Twitter, Youtube etc about what's in each iteration of the drafts, prior to publication than we had back in 1999.

The standard has been revised heavily and now looks quite different when compared to the previous edition, ISO 9001:2008. This is due to the adoption, by the writing committee ISO/TC 176, of the so-called "Annex SL" High Level Structure.

Annex SL


This is the title of the internal-to-ISO document which defines the structure or format of standards and helps with the alignment of topics or requirements across a range of management systems requirements, such as ISO 14001 (Environmental), ISO 27001 (Information Security) and so on. Instead of hunting through the clauses, it's a lot easier to locate, for example, the internal audit requirement. (9.2.2). The adoption of the Annex SL is primarily intended to allow for easier integration of management systems' requirements. An example would be the merging of a product Quality Management System, with an Environmental Management System.

Annex SL is structured around 10 headings, whereas the 2008 edition of ISO 9001 has 8. One thing that's also notable is that the heading names are quite different.




MYTH ALERT!


"We'll have to renumber our Quality Manual to map to the new structure, to show the CB auditors how we address each ISO requirement"



MYTH BUSTED:


Although the new edition doesn't make a quality manual a requirement (keep an eye open for another blog post on this topic) if an organization decides for one reason or another, to have or retain a quality manual, it doesn't need to follow the format of the 1-10 headings or clauses of ISO 9001. Indeed, even the supporting Quality Management Documents don't need to reference the new clauses of the international standard, either. It's a lot of work, doesn't add any value in real terms for the users and, more importantly, the mapping of requirements to the Quality Management System can be done much simpler and without involving a lot of work.

If a table or document tree is created (in Excel or similar) to cross reference the various documents which currently exist or have been (newly) created to meet the various clauses and sub clauses, it can be used by anyone who needs to know what's been mapped to what ISO 9001 requirement.

While we're on the topic of the Quality Manual, it's gone! Yes! There's no longer a stated requirement for the organization to have a Quality Manual. What were the Technical Committee thinking when they dreamed THAT one up?

If we reflect, for a minute, it may not have been such a bad thing. Let's face it. Most organizations have something which slavishly emulates the layout and content of the actual ISO standard itself. In many cases, just a simple substitution for key words and phrases has been made - for example replacing "The Organization" with "Company X" or something similar. Who wouldn't want to get rid of it?

MYTH ALERT!


WooHoo! We can get rid of the Quality manual. No-one reads it anyway, except for the CB auditor".

MYTH BUSTED:


Whoa there! Before you go consigning the Quality Manual to the recycling/bonfire/shredder, consider this:

Is it the Quality Manual which is the problem? Maybe it's the content which puts people off reading it. After all, if it's 30+ pages long, or uses terminology of the standard maybe THAT's the issue to address. After all, what organization calls their Engineering or Operations functions "Product Realization"? On top of that, there's some weasel words in the standard, too. "Where applicable" and similar terms are scattered throughout, so how is a reader to determine when it is applicable?

Let's revisit the whole idea of a Quality Manual for a minute - with a clean slate.


The "Context of the Organization" is key.


If we consider for one minute, a new requirement of the "Annex SL", which is termed the "Context of the Organization", we might give some thought to the position the organization holds in the market and what they have identified as the needs/expectations of their so-called "interested parties". These might include:
  • Customers and their representatives
  • Regulatory bodies and their representatives
  • Employees
  • Stakeholders
There may well be an expectation or need for some kind of quality manual to be maintained to satisfy one or more of the above. Long before ISO 9001 and certification by 3rd parties came along, it was common practice to create and maintain a document which was very like a quality manual, even if it wasn't actually called that. Furthermore, employees might find one useful, too!

Conclusion


If the context of the organization is properly understood, then creating and maintaining a document - call it a Quality Manual if you wish - which describes the organization, key processes, links to common organization-wide processes and much more may well be seen as a value proposition and not something done "to keep an external auditor happy".

Sunday, November 13, 2011

A Rose By Any Other Name



Previously, we discussed the fact that ISO 9001:2008 requires documentation of the organization's Quality Management System, including a Quality Manual, some procedures, and probably other types of documents of an indeterminate type. The need for any form of documentation is actually defined in the standard, under 4.2.1, in the phrase "documents...determined by the organization to be necessary to ensure effective planning, operation and control of its processes. This gives people quite a lot of freedom to create whatever quantity, content and format of documents it chooses, especially if they choose NOT to be constrained by the hierarchical "pyramid" we discussed previously.


We've established, in a previous blog entry, that the need for and content of many documents is going to be, in good part, dependent upon the competency of the people who use them. In general terms, the higher the competency of the person using documents, the less detailed the description in the document needs to be. A key consideration is that someone will probably figure out pretty quickly what the document is about, if they are competent.


Try this simple example; write down the preparation and cooking of scrambled eggs - for yourself! How detailed would such a task need to be for someone with experience in a kitchen? These are fairly simple concepts and practices, so why do people make the creation of "ISO" documentation so complex?


Form Over Function?


Where people start going off the rails in the design (format) of their Quality Manual (see 4.2.1.b). If we take a look at the ISO 9001 section which defines what should be included in a Quality Manual (4.2.2) it says:


"The organizations shall .... a quality manual that includes:-


a) the scope of the quality management system (and some stuff we won't concern ourselves with here)


b) the documented procedures - or reference to them, and


c) a description of the sequence and interaction of the QMS processes"


Pretty simple, really. If we add a couple of other requirements of ISO 9001 which would seem appropriate to include in such a manual:
  • and organization chart or some way to show who 'top management' are (5.1, 5.5.1)
  • the Quality Policy (5.3)
  • Quality Objectives (5.4.1)
  • Who the "Management Representative" is (5.5.2)
Then, maybe assign a page to each of these (which might be considered overkill), adding a nice cover page, we have a total document of some 7 pages. Going beyond what ISO-says, perhaps including some really useful information, like a description of the history/background to the company, details of markets served, products, office/factory locations, contact details, including a web address etc. we might expand it to 10 pages.


One example of an ISO 9001-compliant Quality Manual I saw was actually a tri-fold, made from an 81/2 x 11 sheet. It was prepared in the same way as a company marketing brochure might be, from the front outer cover showing a photograph of the building, the 4 "inside" pages containing the "ISO stuff" and the back page being a map, address, phone numbers etc. What a good looking, useful and very readable document! Imagine being given that on your first day at work, or as a potential customer...

It's interesting, then, to note that in spite of these (minimal) requirements, many people create (or even buy) a document which closely resembles the layout of the ISO 9001 standard itself. Since the Quality Management System is supposed to describe the key or core processes of the organization, which are responsible for determining customers' requirements, through to delivering product/service to those customers, and also the process which support and enable the key/core processes, why use ISO 9001 as a template? It clearly isn't laid out in this manner! 


If we take a look at other types of documents the standard mentions (or people think are necessary), it's common to employ the following format for procedures and work instructions, which often  includes:
  • Purpose
  • Scope
  • Applicability
  • Definitions
  • ISO 9000 reference(s)
  • Responsibilities
  • Flow chart (possibly)
  • Procedure
  • Records
  • Change History
In one (extreme case), even the office stationery needed to complete the work was listed!


Good grief! Look at how much "stuff" has to be waded through before any mention of a procedure is made! Plus, with all this content, how many pages are the result? No wonder people have heard that "ISO" is a paperwork nightmare!


Good Design - You Know It When You See It!


Rigorous adherence to a format is NOT what is required. Well communicated requirements and controls are! The documented management system is a product first and foremost. And good product design considers, first and foremost, the needs of the user. In fact, good product design is elegant! If you look up “elegant” in a dictionary, one of the definitions is:
"gracefully concise and simple; admirably succinct"
Notice it doesn’t just say “concise” or “simple” or “succinct”, but “gracefully concise” and “admirably succinct”. And, for many of us, we know it when we see it. Consider Apple products, if you want a really good example. People actually get "carried away" with their ownership of Apple iPhones, Macs etc. OK, so maybe that's a little extreme as a comparison for QMS documentation, but why shouldn't an organization strive to make its documentation at least "friendly" to users? Why does everything have to be forced to fit this structure?
The answer is, of course, that it doesn't. Now, we all use documentation in our everyday lives - outside of any ISO based QMS - without the need for an similar format. Take, for example a humble bank note, or a bus or train ticket. Often they contain a lot of information. Some of it is for us, some used by the issuing agency. Do they need the structure above, to enable them to be used by a huge population of users with all levels of education etc?


Frankly, I see no real reason to force such a set of descriptors on what should be simple documents. What are we attempting to use QMS documents for? Convey the requirements for effective process "planning, operation and control", elegantly...