ISO 9000 Standards – Document Approval

ISO 9000 Standards – Document Approval

The ISO 9000 Standards requires that documents be approved for adequacy prior to issue.

Approval prior to issue means that designated authorities have agreed the document before being made available for use. Whilst the term ade-
quacy is a little vague it should be taken as meaning that the document is judged as fit for the intended purpose. In a paper based system, this means approval before the document is distributed. With an electronic system, it means that the documents should be approved before they are published or made available to the user community.

The ISO 9000 Standards document control process needs to define the process by which documents are approved. In some cases it may not be necessary for anyone other than the approval authority to examine the documents. In others it may be necessary to set up a panel of reviewers to solicit their comments before approval is given.
It all depends on whether the approval authority has all the information
needed to make the decision and is therefore ‘competent’. One might think that the CEO could approve any document in the organization but just because a person is the most senior executive does not mean he or she is competent to perform any role in the organization.

Users should be the prime participants in the approval process so that the
resultant documents reflect their needs and are fit for the intended purpose. If the objective is stated in the document, does it fulfil that objective? If it is stated that the document applies to certain equipment, area or activity, does it cover that equipment, area or activity to the depth expected of such a document? One of the difficulties in soliciting comments to documents is that you will gather comment on what you have written but not on what you have omitted. A useful method is to ensure that the procedures requiring the document specify the acceptance criteria so that the reviewers and approvers can check the document against an agreed standard.

To demonstrate documents have been deemed as adequate prior to issue,
you will need to show that the document has been processed through the
prescribed document approval process. Where there is a review panel, a simple method is to employ a standard comment sheet on which reviewers can indicate their comments or signify that they have no comment. During the drafting process you may undertake several revisions. You may feel it
necessary to retain these in case of dispute later, but you are not required to do so. You also need to show that the current issue has been reviewed so your comment sheets need to indicate document issue status.

Identifying and Recording Design Changes In ISO 9000 Standards

Identifying and Recording Design Changes In ISO 9000 Standards

The documentation for design changes in ISO 9000 Standards should comprise the change proposal, the results of the evaluation, the instructions for change and traceability in the changed documents to the source and nature of the change. You will therefore need:
- A Change Request form which contains the reason for change and the
results of the evaluation – this is used to initiate the change and obtain
approval before being implemented.
- A Change Notice that provides instructions defining what has to be changed this is issued following approval of the change as instructions to the owners of the various documents that are affected by the change.
- A Change Record that describes what has been changed – this usually forms part of the document that has been changed and can be either in the form of a box at the side of the sheet (as with drawings) or in the form of a table on a separate sheet (as with specifications).
Where the evaluation of the change requires further design work and possibly experimentation and testing, the results for such activities should be documented to form part of the change documentation.
At each design review a design baseline should be established which identifies the design documentation that has been approved. The baseline
should be recorded and change control procedures employed to deal with any changes. These change procedures should provide a means for formally
requesting or proposing changes to the design. For complex designs you may prefer to separate proposals from instructions and have one form for proposing design changes and another form for promulgating design changes after approval. You will need a central registry to collect all proposed changes and provide a means for screening those that are not suitable to go before the review board, (either because they duplicate proposals already made or because they may not satisfy certain acceptance criteria which you have prescribed). On receipt, the change proposals should be identified with a unique number that can be used on all related documentation that is subsequently produced. The change proposal needs to:
- Identify the product of which the design is to be changed
- State the nature of the proposed change identify the principal requirements, specifications, drawings or other design documents which are affected by the change
- State the reasons for the change either directly or by reference to failure
reports, nonconformity reports, customer requests or other sources
- Provide for the results of the evaluation, review and decision to be
recorded

Documenting A Quality Management System

Documenting A Quality Management System

The ISO 9000 Standards requires the organization to document a quality management system in accordance with the requirements of ISO 9001. A document (according to ISO 9000 clause 2.7.1) is information and its supporting medium. A page of printed information, a CD ROM or a computer file is a document, implying that recorded information is a document and verbal information is not a document.
Clause 4.2 requires the management system documentation to include certain types of documents and therefore does not limit the management system documentation to the types of documents listed.
As a management system is the means to achieve the organization’s objectives, and a system is a set of interrelated processes, it follows that what has to be documented are all the processes that constitute the system.
While there is a reduction in emphasis on documentation in ISO 9001:2008 compared with the 1994 version, it does not imply that organizations will need less documentation to define their management system. What it does mean is that the organization is left to decide the documentation necessary for effective operation and control of its processes. If the absence of specific documentation does not adversely affect operation and control of processes, such documentation is unnecessary.
Before ISO 9000 came along, organizations prospered without masses of
documentation and many still do. Those that have chosen not to pursue the
ISO 9000 path often only generate and maintain documents that have a useful purpose and will not produce documents just for auditors unless there is a legal requirement. Most of the documentation that is required in ISO 9000 came about from hindsight – the traditional unscientific way organizations learn and how management systems evolve.
ISO 9000 contains a list of valid reasons for why documents are necessary as below:
- To communicate requirements, intentions, instructions, methods and results effectively
- To convert solved problems into recorded knowledge so as to avoid having
to solve them repeatedly
- To provide freedom for management and staff to maximize their contribution to the business
- To free the business from reliance on particular individuals for its effectiveness
- To provide legitimacy and authority for the actions and decisions needed
- To make responsibility clear and to create the conditions for self-control
- To provide co-ordination for inter-departmental action
- To provide consistency and predictability in carrying out repetitive tasks
- To provide training and reference material for new and existing staff
- To provide evidence to those concerned of your intentions and your actions
- To provide a basis for studying existing work practices and identifying
opportunities for improvement
- To demonstrate after an incident the precautions which were taken or which should have been taken to prevent it or minimize its occurrence
If only one of these reasons make sense in a particular situation, the
information should be documented. In some organizations, they take the
view that it is important to nurture freedom, creativity and initiative and
therefore feel that documenting procedures is counterproductive. Their view is thatdocumented procedures hold back improvement, forcing staff to follow routines without thinking and prevent innovation. While it is true that blindly enforcing procedures that reflect out-of-date practices coupled with bureaucratic change mechanisms is counter productive, it is equally shortsighted to ignore past experience, ignore decisions based on valid evidence and encourage staff to reinvent what were perfectly acceptable methods.
Question by all means, encourage staff to challenge decisions of the past, but
encourage them to put forward a case for change. That way it will cause
them to study the old methods, select the good bits and modify the parts that are no longer appropriate. It is often said that there is nothing new under the sun – just new ways of packaging the same message.

What Should Be Documented In Quality Management System?

What Should Be Documented In Quality Management System?

Clause 4.2.1 in ISO 9000 Standards requires quality management system documentation to include 5 types
of document:
(a) Quality policy and objectives
(b) Quality manual
(c) Documented procedures
(d) Documents needed to ensure the effective planning, operation and control of processes
(e) Records
Other than the requirements in clause 4 for documentation, there are 14 other references requiring documentation. These are as follows:
(a) The output of the planning
(b) The quality manual
(c) A documented procedure for document control
(d) A documented procedure for the identification, storage, retrieval, protection, retention time and disposition of records.
(e) Planning of the realization processes
(f) Inputs relating to product requirements
(g) The outputs of the design and development process
(h) Design and development changes
(i) The results of the review of changes and subsequent follow up actions
(j) A documented procedure for conducting audits that includes the responsibilities and requirements
(k) Evidence of conformity with the acceptance criteria characteristics of the product
(l) A documented procedure for nonconformity control activities
(m)A documented procedure for corrective action
(n) A documented procedure for preventive action
This list is somewhat inadequate for documentation purposes because it does not tell us what types of things we should document or provide criteria to enable us to decide what we need to document. ISO 9000 clause 2.7.2 includes a more useful list of document types that are classified as follows:
(a) Quality manuals
(b) Quality plans
(c) Specifications
(d) Guidelines
(e) Procedures, work instructions and drawings
(f) Records
This list is similar to that in clause 4.2.1 with some notable differences. The
policy and objective could form part of the quality manual and the quality plans, work instructions, guidelines, drawings and specifications could be the documents needed to ensure the effective planning, operation and control of processes.
Obviously the size, type and complexity of the organization and the competency of personnel will have an effect on the depth and breadth of the
documentation but the subject matter other than that which is product, process or customer specific is not dependent on size, type and complexity of the organization etc. There is no single method that will reveal all the things that should be documented but there are several approaches that can be used to reveal the documentation necessary.

ISO 9001 Standards Requirements – Design and Development

ISO 9001 Standards Requirements – Design and Development

Design and Development Planning
Plan and control the product design and development. This planning must determine the:
Stages of design and development
Appropriate review, verification, and validation activities for each stage
Responsibility and authority for design and development
The interfaces between the different involved groups must be managed to ensure effective communication and the clear assignment of responsibility. Update, as appropriate, the planning output during design and development.
NOTE: Design and development review, verification, and validation have distinct purposes. They can be conducted and recorded separately or in any combination, as deemed suitable for the product and the organization.

Design and Development Inputs
Determine product requirement inputs and maintain records. The inputs must include:
Functional and performance requirements
Applicable statutory and regulatory requirements
Applicable information derived from similar designs
Requirements essential for design and development
Review these inputs for adequacy. Resolve any incomplete, ambiguous, or conflicting requirements.

Design and Development Outputs
Document the outputs of the design and development process in a form suitable for verification against the inputs to the process. The outputs must:
Meet design and development input requirements
Provide information for purchasing, production, and service
Contain or reference product acceptance criteria
Define essential characteristics for safe and proper use
Be approved before their release

Design and Development Review
Perform systematic reviews of design and development at suitable stages in accordance with planned arrangements to:
Evaluate the ability of the results to meet requirements
Identify problems and propose any necessary actions
The reviews must include representatives of the functions concerned with the stage being reviewed. Maintain the results of reviews and subsequent follow-up actions.

Design and Development Verification
Perform design and development verification in accordance with planned arrangements to ensure the output meets the design and development input requirements. Maintain the results of the verification and subsequent follow-up actions.

Design and Development Validation
Perform validation in accordance with planned arrangements to confirm the resulting product is capable of meeting the requirements for its specified application or intended use, where known. When practical, complete the validation before delivery or implementation of the product. Maintain the results of the validation and subsequent follow-up actions.

Control of Design and Development Changes
Identify design and development changes and maintain records. Review, verify, and validate (as appropriate) the changes and approve them before implementation. Evaluate the changes in terms of their effect on constituent parts and products already delivered. Maintain the results of the change review and subsequent follow-up actions.