6th Edition PMBOK® Guide–Process 8.3 Control Quality: Tools and Techniques | 4squareviews

This post lists the tools and techniques that are used in this process.   It is a process in the monitoring and controlling group, and its main purpose is monitoring and controlling the quality of the results of the project, namely, the deliverables to make sure they are correct in the sense that they conform with the requirements set out with the input of the stakeholders at the beginning of the project.   That is why it is called quality control.  The review of the quality of the processes on the project is what is referred to quality assurance–it is taken care of in the previous process 8.2 Manage Quality.

Here are the tools and techniques of this process.

8.3.2.1 Data Gathering

  • Checklists–these show the standard operating procedure for quality control activities to make sure they are performed in a uniform manner.   In that way, if there is a defect that shows up, it cannot be traced to a variance in the way in which the quality control activity was done, because the checklist insures that it is done the same way every time.
  • Check sheets–for gathering data on attributes and any defects that are found, check sheets are invaluable.   They tell for example, the number of defects, the specific type of defects, and even the date the defects occurred.   So if a number of defects start occurring, check sheets can help pinpoint their source.
  • Statistical sampling–this is where you take a part of a population of components being produced by a process.   This sample is then measured and compared to quality metrics in order to verify quality.  The frequency of such sampling and the size of the sample (is only one part taken at a time for measuring or are several taken?) are determined ahead of time in the process 8.1 Plan Quality Management.
  • Questionnaires and surveys–after the product is released to the customer, questionnaires and surveys can help gather data about customer satisfaction with the deployment of the product or service.

8.3.2.2 Data Analysis

  • Performance reviews–this is a measure of the performance quality on the project by measuring, comparing, and analyzing any variances seen between the actual results and the quality metrics set up during the Plan Quality Measurement process.
  • Root cause analysis (RCA)–this is used to identify the source of defects.

8.3.2.3 Inspection

This is the physical examination of the work product to determine if its conforms to documented standards.   It can be the results of a single activity, or at the end of the product it can be an inspection of the final product of the project.   It is important that the quality of the final product be verified internally before it gets sent to the next process which is the process 5.5 Validate Scope where the quality and scope of the final product are validated externally by the customer.

8.3.2.4 Testing/Product Evaluations

This is an organized investigation conducted to provide objective information about the quality of the product or service.   It is tested in accordance with the project requirements.   Tests can be done throughout the project on different components of the project, and at the end of the project on the final deliverables.

8.3.2.5 Data Representation

  • Cause-and-effect diagrams–Also known as Ishikawa (for the Japanese person who developed them) or fishbone diagrams, based on the shape of the diagram.  The problem (or “special variation” in quality management terms) is placed at the “head” of the fishbone and the various “bones” that come off of the “spine” of the fishbone represent some possible source of the problem.
  • Control charts–these are used to see whether a process is stable, that is, has predictable performance and will always produce the same outcome.   There is a

    control limit

     that is established exists so that the process stays within the specification limit.    The analogy that comes to mind is that of the lane marker on a highway and the guard rail at the side of the road.    The guard rail is like the specification limit, in that if you go outside that limit, you are definitely “off road” and this is definitely a situation to avoid.    But in order to stay within these outer limits, the control limits in this case are like the lane markers, assuming that there is some sort of shoulder between the lane marker and the guard rail.    If you can steer your car so that you are within the lane markers (control limits), you will never have to worry about hitting the guard rails (specification limits).   For more information on control charts, see my blog post I did for the 5th Edition PMBOK Guide

5th Edition PMBOK Guide–Chapter 8: Control Charts

  • Histograms–they are used to demonstrate the number of defects by source or by component, or sometimes by date or occurrence.   They are useful in figuring out the largest sources of variation, because these are usually prioritized as being the first problems that need to be solved in order to reduce the number of defects.
  • Scatter diagrams–the planned performance can be plotted on one axis and the actual performance on the second axis.   Are they correlating, or is the actual performance show a variation from the planned performance?

8.3.2.6  Meetings

The various quality control processes can be done separately by team members, but certain decisions related to quality require a meeting of the project team.

  • Approve change requests review–if there is a Change Request that is an output of this process, and it is approved in the process 4.6 Perform Integrated Change Control, then that approved change must be incorporated into the process and 

    verified

    through testing or inspection to make sure it was implemented as approved.

  • Retrospectives/lessons learned–the team should periodically hold a lessons learned meeting, sometimes called a retrospective in agile environments, in order to find out
    • what were the successful elements in the project or phase that occurred in the last reporting cycle
    • what elements could be improved in the next reporting cycle (to improve the ongoing project)
    • what to add to the organization process assets (for use on other future projects)

Now let’s turn our attention to the outputs of this process, which I will cover in the next post.

Advertisement

Share this:

  • More

Like this:

Like

Loading…