6th Edition PMBOK® Guide–Process 8.2 Manage Quality: Outputs


This post discusses the outputs of the Manage Quality process, which focuses on quality assurance, that is, making sure that the quality-related processes on the project are done correctly, as opposed to the Control Quality process, which makes sure that the results of the project are done correctly.

8.2.3 Manage Quality Outputs

8.2.3.1 Quality Reports

The information contained in the quality reports is to used by the project team in order to take corrective actions, either to the processes themselves or to the product.  The information may include the following:

  • Quality management issues escalated by the project team
  • Recommendations for improvements to the processes of the project or to the product itself to reduce the probability of potential defects (preventive actions)
  • Recommendations for corrective actions to detect defects (inspection, testing, etc.) or to repair defects before they go to the customer (rework/scrap).
  • Summary of findings from the Control Quality process.

These quality reports are then distributed to all stakeholders who are interested in quality and/or those who have influence on quality.

8.2.3.2 Test and Evaluation Documents

These are the documents which are to be used in the next process 8.3 Control Quality.  They may include:

  • Checklists (to make sure that all processes are done correctly)
  • Check sheets (to document any results that are nonconforming to the quality standards)
  • Requirements traceability matrices (to trace quality metrics to the specific requirements they measure)

8.2.3.3 Change Requests

As a result of this process, there may be recommendations for changes to the following:

  • Project management plan (particularly the quality management plan or any of the baselines for scope, schedule, and cost–see paragraph 8.2.3.4 below)
  • Project documents (particularly the issue log, lessons learned register, or the risk register–see paragraph 8.2.3.5 below)
  • Project or product management processes (as a result of quality improvement activities)

These are then made inputs to process 4.6 Perform Integrated Change Control.

8.2.3.4 Project Management Plan Updates

  • Quality management plan–sometimes rather than conforming the results to the plan, you may find that the plan was unrealistic, in which case you may need to modified the agreed-upon approach to managing quality based on the actual results.
  • Scope baseline–specific quality management activities may change the deliverables (found in the project scope statement) or to the work packages (found in the WBS)
  • Schedule baseline–specific quality management activities may impact the schedule, in which case the schedule baseline may need to be changed
  • Cost baseline–specific quality management activities may impact the budget, in which case the cost baseline may need to be changed.

8.2.3.5 Project Documents Updates

  • Issue log–as a result of the audits done as part of the quality assurance process, new issues may be raised which are recorded in the issue log.
  • Lessons learned register–information is added to the register on
    • challenges encountered during this quality management process and how they could have been avoided or
    • approaches that worked well for managing quality
  • Risk register–information on new risks identified during this process are recorded in the risk register to be managed using the risk management processes (covered in chapter 11)

The next post covers the inputs to the next process 8.3 Control Quality.

 

 

Advertisements

6th Edition PMBOK® Guide–Process 8.2 Manage Quality: Tools and Techniques


There are a LOT of tools and techniques for this process.   Here are the quality objectives related to this process

  • Implement specific design guidelines (see paragraph 8.2.2.6 on “Design for X”)
  • Implement quality assurance tools and techniques (see paragraph 8.2.2.5 on quality audits, paragraph 8.2.2.2 on Data Analysis techniques such as failure analysis)
  • Improve the efficiency and effectiveness of processes and activities to achieve better results (see paragraph 8.2.2.8 on Quality Improvement Methods)
  • Confirm that the quality processes are being implemented and that their use achieves the quality objectives (see paragraphs 8.2.2.1, 8.2.2.2, and 8.2.2.4 on data gathering, analysis, and representation techniques)

There are also some “generic” tools and techniques such as Decision Making (paragraph 8.2.2.3) and Problem Solving (paragraph 8.2.2.7) that are more general and are used with other processes in other knowledge areas.

8.2.2 Manage Quality:  Tools and Techniques

8.2.2.1 Data Gathering

  • Quality checklists–these verify that a set of required steps have been performed or to see if a list of requirements has been satisfied.   These checklists are usually based on the acceptance criteria included in the scope baseline.

8.2.2.2 Data Analysis

  • Alternatives analysis–used to identify various options or approaches with respect to quality and then to select which are most appropriate for use on this project
  • Document analysis–this analyzes the following documents to point out processes that may be out of control
    • Quality reports
    • Test reports
    • Performance reports
    • Variance analysis
  • Process analysis–identifies opportunities for process improvements (see paragraph 8.2.2.8 Quality Improvement Methods) by examining
    • the inputs to a process to see if there are constraints they impose on the process
    • non-value-added activities that occur during that process
    • the outputs to a process to see if they can be used to identify problems
  • Root cause analysis–an analytical technique used to determine the basic underlying reason that causes a variance, defect, or risk.   It can also identify the root causes of a problem on the project (sometimes referred to as an “issue”).

8.2.2.3 Decision Making

If there are alternatives being discussed (see “alternatives analysis” in paragraph 8.2.2.2 on Data Analysis techniques), then there needs to be a decision-making process put into place to decide among those alternatives.   Having criteria in place is important so that the various alternatives can be evaluating to narrow down the alternatives that are the most viable for the project.   if necessary, the final decision can be made by votes taken at a meeting of project team members and experts.

8.2.2.4 Data Representation

Here are some techniques used to represent data–they are used in conjunction with the data analysis techniques listed in paragraph 8.2.2.2.

  • Affinity diagrams–these organize potential causes of defects into groups showing areas that should be focused on the most.   For more information on this techique, see the post I did for the 5th Edition PMBOK just on this technique alone.

https://4squareviews.com/2013/05/31/5th-edition-pmbok-guide-chapter-8-affinity-diagrams/

  • Cause-and-effect diagrams–these are sometimes known as fishbone diagrams, why-why diagrams, or Ishikawa diagrams, and are used to identify the root cause of the the problem being stated.  This kind of diagram breaks down the potential causes of the problem statement into discrete branches.  See Figure 8-9 on p. 294 of the PMBOK Guide for an example.
  • Flowcharts–used to show a series of steps that lead to a defect and are used in conjunction with process analysis (see paragraph 8.2.2.2 on Data Analysis techniques) to identify the processes that are causing the defect so that those processes can be improved using quality improvement methods (see paragraph 8.2.2.8)..
  • Histograms–these are graphical representations of historical data.   Used in managing quality, they can show the number of defects per deliverable, for example.   Then the deliverables that have the most defects can be identified and worked on as a priority.
  • Matrix diagrams–these show the strength of relationships among factors, causes, and objectives that exist between the rows and columns that form the matrix.    For an example of a quality tool called House of Quality that uses matrix diagrams, see my post below:

https://4squareviews.com/2012/12/11/six-sigma-green-belt-management-tool-5-matrix-diagrams/

  • Scatter diagrams–this shows the relationship between two variables.   If there is no relationship between the two variables, there will be no discernible pattern between the data points in the diagram.   If there is a positive correlation, there will be an upward-sloping pattern to the data points; if there is a negative correlation, there will be a downward-sloping pattern.   Do not confuse a negative correlation with no correlation at all!   If X increases while Y increases, this is a positive correlation because the tendency is the same with both variables.   However, if X decreases while Y increases, this is a negative correlation because the tendency is the opposite between the two variables.   If there is NO correlation, then as X increases, Y may be all over the place rather than having any particular pattern.

8.2.2.5 Audits

An audit is a structured, independent process used to determine if project activities comply with organizational and project policies, processes, and procedures.  It is structured because it is done based on some sort of organized format such as a checklist (see paragraph on 8.2.2.1 Checklists).   It is independent because it is not being done by the same people who are responsible for doing the project activities.   This is why a quality audit is usually conducted by a team external to the project.   Here are the types of things that a quality audit will look for:

  • Identification of good and best practices being implemented, and sharing of good practices being done in similar projects in the organization
  • Identification of nonconformity, gaps and shortcomings between activities as they are being done on the project and how they are supposed to be done based on project procedures set forth in the Project Management Plan.
  • Offering assistance to improve the implementation of processes (see paragraph 8.2.2.8 Quality Improvement Methods)

Besides looking at project activities, quality audits can also confirm that approved change requests have been implemented correctly.

8.2.2.6 Design For X (sometimes abbreviated as DfX)

This is a set of technical guidelines that may be applied during the design of a product for the optimization of a specific aspect of the design.   hat is the “X” in DfX, and it can refer to reliability, safety, usability, or any other feature of the design that you want to focus on. This is a trending topic in quality in PMI, which is designing in quality so that defects don’t get produced in the first place, rather than trying to reduce defects through inspection later on.

8.2.2.7 Problem Solving

Quality assurance and quality improvement requires problem solving, where you have to find the cause of the defect (the problem), generate possible solutions, choose one of those solutions, and then implement it.   Finally, you have to verify that the solution is effective.

8.2.2.8 Quality Improvement Methods

Quality improvements can be based on recommendations from quality control processes (i.e., as an output to process 8.3 Control Quality), or they can be uncovered during this process 8.2 Manage Quality.   No matter where these suggestions for quality improvement come from, methods such as Six Sigma can be used to implement them.

The next post will cover the outputs to this process.

 

 

6th Edition PMBOK® Guide–Process 8.2 Manage Quality: Inputs


The quality management processes that were planned during the process 8.1 Plan Quality Management are implemented during the executing process 8.2 Manage Quality.   There are quality assurance activities which manage the correctness of the process, and quality control activities which manage the correctness of the results.   The process 8.2 Manage Quality process covers quality assurance, whereas quality control comes into play in process 8.3 Control Quality.

Here are the inputs of this process:

8.2.1 Manage Quality:  Inputs

8.2.1.1  Project Management Plan

The component of the project management plan that is an input for this process is the quality management plan, which is the output of process 8.1 Plan Quality Management.   In the quality management plan, you find a description of:

  • the acceptable level of project and product quality
  • how to ensure this level of quality in the deliverables and processes
  • what to do with nonconforming products, including what corrective actions to implement

8.2.1.2  Project Documents

The projects documents that may be inputs to this process include the following (these are listed by knowledge area)

Integration Knowledge Area

  • Lessons learned register–if lessons are learned during the process 8.2 Manage Quality which improve the efficiency and effectiveness of managing quality, then the register is updated with these lessons so they can be applied to later phases in the project.

Quality Knowledge Area

  • Quality metrics–created as an output of process 8.1 Plan Quality Management, quality metrics are the basis for testing the deliverables of a project
  • Quality control measurements–an output of process 8.3 Control Quality, quality control measurements, which measure the quality of the results from the project, can be used to evaluate the quality of the processes, particularly those that create quality control measurements.

Risk Knowledge Area

  • Risk report–created as an output of 11.1 Identify Risks, this identifies sources of overall project risk, and can be used to identify those elements of risk exposure which can impact the quality objectives of a project.

8.2.1.3 Organizational Process Assets

Here are the organizational process assets that may be inputs to this process.

  • The organizational quality management system that includes policies, procedures and guidelines which respect to qualitiy (and which should be incorporated into the Qualitiy Management Plan).
  • Quality templates such as check sheets, traceability matrix, test plans and documents that will be used with tools and techniques of this process
  • Lessons learned repository with information on quality assurance activities that were done on previous similar projects

With these inputs, let’s look at the tools and techniques of this process in the next post.

 

 

 

6th Edition PMBOK® Guide–Process 8.1 Plan Quality Management: Outputs


The main output of the process 8.1 Plan Quality Management is the Quality Management Plan itself, but there are also updates to the project management plan as a whole and to project documents.   The production of a management plan related to a particular knowledge area and updates to the overall management plan are outputs typical for any planning process, but for quality management, there is a specific output unique to that knowledge area, namely, quality metrics.

Here are the outputs of the Plan Quality Management process.

8.1.3 Plan Quality Management

8.1.3.1  Quality Management Plan

The quality management plan includes guidelines that help in the conducting of all the other quality management processes, namely 8.2 Manage Quality and 8.3 Control Quality.

These may be included as part of the quality management plan:

  • The quality standards to be used on the project
  • The quality control and quality management activities planned for the project)
  • The quality roles and responsibilities (who will conduct the quality assurance and/or quality control activities)
  • Project deliverables subject to quality control
  • Project processes subject to quality assurance
  • Quality tools to be used on the project
  • Procedures for dealing with non-conformance, such as defect repair and corrective actions, as well as procedures for continuous improvement.

8.1.3.2  Quality Metrics

A quality metric describes an attribute of the project or product such as number of defects identified per day, errors found per line of code, customer satisfaction scores, etc.  The Control Quality process needs to verify compliance with this quality metric.

8.1.3.3 Project Management Plan Updates

Besides the creation of the quality management plan as an output to this process (see paragraph 8.1.3.1), there are other components of the project management plan which are updated as a result of this process, including the following:

  • Risk management plan–decisions on the quality management approach may require changes to managing risk on the project, and these changes are recorded in the risk management plan.
  • Scope baseline–the WBS may require the addition of quality management activities as a result of this process, and the WBS dictionary may records quality requirements related to individual activities or entire work packages.

8.1.3.4 Project Documents Updates

  • Lessons learned register–this may be updated with any challenges encountered in the quality planning process
  • Requirements traceability matrix–if quality requirements are specified by this process, they are recorded in the requirements traceability matrix.
  • Risk register–any new risks identified during this process are updated in the risk register.
  • Stakeholder register–updated with new information on existing or new stakeholders with regards to their interest or influence on quality issues related to this project.

That finishes our discussion of process 8.1 Plan Quality Management. The next process is 8.2 Manage Quality, which takes the quality activities specified in the quality management plan and implements them on the project.   The inputs to this process will be discussed in the next post.

6th Edition PMBOK® Guide–Process 8.1 Plan Quality Management: Tools and Techniques


There are certain “generic” tools and techniques that are used in any process in the PMBOK® Guide that creates a management plan:   expert judgment, decision making, and meetings.    There are other tools and techniques that are specific to this quality management knowledge area.

Let’s go through the tools and techniques for this process.

8.1.2 Plan Quality Management:  Tools and Techniques

8.1.2.1 Expert Judgment

Subject matter experts are always sought after when creating a management plan; in the case of this knowledge area, experts are sought with expertise in anything having to do with quality:

  • quality assurance (making sure that the quality processes are done correctly),
  • quality control (making sure that the quality outcomes fulfill the project criteria),
  • quality improvements (making sure that there is a process in place to improve quality such as Six Sigma),
  • quality systems (making sure that the benefits of pursuing the desired quality levels outweigh the costs of implementing those systems).

8.1.2.2 Data Gathering

Here are some techniques used to gather data regarding quality.

  • Benchmarking–this means comparing the proposed quality standards of the project and comparing them to those of comparable projects.   This could mean comparing the standards to projects that the organization itself has done, or those done by other organizations within the same application area.
  • Brainstorming–this involves gathering\experts (see paragraph 8.1.2.1 above) together in a format that identifies a list of ideas in a short period of time.  Brainstorming consists of two parts:   idea generation, which is an “open mode” of discussion where all ideas are entertained in order to stimulate creative input, and the analysis or “closed mode” of discussion where the ideas are prioritized or ranked according to a set of criteria that are agreed upon beforehand.
  •  Interviews–rather than the brainstorming technique, which involves bringing all of the experts together with the project team in order to generate ideas, interviews are done by having members of the project team do individual interviews of experts and/or stakeholders in order to get their views on appropriate quality standards for the project.

8.1.2.3 Data Analysis

  • Cost-benefit analysis and cost of quality (COQ)–the PMBOK® Guide lists these two tools and techniques separately, but essentially they are doing the same thing:   making sure that the planned quality activities are cost-effective.   In other words, the cost of conformance to the quality standards, i.e., costs of prevention and appraisal of defects, need to be less than the costs of non-conformance, i.e., the costs incurred if defects do occur.   These non-conformance costs can include the costs of internal failures, that is, defects that are discovered before the product is shipped out to the customer (rework and scrap), and the costs of external failure, that is, defects that are discovered after the product is shipped out to the customer (warranty, product liability claims and lawsuits, and lost repeat business).  There is an optimal level of quality for a project, where the cost of investing in a certain level of prevention and appraisal of potential defects is worth it because it is less than the cost of the defects they are designed to avoid, whereas investing in additional measures for prevention and appraisal would not be beneficial.

8.1.2.4 Decision Making

This is the process on how decisions are made at meetings (see paragraph 6.1.2.7) with subject matter experts (see paragraph 8.1.2.1) and project team members.   There can be tools such as prioritization matrices which can take various alternatives that come up during brainstorming and interviews (see paragraph 8.1.2.2) and rank them based on criteria that are decided upon beforehand.   This objective method of prioritizing quality metrics can help with the process in deciding which metrics to apply on the project.

8.1.2.5 Data Representation

  • Flowcharts–these are process maps, like the 49 project management processes covered in this PMBOK® Guide which take outputs from one process, and use them as inputs in another process, which then takes tools and techniques to create new outputs, which are uses in other processes, etc.   They are useful in understanding and estimating the cost of quality for a process.
  • Logical data models–these are visual representation’s of an organization’s data, which can be used to identify issues regarding the integrity of data used in quality metrics.   In this way a project manager can be more confident that the quality metrics are giving a true picture of quality on the project.
  • Matrix diagrams–these diagrams find the strength between the different factors listed in the rows and columns of the matrix, and are useful in identifying the key quality metrics for a project.
  • Mind mapping–this is a method where a single quality concept is put in the center of a blank page, and representations of ideas that are associated with that concept are put around the center.   It helps with the rapid gathering of project quality requirements, constraints, dependencies, and relationships.

8.1.2.6 Test and Inspection Planning

One of the costs of conformance is the costs of appraisal of whether a defect exists in a product or not, namely, the cost of testing or inspecting that product.   The project team needs to determine how to test or inspect the product, as well as how often to do the test or inspection (once for every X number of products, for example).

8.1.2.7 Meetings

Meetings are a generic technique that are used for any planning process.   In the case of quality management, they are used to conduct many of the other techniques listed above, for example, data gathering, data analysis, data representation, and the planning of tests and inspections.   Those invited can include the project sponsor, selected project team members who will be conducting quality-related processes during the project, stakeholders with an interest in quality on the project, and/or subject matter experts that have expertise with regards to quality.

The next post will cover the outputs of the Plan Quality Management Process.

 

 

6th Edition PMBOK® Guide–Process 8.1 Plan Quality Management


Before we discuss this planning process for the quality management knowledge area, let us make sure we are clear that quality is a constraint that covers the correctness of the work, as supposed to the scope that covers the completeness of the work.   Correct as compared to what, you may ask?   Correct as compared to the requirements as set forth at the very beginning of the project, which come from customers for an external project or the project sponsor for an internal one.

Like any other planning process, the process is designed to create guidelines and procedures on how to do all of the OTHER processes in the knowledge area, which are going to be contained in the Quality Management Plan as an output of the process.

Here are the inputs to the process:

8.1.1 Plan Quality Management:  Inputs

8.1.1.1 Project Charter

The project charter contains the high-level project description (sometimes referred to as the “statement of work”) and the product characteristics which are the technical requirements.   There may also be other requirements listed in the project charter, such as any requirements for the final product of the project to be approved by the customer or sponsor (as part of the Validate Scope process).

8.1.1.2 Project Management Plan

Here are the components of the project management plan which may be inputs to this process.

  • Requirements management plan–the output of process 5.1 Collect Requirements, this shows how the requirements will be identified, analyzed, and managed throughout the project.   The requirements are the highest level of the scope.
  • Scope baseline–the requirements are broken down into the deliverables in the project scope statement, and these in turn are broken down into the level of work packages in the Work Breakdown Structure or WBS.   The project scope statement, the WBS, and the WBS Dictionary, which contains information on the other constraints that relate to each work package (duration and cost estimates, for example), are all part of the scope baseline.
  • Risk management plan–output of process 11.1 Plan Risk Management.   Information from the risk management plan is used together with the quality management plan to successfully deliver product and project success.   Quality is measured by metrics which measure the likelihood of defects and these risks of a defectneed to be considered in the cost of quality, which compares the cost of doing quality control measures with the cost of NOT doing them (i.e., allowing a certain level of risk of defects).
  • Stakeholder management plan–output of process 13.2 Plan Stakeholder Management.   This contains the plan on documenting the stakeholders’ needs and expectations that contribute to the requirements for the product and project to be a success.

8.1.1.3  Project Documents

  • Assumption log—output of process 4.1 Develop Project Charter. May contain assumptions and constraints regarding quality requirements.
  • Requirements documentation (including requirements traceability matrix)—may include project and product quality requirements, as well as tests required to verify those requirements.
  • Risk register –may contain information on threats and opportunities that impact quality requirements.
  • Stakeholder register—helps identify stakeholders who have a particular interest or impact on the quality requirements.

8.1.1.4 Enterprise Environmental Factors

Among the enterprise environmental factors that may influence the quality requirements for the project are the following:

  • Governmental agency regulations regarding health and safety
  • Standards related to quality that are specific to the application area

8.1.1.5 Organizational Process Assets

  • Organizational quality management policices, procedures, and guidelines
  • Quality-related templates
  • Historical databases and lessons learned repository from previous similar projects

The next post will cover the tools and techniques of this process.

 

 

6th Edition PMBOK® Guide–Process 7.4 Control Costs: Outputs


This is the last process for the cost management knowledge area, and as a monitoring and control process, it has the outputs that are typical for such a process:   work performance information, change requests, and updates to the project management plan.   There is one output that is specific to this knowledge area and that is cost forecasts.

Let’s go over the outputs for this process.

7.4.3 Control Costs:  Outputs

7.4.3.1  Work Performance Information

One of the inputs to this process was work performance data, which represented in the case of this process the actual costs associated with the activities done in the last reporting period.   Among other things, this process takes those actual costs and compares them to the costs that were projected as part of the project budget, and determines whether there are any variances.   If there are any, the data regarding the variances and any preliminary determination as to those cause are considered work performance information which the project team can use to determine what change requests (see paragraph 7.4.3.3 below) to implement in order to correct them.

7.4.3.2 Cost Forecasts

As one of the results of trend analysis and forecasting, two data analysis techniques used in this process, an estimate of how much the project will now cost in order to complete may be done, and this quantity called the Estimate At Completion or EAC may be documented for inclusion in reports to stakeholders.

7.4.3.3  Change Requests

As mentioned above in paragraph 7.4.3.1, if variances between the actual costs and the proposed costs (i.e., what is in the project budget) are uncovered by this process, there may be change requests proposed in order to correct these variances and to bring the costs in line with what is in the plan or budget.   These change requests are then input, as are all other change requests from different knowledge areas, to the main change control process 4.6 Perform Integrated Change Control.f

7.4.3.4 Project Management Plan Updates

As a result of this process, some of the components of the project management plan may be updated.   These include the following:

  • Cost management plan–feedback from relevant stakeholders may require a change request to moderate the guidelines for this process, including control thresholds or specified levels of accuracy when reporting the project’s cost.
  • Cost baseline–if there are any changes in cost estimates uncovered as a result of this process, the change request may require changes to the cost baseline.   Remember, a change request can either
    • change the work to fit the plan (with a defect repair, corrective action, or preventive action)
    • change the plan to fit the work (if the original cost estimates prove to be unrealistic based on new knowledge gained in the last reporting cycle)
  • Performance measurement baseline–any approved changes in the cost baseline will affect the performance measurement baseline.   For example, if there are changes in cost estimates for a given activity, the planned value or PV of that activity may change, and when that activity is completed, its earned value of that value may change as well.   Since all of the earned value analysis measurements such as SPI, SV, CPI, and CV depend on the value of EV, this will have an effect on those derived values as well.   If the affect on the performance measurement baseline is large, it may require recalculating the project budget as a whole (the budget at completion or BAC) and/or the remaining budget to be spent (the estimate to completion or ETC).

The next post will start on the next knowledge area, that of quality management!