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.

Filed under: Uncategorized | Leave a comment »

The quality management knowledge area consists of three processes, one in the planning process group (Plan Quality Management), one in the executing process group (Manage Quality), and one in the monitoring and controlling process group (Control Quality).   The difference between Manage Quality and Control Quality is that Manage Quality focuses on quality assurance, that is, making sure of the correctness of the processes done on the project, and Control Quality focuses on quality control, that is, making sure of the correctness of the results of those processes, i.e., the deliverables.    Specifically what do we mean by “correctness”?

In the language of project management, what constitutes correctness is the degree to which the project deliverables work the requirements specified by the stakeholders.

In this post, we will go over the inputs to this process.

8.3.1 Control Quality:  Inputsss

8.3.1.1 Project Management Plan

The component of the overall project management plan that is an input to this process is the quality management plan, the output of process 8.1 Plan Quality Management.   The specific elements of the quality management plan that may be used on this process include the following:

• The quality objectives of the project (these are what the deliverables will be compared to)
• The quality control management activities planned for the project (how will it be monitored, and how will it be controlled)
• The quality roles and responsibilities (who will conduct the quality control activities)
• Project deliverables subject to quality control
• Quality tools to be used on the project
• Procedures for dealing with non-conformance, such as defect repair and corrective actions.

8.3.1.2  Project Documents

• Lessons learned register–lessons learned during this quality control process early on in the project are put into the register so that they can be applied to later phases in the project to improve quality control
• Quality metrics–these are an output of process 8.1 Plan Quality Management.  This document tracks the attributes of a product and how the Control Quality process will verify compliance with those metrics.
• Test and evaluation documents–These documents that were created in the Manage Quality process will be used to evaluate achievement of the quality objectives during this process.

8.3.1.3 Approved Change Requests

Let’s say in the first round of this process, there are change requests that occur as an output of the process.   The change requests are evaluated in process 4.6 Perform Integrated Change Control (as are the change requests coming out of ALL of other knowledge areas as well).   They will be either approved or rejected.   If rejected, they are put into the change log together with the reasons why they were rejected.    However, if they are approved, they imply that modifications will be done on the project in the area of quality control (such as defect repairs).   The implementation of these approved changes needs to be verified.

8.3.1.4 Deliverables

Deliverables, which are the output of process 4.3 Direct and Manage Product Work, are inspected and compared to the acceptance criteria defined in the project scope statement and the quality management plan.    Scope deals with the completeness of the work; quality deals with the correctness of the work.

8.3.1.5 Work Performance Data

Data on the product status such as observations, quality metrics, and measurements for technical performance, are used in this process because these will be compared to the quality standards to see if the product conforms to those standards or not.

8.3.1.6 Enterprise Environmental Factors

• The Project Management Information System–the software used to manage the project, including aspects of quality management.   This is an EEF because the software is not something which is created by the organization itself, but a tool created by an external company used by the organization.   However, data regarding previous projects stored on that software would be considered  an organizational process asset (see paragraph 8.3.1.7 below)
• Rules, standards, and guidelines specific to the application area.

8.3.1.7 Organizational Process Assets

• Quality standards and policies (should be included in the Quality Management Plan)
• Quality templates, for example, check sheets, checklists, etc.
• Issue and defect reporting procedures and communication policies

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

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

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:

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | 1 Comment »

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.

Filed under: Uncategorized | Leave a comment »

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!

Filed under: Uncategorized | Leave a comment »

In this post, we continue our discussion of the tools and techniques of this process 7.4 Control Costs.   In the last post, we covered the “generic” tools and techniques that would apply to any control process for any knowledge area, namely, Expert Judgment and the Project Management Information System (such as Microsoft Project).

Here are the tools and techniques that are specific to this process, although they are also used in the control process for another major constraint on the project, that of controlling the schedule.   (The numbering is not consecutive because I am skipping the “generic” tools and technique that were covered in the last post.)

7.4.2 Control Costs:  Tools and Techniques

7.4.2.2 Data Analysis

This covers a broad array of techniques that are used to analyze the extent to which the actual results (which you get from the input “Work Performance Data”) vary from what is in the plan (in particular, the cost baseline component of the Project Management Plan).

• Earned value analysis–there are three basic constraints on a project:  scope (the work packages in the WBS), time (the project schedule) and cost (the project budget).   There are three key quantities that are used in earned value management (sometimes referred to as EVM):   PV (planned value), EV (earned value), and AC (actual cost).   Let’s discuss each one in turn:
  • Planned value or PV is a measure of the scheduled or planned work.   Specifically, it is the authorized budget for the work to be accomplished for an activity.
  • Earned value (EV) is a measure of the scope actually accomplished.   Specifically , it is the budget for the work that has actually been completed.
  • Actual cost (AC) is a measure of the costs actually incurred.   Specifically, it is the realized cost for the work performed on an activity.
• Variance analysis–with the building blocks of PV, EV and AC, you can compute the variance between the actual results (as expressed in EV and AC) and what is in the plan (as expressed in PV).   There are four types of variance analysis that can be done by taking various combinations of these building blocks:
  • Schedule variance (SV) = EV – PV (a positive number is good, a negative number is bad, meaning the project is behind schedule)
  • Schedule performance index (SPI) = EV/PV (a number greater than one is good, a number less than one is bad, meaning the project is behind schedule)
  • Cost variance (CV) = EV – AC (a positive number is good, a negative number is bad, meaning a cost overrun)
  • Cost performance index (CPI) = EV/AC (a number greater than one is good, a number less than one is bad, meaning a cost overrun)
• Trend analysis–the variance analysis quantities listed above are a “snapshot” of the current performance on the project, but you can compare these same quantities over time to get an idea of the trend of the project performance.   If you see a cost performance index or CPI that is less than 1.0 now, you can take a corrective action that will bring the CPI above zero.  However, if you see that the CPI for the past few months is positive, but will be less than zero in two months if the current trend continues, you can take a preventive action to make sure the CPI doesn’t go below zero in the future.
• Forecasting–the amount of the total budget for the project is sometimes referred to as the budget at completion or BAC, because it is what is projected to be spent on the project if it completed based on the current budget.   But let’s say you are halfway done with the project, and it turns out you have spent all of the money that was budgeted for the project.   In this case, your CPI or cost performance index is 0.5, meaning that for every dollar you budgeted, you only got half of the amount of work done.   How much will you have to pay for the entire project?   Well, if you make the assumption that your CPI for the rest of the project is the same and you are only working at a 50% rate of efficiency, you will have to pay twice as much as you budgeted for originally.   This assumes that you will pay from now to completion the same amount that you have already paid to get to this half-way point.  This estimated amount that you will have to pay from now to completion is called the estimate to completion or ETC.   The total new estimated cost of doing the entire project is called the estimate at completion or EAC.   There are several ways to compute the EAC depending on the situation:
  • EAC = AC + (bottom-up) ETC  This requires looking at the WBS and taking the actual costs already incurred (AC) and adding it to an estimate of the remaining work to be done (ETC).
  • EAC = AC + (BAC – EV).   For the work remaining, if the assumption is that the work will be done according to the project budget (CPI = 1.0), then you can take the actual costs (AC) and add it to the value of the work that remains (BAC – EV).   This is used if the variance encountered is a one-time deal based on a factor which can be easily corrected with a corrective action.
  • EAC = BAC/CPI.   For the work remaining, if the assumption is that the work will be done based on the current CPI, then you can take the BAC and divide it by the CPI as in the example I just gave.   If your CPI is 0.5, that means you are working at 50% efficiency from a cost standpoint; so it will take twice as much money to do the project than what you budgeted.   So EAC = BAC/CPI = BAC/0.5 = 2 x BAC.
  • EAC = AC + [(BAC – EV)/ (CPI x SPI)].   For the work remaining, if the assumption is that the work will be done on the current CPI AND the current SPI (schedule performance index), then you take the actual costs already incurred (AC) and add it to the remaining costs (BAC – EV) and adjust it by dividing by both the factors CPI and SPI.
• Reserve analysis–this comes about from the risk management knowledge area.   If there are identified risks associated with an activity, the money for possible risk responses is included in the contingency reserves for that activity.    The budgeted amount for that activity will include the actual costs for the activity plus the contingency reserves for any possible risk responses.    Let’s say the activity is done, and the identified risks do not occur.   Those unused contingency reserves may be removed from the project budget so that those financial resources can be used on other projects.   Of course, if during the course of doing the project, risks are identified which were not identified at the start and included on the risk register, there may be a need for a request for additional reserves to be added to the project budget.

7.4.2.3 To-Complete Performance Index (TCPI)

This is actual a forecasting tool, because what it does is compute what your CPI has to be from here on out in order to complete the project within the allotted budget.   It is calculated by taking the remaining work (BAC – EV) and dividing by the remaining costs in the budget (BAC – AC).

If the allotted budget is not going to be sufficient, then an alternative version of the TCPI does the following.   It is calculated first by getting the new estimate for how much it will take to complete the project (EAC), and then taking the remaining work (BAC – EV) and dividing it by the costs in the remainder of the revised budget estimate (EAC – AC).   If you have been running the project up to this point with a CPI that is less than 1.0, you will have to have a CPI that is greater than 1.0 (with greater cost efficiency) in order to complete the project.   Likewise, if you have been running the project up to this point with a CPI that is greater than 1.0, than you complete the project even if your CPI is less than 1.0 from here on out.   The TCPI, of course, will tell you exactly what that CPI amount has to be in order to “break even” at the end of the project.

With all of these tools related to earned value analysis (sometimes called earned value management or EVM), you may want to search my website with the term examples from previous versions of the PMBOK Guide, because although some of the content in the Guide has changed, the basic theory behind EVM is the same.

The next post will be on outputs for this process.

Filed under: Uncategorized | Leave a comment »