Configuration Audits

The configuration audit is an activity that is conducted to determine that a system or item meets it functional requirements and has been built in accordance with its blueprints, source code, or other technical documents. In plain English, audits are done to prove that (1) the thing works the way it should and (2) the builder's factory production system has reliable quality control, especially as it pertains to technical documentation (the documents that depict, describe, and define the thing).

The nature of the particular system or item determines the extent to which its hardware and software are reviewed for correlation with test results and design documentation. Generally, developed items are more thoroughly audited than “commercial off the shelf” (COTS) items. However, the bottom line of the audits is that they (1) validate that the system meets its functional requirements and (2) establish that the system’s technical documentation is accurate and well maintained. There are three basic categories of audits: functional, physical, and privately developed item.

Functional Configuration Audit (FCA). The FCA is a review of a system's or item’s test, analysis, inspection, or demonstration records to validate that it meets its performance and interface/interoperability contract requirements. That is, the FCA verifies that the system's or item's required functional, physical, and interoperability characteristics meet the specified contractual requirements. A functional audit is a prerequisite to the performance of a physical audit.

Physical Configuration Audit (PCA). A PCA involves the matching of a functionally successful "as built" system or item with its proposed product configuration identification (PCI), (the “PCI” is the set of documents that will eventually be used for production, acceptance, and modification management) Successful completion of a PCA will provide reasonable assurance that the PCI is (1) complete, (2) matches the system or item, and (3) is suitable for full-scale production, field operations, maintenance, and life-cycle modifications.

Privately Developed Item Audits. Configuration audits on privately developed items, i.e., those not developed with Government funds, are usually either not audited or in some cases, a functional audit may be done to assure that its functional characteristics satisfy Government requirements. The audit is usually limited to an examination of test data provided by the contractor.

Why bother with these audits? The question is often asked why these audits should be done; i.e., what, if any, value do these audits bring to a system acquisition program? I have participated and been the lead for many audits and have found that they can be vitally important for the success of a system acquisition. These audits are often done before a system is actually shipped to the field for use. In some cases, these audits uncover safety hazards and other potentially serious problems that were heretofore unrecognized. In some cases, an audit can uncover that many contractually specified requirements were never subjected to any test, and thus, no one knows if the system can actually meet those requirements. In other cases, the audits can uncover that approved product changes were never added to the blueprints and thus were not added to the physical system itself.

These audits are also extremely valuable in that they give a decision maker confidence that a program can proceed to full-scale production. That is, knowing that a system has been thoroughly audited and has been verified to perform as expected, and further knowing that all the vital technical documentation that will be used to build and sustain the system is accurate and is well maintained, provides the decision maker with confidence in granting permission to proceed with full-scale production and deployment of the system.

How to Prepare for an Audit. If an audit is a contract requirement, then you can usually follow these steps and be reasonably safe:

  1. Check Section C of the contract to see which documents are binding on the CLINS to be audited. For example,

    CLIN 0001, Radio PME: "Radio System Specification 0001C"

  2. Check the SOW to verify the audit requirements.
  3. Use Microsoft Excel or other spreadsheet application to create a matrix which matches requirements with verification methods. For example: Audit Checklist
  4. Coordinate the audit details and logistics with the contractor (i.e., time, date, location, participants, scope, etc.)
  5. Conduct the audit and document (For example Sample Audit Document & Audit Template) any deviations or problem areas.
  6. Take follow-up action to resolve any deviations or problem areas.

Back to Homepage