I am bidding on a government contract (my first) and there is a section requesting that I provide a high-level outline of a quality control plan that would ensure that the end product is ISO-9001 compliant.

I don't know much about ISO 9001 so I am certainly doing my own homework and research on this, but thought I would ask the question here in case there happens to be someone very knowledgeable in the area who could provide 5-10 broad bullet points on which I should focus.

  • "avoid asking subjective questions where … every answer is equally valid..." (help center)
    – gnat
    Commented Jul 3, 2014 at 4:03
  • 3
    @gnat--There are cases in which software professionals need to ask a question like this and in which the resulting answer will help others. If this isn't the appropriate SE forum, then what is? Perhaps you could offer a better way to ask the question rather than to simply cite text from the help center. Commented Jul 3, 2014 at 15:20
  • @gnat--here is your most popular answer: programmers.stackexchange.com/questions/154733/… The question is very subjective. Can you please help me understand the differnce? Commented Jul 3, 2014 at 15:23
  • I'm not explicitly familiar with ISO9001, but I am very familiar with AS9100 (ISO9001 with additions for aerospace) and AS9115 (additions to AS9100 for aerospace software). By "quality control plan", are you referring to the quality management system or a specific document mentioned in ISO9001?
    – Thomas Owens
    Commented Jul 3, 2014 at 16:14

2 Answers 2


I'm going to preface my answer with the fact that my expertise is in AS9100 and AS9115. AS9100 is the aerospace industry standard that incorporates additional aerospace industry requirements with ISO 9001. The revision of AS9100 that I'm familiar with is AS9100C, which corresponds to ISO9001:2008. There may be minor differences between the two.

The first thing to realize is that a document like ISO9001 or AS9100 is designed for an organization to ensure that their process accounts for things that are important to their customers. It, by itself, is not a process. It's up to an organization to determine exactly how to meet the requirements, based on the organizational environment, objectives, the product, the size of the organization, and more. The emphasis is on considering the value added to customers by process steps, obtaining an effective process and continually improving processes using objective measures, and ultimately understanding customer requirements and meeting them throughout the product life cycle.

At the highest level, the goal is to define organizational processes, how those processes interact, ensure that the processes have the resources and information needed to function, how to measure and control each process, and how to implement actions to correct or prevent problems in the process.

In AS9100, the actual requirements are found in sections 4 through 8. Looking at the outline of ISO9001 on Wikipedia, it looks like the section headers are the same - Quality Management System, Management Responsibility, Resource Management, Product Realization, and Measurement, Analysis and Improvement.

Each section and subsection is a collection of statements, usually "shall" statements. In essence, this document is a requirements specification for an organization to follow.

For example, section 7.3.4 Design and Development Review:

At suitable stages, systematic reviews of design and development shall be performed in accordance with planned arrangements (see 7.3.1)

a) to evaluate the ability of the results of design and development to meet requirements

b) to identify any problems and propose necessary actions

Participants in such reviews shall include representatives of functions concerned with the design and development stage(s) being reviewed. Records of the results of the reviews and any necessary actions shall be maintained (see 4.2.4).

What this says is that you have planned and well-defined reviews during product development. Often, this takes the form of System Requirements Review, Preliminary Design Review, Critical Design Review, and Test Readiness Review, in addition to various peer reviews that are planned and executed during development. These reviews are to ensure that the current work products (derived requirements specifications, models, design documents, source code, test code, etc) are meeting requirements.

This ties to Section 7.3.1 Design and Development Planning, which says that you plan the stages of design and development, ensure that reviews and V&V activities occur at every stage of development and are appropriate given the inputs and outputs, and that you identify who is responsible and has authority over design and development activities. It also ties to 4.2.4 Control of Records which says that you have documented procedures for identifying, storing, protecting, retrieving, retaining, and dispositioning records and maintain objective evidence of this happening.

Depending on your organization, there may be one or more documents that define the organizational process. In larger organizations, there are often several documents controlled by different people who are knowledgeable in that area. For example, the documents that define the processes for configuration management are controlled by the configuration management team, while the documents for record management are controlled by Document Control, and the engineering documents are controlled by various engineers (often engineering management). However, in a smaller organization, you may only have one or a small handful of documents.

In order to fully understand and implement ISO9001, you'll need to have a copy of the standard to read and follow. Reading it pretty much tells you everything that you'll need to achieve with your process documentation. Once your documentation is in place and you've been executing to it for long enough to begin to produce objective evidence, you can seek an audit and your organization will become compliant to ISO9001.


In doing my own research on the topic, I found this document published by ISO. It covers eight quality management principles:

  1. Customer Focus
  2. Leadership
  3. Involvement of people
  4. Process approach
  5. System approach to management
  6. Continual improvement
  7. Factual approach to decision making
  8. Mutually beneficial supplier relationships

The document itself goes into detail about what each tenent means with regards to quality and it's not too hard to apply that to the process of producing a piece of software.


Not the answer you're looking for? Browse other questions tagged or ask your own question.