Sunday, August 7, 2011

Quality Assurance and Quality Control

I have noticed that many professionals, and even very accomplished managers, tend to lump 'quality assurance and quality control' together as if they occur together and mean the same. In reality, QA and QC are two as different a concept as can be! I hope I will be able to dispel a bit of that confusion.

Every organization seeks to achieve higher quality in their work, whether it is a product or a service they offer. These organizations seek to maximize the ability to meet its goals with a minimum of mistakes, inefficiency, and waste. And why not, this endeavor has many long-term benefits: reduction of costs, a delighted client, good future business prospects, etc. The process to achieve this continuous improvement has several steps and is, however, usually mistakenly termed QAQC.

QA (Quality Assurance) is a set of activities (e.g. a quality audit) that are aimed to ensure that the processes followed in the organization are actually happening properly and meeting the objectives. For example, a document control audit to check if all correspondence is being filed properly at the right place for easy access and future retrieval is a QA exercise. QA also works to develop processes to better handle issues. For example, when a problem has been identified in the project execution, say drawings are being issued for construction without a mechanical engineer's review, the QA manager will then modify the project execution process to include a step that includes a review of drawings by a mechanical engineer. So, the bottom line definition is that QA is that it is process focused, that is, development of methodology and standards. The goal of QA is to find a problem in the processes and make sure the checks are implemented at the right level of detail.

QC (Quality Control), on the other hand, is the set of activities that evaluate the product. So, in the above mentioned example, the mechanical engineer checking the drawings is a QC activity. This activity is focused on finding defects in particular deliverables. In a production line, inspection and testing of a sample would be QC. Here the task is to find if the deliverable / product meets the stated level of detail and specification requirements. To stress the point - this is a fault finding activity.

Now, the confusion arises, I think, is because organizations are not sure about assigning responsibility for these two activities. More often than not, these activities are assigned to the same individual - the project manager. This is not the right approach, and I have seen many cases in my career where the final quality of the project suffers due to this.

In my opinion, the project manager should be only responsible for QA and not for QC. Of course, it also depends on scope of projects. For a $5M or less construction projects, the resources are usually strapped and the PM is forced to do both, and usually manages to do a good job. But, in projects, especially $50M+ construction projects, it will be near impossible for a PM to do both QA and QC and produce good results. There are too many details to consider and the focus shifts away from QA thereby compromising the project. For such projects, the PM should focus on QA and QA only. He/She should have the lead engineer or a third technically savvy engineer deal with the QC part of the project. When setting up the project the PM will need to put sufficient QC check points in his/her project execution strategy to ensure the 'fault finding' is adequately happening on the project and the quality of the final deliverables going out of the door meets (or exceeds) the quality standards promised to the client. His/her job is to constantly monitor the operations to make sure the QC checks and the recification is happening. On projects greater than $150M, there should be dedicated QA manager.

3 comments:

  1. From theoretical learning, yes QA/QC are taught as if they are sisiters. In practice, as you explained above, they are two different responsibility.

    The QC Office I affilicated briefly was simply following what QA told QC to do. Although it has changed since I started, and QC decided to have our own position - rather than just following QA's instructions. It is some of changes I brought into the organization.

    ReplyDelete
  2. There are actually 3 primary steps in the process. first is the quality plan, then control, then assurance. Since the scope and depth of the team and stakeholders for our projects are relatively small, a very simple example of the quality process can be:
    1: quality control planning, which can consist of a simple form that identifies the various deliverables, and blanks for the reviewer, date, comments, etc.
    2: at each deliverable stage, the quality control consists of the reviewer going over the deliverable, checking for errors, constructibility, details, etc. At the conclusion they are to fill out the form as directed by the quality control plan.
    3: the quality assurance is the review, by the pm, to assure that the completion of the qc form is being completed for each deliverable completely. This is also were the pm can evaluate and change the plan if it is not having the desired effect.

    I agree that the qa/qc process is not well understood in terms of the multi step process it is intended, at least for smaller projects. I'd guess that the number of engineering projects relative to value is almost exponential. For every 1,000 $100k projects, there are 100 $1m projects, 10 $10m projects and 1 $100m projects. For smaller projects, the level of detail is such that the quality contol process can be managed as described above, with a simple form. Too many times there is no documentation at all of the quality control process.

    ReplyDelete
  3. @ Russ: Yes, the size of the project has a lot to do with how the QA and QC process is implemented. The job of the PM is to set up the QC forms and processes and maintain it. He/She should also hold the QC reviewers accountable for the review and preferably the QC reviewers should be distant from the project so that they can provide an objective and independent review.

    @ Yoshimi: Nice to hear that you have been able to make some changes in the organization. I will be interested to hear your stories / lessons learned.

    ReplyDelete