The best way to start when learning how to read a standard is to read the scope before reading the requirements. Often we open up a standard at the first requirement, and start reading through it from there. Although this can be the quickest way to find the information we are looking for, it is often the most confusing. Sometimes clauses appear to be relevant but, in fact, they are only meant to apply to a specific product, process, organisation or situation. Before you try to work out what a clause is saying, take a moment to read the scope. In just a few sentences, the scope outlines the boundaries of the document and gives you some clues about what you may want to focus on.
Often the scope will give you some idea of what the standard is about, what it is intended to do, and perhaps even what it is not intended to do. Within the scope you will find some nouns that will tell you the topic, some verbs that will tell you what is intended, and some phrases that will give you the limits, such as “applies to”, “specifies requirements for” etc. This information is not just fluff, it is the information you will need in order to know what to do with the rest of the document.
Consider a standard that has been developed that specifies requirements for temperature-controlled storage during transportation. You come across a clause that deals with temperature monitoring and logging, and assume that the same clause must apply to your warehouse storage. You have misinterpreted this clause, because it is only meant to apply to transport-related storage. The clause has not changed, but its limits have. By taking a moment to read the scope, you would have seen that this clause does not apply to the warehouse. Reading the scope will stop you from copying a requirement into a process that it wasn’t written for.
To get a feel for this approach, take a short extract from a standard and read the title and the scope. Then write down a sentence to answer each of the following questions: What is covered? What/who does it involve? Where does it end? Next, identify any words that are unclear, and take a look in the terms and definitions section to ensure you are using the right definition. A word like “supplier”, “service” or “inspection” might have a very specific meaning within the document, which is different to what it means in general use.
You may also want to look at the normative references and annexes section to get an understanding of what additional documents or material are required. Just because a document has been referenced doesn’t necessarily mean it’s mandatory; and just because something is an annex doesn’t mean it is mandatory. Take a look at the scope again, and see if the wording of the references and annexes give you any clue as to whether they form part of the requirements or not.
Once you have identified clauses that are going to be useful, and have translated them into your own procedures or checklists, keep a copy of the scope available. It is a good idea to make a brief note next to the clause outlining the process, item, or situation to which it relates. This creates a traceability link between the source document and the procedure, and means that someone who has not seen the original document will still be able to see why you have included this information.
Once you begin reading the scopes, you will probably notice a change in your habits, instead of wondering whether or not a clause is relevant after you have decided to include it, you will begin wondering whether a clause is even relevant to begin with. The question changes from “what does this clause require?” to “does this clause apply here?” This habit will help to reduce the number of unnecessary clauses in your documents, keep your procedures more closely aligned with your processes, and improve the quality of your documentation.