If you think from a real World perspective, Control Quality appears to be a very important process that needs to be as comprehensive as possible. Several Tools and Techniques are applied during the course of this process. You have already studied some of them like the ones from the seven basic quality tools – Checksheets, Histogram, Cause and Effect Diagram, Control Charts and Scatter Diagrams but there are others that will be covered in this article.
Performance Reviews is how the project team evaluates the current measurements of the product quality against expectations.
For example, in a software development project, let’s say the quality expectation was that the code should not contain more than 10 non-critical bugs per 10,000 lines of code. Upon the performance review analysis, it was found that there were actually more than 10 non-critical bugs and thus this quality criteria is not met.
Note that Performance Review is not same as Audit.
Root Cause Analysis
Also known as RCA, Root Cause Analysis is pretty much what it sounds like. This is where the project team tries to find out the reason or the root cause of the occurrence of defects.
For example, in the software development project above, if you take a bug and try to find out the root cause rather than simply fixing the bug, you may discover that the same root cause is responsible for some other bugs as well. Thus fixing this root cause would be more efficient than individually fixing bugs.
One of the techniques used in finding the root cause is asking “Why” multiple times. This is also known as Five Whys technique.
Below is a snip from Wikipedia about Five Whys,
Five whys (or 5 whys) is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question “Why?”. Each answer forms the basis of the next question.
Lean Thinker Taichi Ohno popularized this idea of Five Whys. It was part of the Toyota Production System.
Inspection is very different from Performance Review. Inspection is centered around the standards, either internal (defined at organization level) or external (defined by the government) while Performance Review is the product performance you are trying to achieve. Inspection is applicable to interim deliverables of the project as well. The sooner you find a defect the easier and cheaper it is to fix.
Inspection plays an important role in Agile. Many agile practices focus on the creator of the deliverable inspecting their own work as they build as well as using peer reviews before calling the declaring the deliverable as done.
Testing / Product Evaluations
To understand Testing or Product Evaluations you should refer to Test Planning. Making use of the test cases that were planned in the Plan Quality Management process, it is now time to execute them on the project deliverables. The result of executing these test cases gives you the deliverables that conform to quality and the ones that don’t. Wherever a deliverable doesn’t conform to quality it is a defect. The project team needs to review all such defects to determine whether or not they need to be fixed. Note that making these fixes also impact the other project constraints and planned work.
Check more articles on Quality Management