November, 2005
Visit and
bookmark our web site today: http://www.WhittingtonAssociates.com
This e-Newsletter is in HTML
format and may not be displayed properly by some email programs. Please
click on our web site address above
to see the e-Newsletter with its proper formatting.
November Articles
|
Public Classes |
Click
on an article title to
jump to the
article:
1. ISO 14001:2004
Requirements Summary
2. Managing Risk
in Projects
3. ISO 9001:2000
Guidelines for Government
4. New ISO 9000:2005 Edition
5.
Classes: November, 2005 - January, 2006
BOOKS: See recommended
ISO 9001, Auditing, and Six Sigma books at:
http://www.whittingtonassociates.com/v2/books.shtml
To
see previous
articles, go to Newsletter
Archives.
To avoid this
newsletter
being rejected, or placed in a junk folder, please add Larry@WhittingtonAssociates.com
to your address
book or accepted list.
|
Click
on a course to
jump to its description and class schedule:
|
| Atlanta Classes |
Enroll and pay for an
Atlanta class at least 30 days in advance of the class and receive a
10% discount.
|
Students at previous
Atlanta classes receive a 20% discount on future Atlanta classes.
|
|
ISO 17799:2005 -
Information Security
|
ISO 9001:2000 - Quality Systems
|
ISO
17799 - Understanding an Information Security Management System
February 7-8, 2006
ISO
27001 - Information Security Management System Auditor
February 13-17, 2006
ISO 17799 - Information Security Management System
Implementation
December 5-9, 2005
|
Understanding ISO 9001:2000 Requirements
November 14, 2005; February 6, 2006
Quality Systems Documentation
November 15-16, 2005;
February 7-8, 2006
Implementing ISO 9001:2000
November 17-18, 2005;
February 9-10, 2006
ISO
9001:2000 Internal Auditor
Nov. 29 - Dec. 1,
2005;
January 24-26, 2006
ISO
9001:2000 Lead Auditor
December 12-16, 2005;
February 13-17, 2006
|
ISO 14001:2004 - Environmental Systems
|
Six Sigma |
|
Understanding ISO 14001:2004 Requirements
January 30, 2006
Implementing an Environmental Management System
January 30 - February 1, 2006
ISO
14001:2004 Internal Auditor
February 20-21, 2006
ISO
14001:2004 Lead Auditor
March 27 - 31, 2006
|
Introduction
to Statistics
November 30 -
December 2, 2005
Green
Belt Certification
December 12-14, 2005
January 23-25, 2006
Black
Belt Certification
Group 20 (3 weeks): February 13-17, 2006
+ March 13-17, 2006 + April 17-21, 2006
|
|
1. ISO 14001:2004 Requirements Summary
|
I prepared
this summary of the ISO 14001:2004 requirements for my clients. See the
actual
standard for a complete description of the requirements.
4.1 General
Requirements
- Establish,
document, and implement environmental system
- Maintain and
continually improve the environmental system
- Determine how
system will meet requirements of standard
- Document scope of
the environmental management system
4.2 Environmental
Policy
- Define and
document the environmental policy
- Ensure
appropriate for activities, products, and services
- Commit to
pollution prevention and continually improvement
- Include
compliance with legal and other requirements
- Provide framework
for environmental objectives and targets
- Communicate to
all working for or on behalf of organization
- Make
environmental policy available to public
4.3 Planning
4.3.1 Environmental
Aspects
- Implement
procedure to identify environmental aspects
- Identify aspects
of activities, products, and services
- Include aspects
within the defined scope of system
- Consider aspects
that can control or can influence
- Take into account
planned or new developments
- Determine aspects
with significant impact on environment
- Document aspects
and impacts and keep up to date
- Ensure
significant aspects are taken into account in system
4.3.2 Legal and Other
Requirements
- Implement
procedure to identify and access legal requirements
- Determine how
requirements apply to environmental aspects
- Ensure
requirements are considered in environmental system
4.3.3 Objectives,
Targets, and Programs
- Document
environmental objectives and targets
- Establish
measurable targets consistent with policy
- Commit to
compliance with legal and other requirements
- Commit to
pollution prevention and continually improvement
- Take into account
legal requirements and significant aspects
- Consider
technology options and views of interested parties
- Address
financial, operational, and business requirements
- Implement a
program to achieve objectives and targets
- Designate
responsibility at relevant functions and levels
- Include means and
timeframe for achieving the targets
4.4 Implementation and
Operation
4.4.1 Resources, Roles,
Responsibility, and Authority
- Ensure
availability of resources for environmental system
- Include human
resources and specialized skills
- Address
infrastructure, technology, and finances
- Document and
communicate responsibilities and authorities
- Appoint
management representative with following duties
- Ensure system is
maintained according to standard
- Report to top
management on performance of system
- Include
recommendations for improvement
4.4.2 Competence,
Training, and Awareness
- Ensure persons
with environmental tasks are competent
- Judge competency
based on education, training, or experience
- Keep records of
education, training, and experience
- Identify training
needs based on system and aspects
- Provide training,
or other actions, and keep records
- Implement
procedure for awareness of following factors
- Stress importance
of conformity to policies and procedures
- Point out
significant aspects and actual or potential impacts
- Identify
environmental benefits of improved personal performance
- Clarify roles and
responsibilities for conformity to requirements
- Identify
potential consequences of departure from procedures
4.4.3 Communication
- Implement
procedure for internal communication
- Consider at
relevant levels and functions of organization
- Implement
procedure for external communication
- Consider
receiving, documenting, and responding
- Decide if will
communicate externally on significant aspects
- Document this
decision on external communication
- Implement method
for external communication, if needed
4.4.4 Documentation
- Document
environmental policy, objectives, and targets
- Describe scope of
environmental management system
- Describe main
system elements and their interaction
- Refer to related
documents for these main elements
- Include documents
and records required by standard
- Include
documentation needed for effective processes
4.4.5 Control of
Documents
- Control documents
needed for system or standard
- Implement
procedure to control these documents
- Approve documents
for adequacy prior to issue
- Review and update
as necessary and re-approve
- Identify document
changes and revision status
- Ensure documents
are available at points of use
- Keep documents
legible and readily identifiable
- Identify and
control distribution of external documents
- Prevent
unintended use of obsolete documents
- Apply suitable
identification if documents retained
4.4.6 Operational
Control
- Identify and plan
operations with significant aspects
- Plan consistent
with policy, objectives, and targets
- Ensure carried
out under specified conditions
- Implement
documented procedures as needed
- Use where their
absence could lead to deviations
- Stipulate the
operating criteria in the procedures
- Implement
procedures related to environmental aspects
- Communicate
procedures to suppliers and subcontractors
4.4.7 Emergency
Preparedness and Response
- Identify
potential emergencies and accidents
- Implement
procedure on how to respond to them
- Respond to actual
emergencies and accidents
- Prevent or
mitigate adverse environmental impacts
- Review procedures
periodically and revise as needed
- Test procedures
periodically, where practical
4.5 Checking
4.5.1 Monitoring and
Measurement
- Implement
procedure to monitor and measure operations
- Monitor key
characteristics that have significant impact
- Document data on
performance, conformity, and controls
- Judge conformity
to environmental objectives and targets
- Maintain and use
calibrated or verified equipment
- Keep records of
monitoring and measurement equipment
4.5.2 Evaluation of
Compliance
4.5.2.1
- Evaluate
compliance with legal requirements
- Implement
procedure for periodic evaluations
- Keep records of
results of periodic evaluations
4.5.2.2
- Evaluate
compliance with other requirements
- Consider
establishing a separate evaluation procedure
- Consider
combining with evaluation of legal compliance
- Keep records of
results of periodic evaluations
4.5.3 Nonconformity,
Corrective Action, and Preventive Action
- Implement
procedure for dealing with nonconformities
- Include procedure
for corrective and preventive action
- Identify and
correct nonconformities
- Take actions to
mitigate environmental impacts
- Investigate
nonconformities and determine causes
- Take actions to
avoid their recurrence
- Evaluate need for
actions to prevent nonconformities
- Implement actions
to avoid their occurrence
- Record results of
corrective and preventive actions
- Review
effectiveness of the actions taken
- Act based on
problem magnitude and environmental impact
- Ensure changes
are made to system documentation
4.5.4 Control of
Records
- Maintain records
as evidence of conformity
- Use records to
demonstrate achieved results
- Implement
procedure for control of records
- Identify, store,
and protect the records
- Keep legible,
identifiable, and traceable
- Retrieve, retain,
and dispose of records
4.5.5 Internal Audit
- Ensure internal
audits are held at planned intervals
- Determine if
system conforms to requirements
- Determine if
system implemented and maintained
- Plan audit
program based on areas and prior audits
- Implement
procedure that addresses responsibilities
- Cover planning,
conducting, reporting, and recording
- Determine
criteria, scope, frequency, and methods
- Ensure auditors
and audits are impartial and objective
4.6 Management Review
- Review
environmental system at planned intervals
- Ensure its
suitability, adequacy, and effectiveness
- Include
assessment of improvement opportunities
- Assess need for
system changes, including targets
- Include results
of audits and compliance evaluations
- Cover external
communications and any complaints
- Examine
environmental performance of organization
- Include the
extent to which targets have been met
- Review status of
corrective and preventive actions
- Address follow-up
actions from previous reviews
- Consider changing
circumstances related to aspects
- Evaluate
recommendations for improvement
- Keep records of
management reviews
- Include decisions
and actions in records
For a list of our ISO
14001:2004 courses,
go to:
(http://www.whittingtonassociates.com/v2/training/courses.shtml#ems).
2. Managing Risk in Projects
|
Although ISO 9001:2000, clause 0.4, says the standard doesn't
include
any requirements for risk management, ISO 9004:2000 provides
guidance
across multiple clauses that the organization should identify, assess,
and
mitigate risk.
RISK GUIDANCE IN ISO 9004:2000
ISO 9004:2000, clause 5.1.2, Issues to be Considered, states that
management should
consider identifying and managing risks. Clause 5.4.2, Quality
Planning, says that inputs for effective and efficient planning include
risk assessment and mitigation data.
Clause 5.6.3, Management Review Output, says additional outputs may
include loss prevention and mitigation plans for identified risks.
Clause 6.3 states that infrastructure planning should consider the
identification and mitigation of associated risks.
Clause 7.1.3.1, Managing Processes - General, says an operating plan
should be defined to manage the
processes, including identification, assessment, and mitigation of
risk. Clause 7.1.3.3. Product and Process Validation and Changes, says
that risk assessment should be
undertaken to assess the potential for, and the effect of, possible
failures or faults in processes. And, that the results of the
assessment should be used to define and implement preventive actions to
mitigate the identified risks.
Design and Development, clause 7.3.1, says management has the
responsibility to ensure steps are taken to identify and mitigate
potential risk to the users of the product and the processes of the
organization. Risk assessment should be undertaken to assess the
potential for, and effect of, possible failures or faults in products
or processes. The results of the assessment should be used to define
and implement preventive actions to mitigate the identified risks.
Clause 7.4.1, Purchasing Process, says management should identify and
mitigate
any risk associated with the purchased product. Clause 7.5.2 for
Product Identification (yes, 7.5.2 in ISO 9004; not 7.5.3 as in ISO
9001) says the need for
identification and traceability may arise from the mitigation of
identified risks. Clause 8.5.3 on Loss Prevention refers to the data
generated from the use of risk analysis tools, such as, fault mode and
effects analysis.
Although ISO 9001:2000 doesn't require risk management, ISO 9004:2000
strongly
suggests it. But what is risk management? The February 2005 issue of
CrossTalk includes an article, Understanding Risk Management, which is
edited below for an answer:
RISK MANAGEMENT
Risk is a product of the uncertainty of
future events and is a part of any process. It is a fact for any
organization. We typically try to stay
away from situations that involve high
risk. However, when we cannot
avoid risk, we look for ways to reduce
it (or its impact). Yet, even
with careful planning and preparation,
risks cannot be completely eliminated
because they cannot be completely identified
in advance. However, strange as it may seem, risk is essential to
progress.
The opportunity to succeed also carries
the opportunity to fail. So, we have to learn to balance the possible
negative
consequences of risk with the potential
benefits of its associated opportunity.
Risk may be defined as the possibility to
suffer damage or loss. The possibility is
characterized by three factors:
- The probability, or likelihood, that loss
or damage will occur.
- The expected time of occurrence.
- The magnitude of the negative
impact that can result from its occurrence.
From a project perspective, the seriousness of a
risk can be
determined by multiplying the probability
of the event actually occurring by the
potential negative impact to the cost,
schedule, or performance of the project:
Risk Severity = Probability of
Occurrence x Potential Negative
Impact
Thus, risks where the probability of occurrence
is high and the potential impact is very
low, or vice versa, are not considered as
serious as risks where both the probability of
occurrence and the potential impact are
medium to high. Managers should recognize
and
accept the fact that risk is inherent in any
project.
There
are two ways of dealing with this risk. One,
risk management, is proactive and carefully
analyzes future project events and
past projects to identify potential risks.
Once risks are identified, they are dealt
with by taking measures to reduce their
probability or to reduce their impact. The
alternative to risk management is crisis
management. It is a reactive and
resource-intensive process, with available
options constrained or restricted by
events.
Effective risk management requires
establishing and following a rigorous
process. Because risks will be found in all
areas, and will often be
interrelated, risk management should
address all processes of the system.
Process Description
Various paradigms are used by different
organizations to coordinate their risk
management activities. While
there are variations in the different paradigms,
certain characteristics are universally
required for the program to be successful:
- The risk management process is
planned and structured
- The risk process is integrated with the
acquisition process
- Developers, users, procurers, and all
other stakeholders work together
closely to implement the risk process
- Risk management is an ongoing
process with continual monitoring
and reassessment
- A set of success criteria is defined for
all cost, schedule, and performance
elements of the project
- Metrics are defined and used to monitor
effectiveness of risk management
strategies
- An effective test and evaluation program
is planned and followed
- All aspects of the risk management
program are formally documented
- Communication and feedback are an
integral part of all risk management
activities
While your risk management
approach should be tailored to your organizational needs, it should
incorporate these
fundamental characteristics. In essence, the process is a standard
approach to problem solving:
- Plan or define the problem-solving
process.
- Define the problem.
- Work out solutions for those problems.
- Track the progress and success of the
solutions.
RISK MANAGEMENT PROCESS
Planning
Risk planning includes developing and
documenting a structured, proactive, and
comprehensive strategy to deal with risk.
Key to this activity is establishing methods
and procedures to do the following:
- Establish an organization to take part
in the risk management process.
- Identify and analyze risks.
- Develop risk-handling plans.
- Monitor or track risk areas.
- Assign resources to deal with risks.
Assessment
Risk assessment involves two primary
activities: risk identification and risk
analysis. Risk identification is actually
begun early in the planning phase and
continues throughout the life of the project.
The following methods are often
used to identify possible risks:
- Brainstorming
- Evaluations or inputs from project
stakeholders
- Periodic reviews of project data
- Questionnaires based on taxonomy,
the classification of product areas and
disciplines
- Interviews based on taxonomy
- Analysis of the Work Breakdown
Structure
- Analysis of historical data
When identifying a risk, it is essential
to do so in a clear and concise statement.
It should include three components:
- Condition: A sentence or
phrase
briefly describing the situation or circumstance
that may have caused concern,
anxiety, or uncertainty.
- Consequence: A sentence
describing
the key negative outcomes that may
result from the condition.
- Context: Additional
information
about the risk to ensure others can
understand its nature, especially after
the passage of time.
The other half of assessment is risk
analysis. This is the process of examining
each risk to refine the risk description,
isolate the cause, quantify the probability
of occurrence, and determine the nature
and impact of possible effects. The result
of this process is a list of risks rated and
prioritized according to their probability
of occurrence, severity of impact, and
relationship to other risk areas.
Once risks have been defined, and
probability of occurrence and consequences
assigned, the risk can be rated as
to its severity. This facilitates prioritizing
risks and deciding what level of resources
to devote to each risk.
Assessment Guide (Based on the Defense Acquisition
University
Assessment Model)
This assessment model uses risk probability
and consequence levels in a matrix to
determine a level of risk severity. In addition
to an overall method of risk rating,
the model also gives good examples of
probability levels and types and levels of
consequences. The ratings given in the
assessment guide matrix are suggested
minimum ratings. It may be necessary to
adjust the moderate and high thresholds
to better coincide with your type of project.
| Probability
Levels |
1
|
2
|
3
|
4
|
5 |
E =
significant; near certainty
|
Moderate
|
Moderate
|
HIGH
|
HIGH
|
HIGH
|
| D = large;
highly likely |
Low
|
Moderate
|
Moderate
|
HIGH
|
HIGH
|
C =
probable; likely
|
Low |
Low |
Moderate |
Moderate |
HIGH
|
B = small;
unlikely
|
Low |
Low |
Low |
Moderate |
Moderate |
A = minimal;
remote
|
Low |
Low |
Low |
Low |
Moderate |
Probability (Rows above)
Levels A to E are the levels of likelihood risk will happen.
Consequence (Columns above)
Level
|
Performance
|
Schedule
|
Cost
|
Impact on
other teams
|
1
|
Minimal or
no impact
|
Minimal or
no impact |
Minimal or
none
|
None
|
2
|
Acceptable
with some reduction in margin
|
Additional
resources required; able to met need dates
|
<5%
|
Some
|
3
|
Acceptable
with significant reduction in margin
|
Minor slip
in key milestone; not able to meet need dates
|
5-7%
|
Moderate
|
4
|
Acceptable;
no remaining margin
|
Minor slip
in key milestone or critical path impacted
|
7-10%
|
Major
|
5
|
Unacceptable
|
Cannot
achieve key team or major project milestone
|
>10%
|
Unacceptable
|
Risk Impact Rating
High: Significant impact on cost,
schedule, and performance. Significant action required. High priority
management attention required.
Moderate: Some impact. Special action may be required.
Additional
management attention may be needed.
Low: Minimum impact. Normal
oversight
needed to ensure risk remains low.
Handling
Risk handling is the process that
identifies,
evaluates, selects, and implements
options for mitigating risks. Two approaches are used in
handling risk. The first is to employ
options that reduce the risk itself. This
usually involves a change in current conditions
to lessen the probability of occurrence.
The second approach, often
employed where risk probability is high,
is to use options that reduce the negative
impact to the project if the risk condition
should occur. Improving jet engine maintenance
and inspection procedures to
reduce the risk of in-flight engine failure
is an example of the first approach.
Providing a parachute for the pilot, to
reduce loss if the risk condition should
occur, is an example of the second
approach.
Monitoring
Risk monitoring is the process of continually
tracking risks and the effectiveness
of risk handling options to ensure risk
conditions do not get out of control.
This is done by knowing the baseline risk
management plans, understanding the
risks and risk handling options, establishing
meaningful metrics, and evaluating
project performance against the established
metrics, plans, and expected results
throughout the acquisition process.
Continual monitoring also enables new
risks to be identified if they become
apparent over time. Further monitoring may reveal the
interrelationships between
various risks.
The monitoring process provides
feedback into all other activities to
improve the ongoing, iterative risk management
process for the current and
future projects.
Documentation
Risk documentation is absolutely essential
for current, as well as, future projects.
It consists of recording, maintaining,
and reporting risk management
plans, assessments, and handling information.
It also includes recording the
results of risk management activities,
providing a knowledge base for better
risk management in later stages of the
project and in other projects.
Documentation should include - at a
minimum - the following information:
- Risk management plans
- Project metrics to be used for risk
management
- Identified risks and their descriptions
- The probability, severity of impact,
and prioritization of all known risks
- Description of risk handling options
selected for implementation
- Project performance assessment
results, including deviations from the
baseline plans
- Records of all changes to the above
documentation, including newly identified
risks, plan changes, etc.
Risk Management
Checklist
This checklist is provided to assist you in
risk management for a "software" project, but can be related to other
types of projects. If you answer NO to
any of these important questions, you should examine
the situation carefully to avoid greater risks to your project.
This is
only a brief checklist for such an
important subject. See the article, Understanding
Risk Management, in the February 2005 issue of CrossTalk for more
information and references to expanded checklists.
- Do you have a comprehensive,
planned, and documented approach
to risk management?
- Are all major areas and disciplines
represented
on your risk management
team?
- Is the project manager experienced
with similar projects?
- Do the stakeholders support disciplined
development methods that
incorporate adequate planning,
requirements analysis, design, and
testing?
- Is the project manager dedicated to
this project, and not dividing his or
her time among other efforts?
- Are you implementing a proven
development methodology?
- Are requirements well defined,
understandable,
and stable?
- Do you have an effective requirements
change process in place, and do
you use it?
- Does your project plan call for tracking/
tracing requirements through all
phases of the project?
- Are you implementing proven technology?
- Are suppliers stable, and do you have
multiple sources for hardware and
equipment?
- Are all procurement items needed for
your development effort short lead-time
items (no long-lead items)?
- Are all external and internal interfaces
for the system well defined?
- Are all project positions appropriately
staffed with qualified, motivated personnel?
- Are developers trained and experienced
in their respective development
disciplines (i.e., software engineering, language,
platform, tools, etc.)?
- Are developers experienced or familiar
with the technology and the development
environment?
- Are key personnel stable and likely to
remain in their positions throughout
the project?
- Is project funding stable and secure?
- Are all costs associated with the project
known?
- Are development tools and equipment
used for the project state-of-the-art, dependable, and available in
sufficient quantity?
- Are the schedule estimates free of
unknowns?
- Is the schedule realistic to support an
acceptable level of risk?
- Is the project free of special environmental
constraints or requirements?
- Is your testing approach feasible and
appropriate for the components and
system?
- Have acceptance criteria been established
for all requirements and agreed
to by all stakeholders?
- Will there be sufficient equipment to
do adequate integration and testing?
- Has sufficient time been scheduled
for system integration and testing?
- Can software be tested without complex
testing or special test equipment?
- Is a single group in one location
developing the system?
- Are subcontractors reliable and
proven?
- Is all project work being done by
groups over which you have control?
- Are development and support teams
all collocated at one site?
- Is the project team accustomed to
working on an effort of this size (neither
bigger nor smaller)?
Summary
Project managers recognize and accept
the fact that risk is inherent in any project.
The most successful project managers
choose to deal proactively with risk.
They carefully analyze future project
events and past projects to identify
potential risks. Once risks are identified,
managers take steps to reduce their probability,
or to reduce the impact associated
with them, by establishing and following a
rigorous process which involves the
entire project team, as well as, outside
experts.
Risk management should include
hardware, software, integration issues,
and the human element. A risk management
process includes planning, assessment,
handling, monitoring, and documentation.
Risk is a product of the
uncertainty of future events and is a part
of all activities. Learning to balance its possible
negative consequences with its
potential benefits is the key to successful
risk management.
Note: This article is based on an edited
version of Understanding
Risk Management, in the February 2005 issue of CrossTalk, The
Journal of Defense Software Engineering.
3. ISO 9001:2000 Guidelines for Local Government
|
IWA 4:2005 - Quality
Management Systems – Guidelines for the
Application of ISO 9001:2000 in Local Government, provides local governments with guidelines for the
voluntary application
of ISO 9001:2000. The guidelines provided by this International Workshop Agreement do not,
however, add, change, or modify the requirements of ISO 9001:2000.For a local government to be considered reliable, it should
guarantee minimum conditions of reliability for the processes that are
necessary to provide all the services needed by its citizens in a
consistent and reliable manner. All the local government's processes
should be part of a single, integral, quality management system.
The integral
character of this system is important because, otherwise, a
local government could be reliable in some areas of activity, but
unreliable in others. For a local government to be considered reliable,
it
should guarantee minimum conditions of reliability for all key
processes and services.
To achieve this, it is advisable that the local
government clearly identify the management, core, operational, and
support processes
that, together, make it reliable (addressed by Annex A of IWA 4). A
diagnostic tool for local governments to evaluate the scope and
maturity of their processes and services is provided in Annex B.
4. New ISO 9000:2005 Edition
|
ISO
9000:2000, the standard that
defines the vocabulary (and describes the fundamentals) of quality
management systems, has been replaced with a new edition: ISO
9000:2005.
ISO 9000:2005, Quality management
systems - Fundamentals and vocabulary,
introduces no changes to the descriptions of the fundamentals of
quality management systems. However, some definitions have been added,
and
explanatory notes expanded or added, to take into account more recent
documents in the ISO 9000 family.
Examples of new definitions include: technical expert, requirement,
competence, contract, auditor, audit team, audit plan, and audit scope.
The primary reason for
this new edition is to provide a single, unambiguous meaning of key
words used in various management systems standards, in particular, ISO
9001:2000, Quality management systems – Requirements and ISO
19011:2002, Guidelines for quality and/or environmental
management
systems auditing. To reflect these changes, a number of the
diagrams appearing in ISO 9000 have been enhanced in the 2005 version.
ISO 9000:2005 will be useful for all users of
standards in the ISO 9000 family, and especially for:
- Suppliers, customers,
and regulators - providing them with a
common understanding of the terminology of quality management,
- People
who assess QMS, or audit them for conformity to ISO 9001:2000 – such as
internal auditors, external auditors of certification bodies, and
regulators, and
- Providers of
consultancy or training on QMS.
ISO 9000:2005, Quality management systems – Fundamentals and vocabulary, ISO
9000:2005 is available through ANSI
(and soon through ASQ).
|
5. Class Schedule: November, 2005 - January, 2006
|
To enroll
in these
public classes, you can click on the course title, go to Class
Schedule at our web site, or call us at 800-404-7585.
Classes
taught by Larry Whittington are shown in yellow.
ISO
9001:2000 Lead
Auditor (RABQSA Certified) - BSI Management Systems
Initial
course version developed by Larry Whittington
| November |
December |
January |
| 07-11
Detroit, MI |
05-09
Chicago, IL |
09-13 San Jose, CA |
| 14-18
Roanoke, VA |
12-16
Atlanta, GA |
23-27 Reston, VA |
| 14-18 San
Jose, CA |
12-16 Las
Vegas, NV |
30-03 Houston, TX |
| 28-02
Reston, VA |
- - |
- - |
ISO
9001:2000
Internal Auditor (RABQSA Certified) - BSI
Management Systems
Initial course version developed by an Associate at Whittington & Associates
| November |
December |
January |
| 15-17
Chicago, IL |
06-08
Reston, VA |
18-20 San Jose, CA |
| 29-01
Atlanta, GA |
- - |
24-26 Atlanta, GA |
Implementing
ISO
9001:2000
Course
developed by Larry Whittington
| November |
December |
January |
| 17-18 Atlanta, GA |
- - |
10-11 Chicago, IL |
| 29-30 San Diego, CA |
- - |
- - |
Understanding
ISO
9001:2000
| November December |
January |
| 28 San
Diego, CA - - |
09 Chicago, IL |
Understanding
ISO
9001:2000 Requirements (Atlanta Only - $295)
Course
developed by Larry
Whittington
| November |
February |
| 14 Atlanta, GA |
06 Atlanta, GA |
Quality
System
Documentation (ISO 9001:2000)
Course
developed by Larry
Whittington
| November |
December |
January |
| 15-16 Atlanta, GA |
01-02 San
Diego, CA |
12-13 Chicago, IL |
ISO
17799 - Understanding an Information Security Management System
| December |
January
|
February |
| 19-20 Reston, VA |
- - |
07-08 Atlanta, GA |
- -
|
- -
|
22-23 Newark, NJ |
BS
7799-2 - Information Security Management System Auditor
| December |
March |
| 05-09 San
Jose, CA |
06-10 Seattle, WA |
ISO
17799 - Information Security Management System Implementation
| November |
December |
February |
| 14-18 Las
Vegas, NV |
05-09 Atlanta, GA |
06-10 Reston, VA |
| - - |
12-16 Orlando, FL |
|
Understanding
ISO 14001:2004
January
|
February
|
March |
30
Atlanta, GA
|
- -
|
27 San Jose, CA |
Implementing
an Environmental Management System
| December |
January |
March |
| 13-14 San
Diego, CA |
17-18 Reston, VA |
28-29 San Jose, CA |
- -
|
31-01 Atlanta, GA
|
- - |
ISO
14001:2004
Internal Auditor
| November |
January |
February |
| 21-22 Reston, VA |
19-20 Reston, VA |
20-21 Atlanta, GA |
ISO
14001:2004 Lead Auditor
| December |
January |
February |
| 05-09 Orlando, FL |
23-27 San
Jose, CA |
13-17 Houston, TX |
On-site
Courses
The above
public
courses can
be offered on-site at your facility. In addition, we offer these
on-site courses:
- ISO 9001:2000
Auditor Update - The
Process
Approach (1 Day) - Course developed by Larry
Whittington
- Understanding
ISO/TS 16949:2002
Requirements (1 Day)
- Course developed by Larry
Whittington
- Internal
Quality
Auditing (2 Days) - Course developed by Larry
Whittington (based on ISO 19011)
- AS9100B:
Requirements Beyond ISO 9001:2000 (1 Day) - Course developed by Larry
Whittington
To arrange
an
economical
on-site class, please call us at 800-404-7585.
© 2000-2005 Whittington & Associates, LLC. All rights reserved.
You may copy this e-Newsletter provided you copy it completely, do not change it, and include this copyright notice.
|
