Quality of Procured Items
Often the quality requirements for items that are procured from suppliers are set by
industry standards, in which case the main criterion for choosing a supplier is price. When a
procurement officer receives instructions to buy a batch of standard items such as bolts, she
would obtain quotes from a number of suppliers and pick the least expensive; when the batch
arrives, an inspector checks the bolts to determine whether they are acceptable. But in the
case of a subsystem or item to be newly developed, there likely is no industry standard. In that
case, to assure the item meets specifications, the contractor ordering the item to be developed
should be involved in planning the quality assurance and quality control of the work of the
supplier. Even for procured items that are standard, better than just selecting the cheapest
supplier is for the contractor to develop a mutually beneficial long-term relationship with a
supplier that has the proven capability and is willing to meet the contractor ’ s requirements.
The contractor and the supplier work together as partners and share responsibility for each
other ’ s success. Establishing this kind of relationship is not always easy, especially when the
supplier is much larger than the contactor or does not value the relationship or consider the
contracted work high priority. Contractors often invest heavily to make sure they get the
appropriate-quality subsystems and components from their suppliers. It is common for a
contractor to have a special vendor quality section within its procurement division to oversee
quality assurance of all procured items—including their development and manufacture or
construction. The role of the vendor quality section is to assist in selection of suppliers, monitor
suppliers ’ processes to ensure quality, and perform acceptance tests and inspection of
purchased items. Additional responsibilities are described in the example.
Configuration Management
During the design of a system, vast amounts of data and information are generated for
use in the design process and later for manufacturing (or construction), maintenance, and
support. The design can involve many hundreds or even thousands of documents
(specifications, schematics, drawings, etc.), each likely to be modified in some way during the
project. Keeping track of all the changes and knowing the most current version of every item
can be difficult. Thus, any project aimed at delivering a technical product should include
provision to keep up with and control all this information; such is the purpose of configuration
management . Configuration management represents policies and procedures for monitoring
and tracking design information and changes, and ensuring that everyone involved with the
project and, later on, the operation of the end-item has the most current information possible.
Policies and procedures that form the configuration management system for a project should
be included as a section in the quality plan. As with all procedures, the best configuration
management system is whatever enables the desired level of control and is the simplest to
implement. Two aspects of configuration management are configuration identification and
configuration control.
Any modifications, waivers, or deviations to a CI are recorded so that all CI
documentation reflects the “ as-built ” status of the system. In the case of an end-item such as
a building, ship, or other one-of-a-kind system that becomes operational, the “ as-built ”
specification will later be used for its operation and maintenance. Where multiple units are
produced (such as cars, airplanes, appliances) and modifications and improvements are
introduced over time, the specific configuration for each individually produced unit must be
known, which requires that each specific CI in the product must be traceable to its specific “
as-built ” specifications. This is necessary, so that, for example, the correct spare parts, training,
and operating manuals can be supplied, and problems can be traced and analyzed in the event
of accidents, customer complaints, or claims regarding product liability. This concept of “
traceability ” was introduced in Chapter 4 and is illustrated in the following example.
