4squareviews

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 »

The tools and techniques for the Process 7.4 Control Costs contain some which I call “generic”, meaning that they are used in every monitoring and controlling process called “Control X” where “X” stands for any knowledge area, including cost management.    Then there are some which are used specifically for schedule and/or cost management, like Data Analysis techniques such as

• Earned Value Analysis,
• Variance Analysis
• Trend Analysis
• Reserve Analysis

and the To-Complete Performance Index (TCPI) which uses earned value analysis as a forecast tool.

Let me quickly cover in this post the “generic” tools and techniques, and then in the next post, I’ll start covering earned value analysis.

The generic tools and techniques used in this process are (note that the numbering is not consecutive, because I am selecting out only those tools and techniques which are generic).

7.4.2 Control Costs:  Tools and Techniques

7.4.2.1 Expert Judgment

You want to make use of the expert judgment of either people on your project team or others who have expertise in the following areas:

• Earned value analysis (one of the main Data Analysis Techniques to uncover whether there is a variance between the actual costs of activities and the planned costs for those activities according to the project budget)
• Variance analysis (one of the Data Analysis Techniques done to determine the source of the variance if one is uncovered during earned value analysis)
• Trend analysis and forecasting (including the To-Complete Performance Index or TCPI, these Data Analysis Techniques will show what will happen to the project as a whole, either with regards to the overall project schedule or budget, if current trends continue that are uncovered by earned value analysis)
• Financial analysis (especially to see if funding for project is remaining within project funding requirements)

7.4.2.4 Project Management Information System (PMIS)

This is a tool, rather than a technique, and it is the software system used to monitor the three basic quantities used in earned value analysis, namely PV (planned value), EV (earned value), and AC (actual cost). and to assist with trend analysis and forecasting.

In the next post, then, we will start discussing Data Analysis Techniques starting with earned value analysis.   This is important not just for project managers doing a project, but for those studying for the PMP exam, because PMI loves asking questions about earned value analysis on the certification exam!

Filed under: Uncategorized | Leave a comment »

The first three processes in this cost management knowledge area are planning processes; this last one is a process in the monitoring and controlling process group.   Ass such, it follows a typical pattern for such processes.   The inputs come from the work performance data (i.e., how much did the activities actually cost?), and the cost management plan (i.e., how much were the activities supposed to cost according to the plan).   The tools and techniques basically do a comparison between the two, and if there is a discrepancy, what PMI likes to term a variance, the cause for this is determined, and the output of the process is a recommendation on how to correct this (the change requests), as well as the results of the analysis done during the process (work performance information).

Let’s go into detail regarding the inputs of this process.

7.4.1 Control Costs:  Inputs

7.4.1.1 Project Management Plan

• Cost Management Plan–this is an output of process 7.1 Plan Cost Management, and it contains guidelines on how to do all the other processes in the cost management knowledge area, including this one.   Here are some specific guidelines that pertain to process 7.4 Control Costs
  • Rules of performance measurement–Earned Value Management or EVM is a tool used in monitoring the performance of a project, including whether it is ahead of, on, or behind schedule.   The rules of how EVM will be used on the project should be specified, usually using one of the two measures Schedule Performance Index (SPI) or Schedule Variance (SV).
  • Control thresholds–once a variance is detected, the threshold should be set (usually in terms of a percentage deviation from the baseline plan as expressed in the SPI) ,so that any amount of variation above that threshold will cause certain actions to be taken.
  • Reporting formats–when the work performance reports are sent to the stakeholders, the formats of those reports, which stakeholders receive them, and the frequency of those reports should be specified.
• Cost baseline–this is an output of the last process 7.3 Determine Budget, and it represents the budget according to plan; it is what the actual costs are compared to in order to determine whether a variance exists.
• Performance measurement baseline–this is used in earned value analysis, which takes the three constraints of scope, schedule and cost and combines them to create a baseline from which to compare the actual results in terms of schedule and cost.  In the case of cost management, the quantities used are the Cost Performance Index (CPI) and the Cost Variance (CV).

7.4.2 Project Documents

The lessons learned register, an output of process 4.4 Manage Project Knowledge, is updated during this process to see if there are any procedures done by the project team that improve cost control; these lessons are stored in the register to be used later on in the project, and possibly on future projects as well.

7.4.1.3 Project Funding Requirements

This is another output of the previous process 7.3 Determine Budget.   This is done if the money for the project budget is not available from the parent organization all at once, and if it is supplied for use by the project team in increments.    In this case, the funding limits for each period are set up, and so it is important for the project manager to make sure that the expenditures during each period do not exceed the amount given by the periodic funding limit.

7.4.1.4 Work Performance Data

This is an output of process 4.3 Direct and Manage Project Work.   The data that pertains to this process include the actual costs that have authorized, incurred, invoiced and paid for activities done on the project.

7.4.1.5 Organizational Process Assets

• Policies, procedures and guidelines related to cost control (should be included in the Cost Management Plan), including methods for monitoring, controlling, and reporting information related to costs
• Cost control tools (the Project Management Information System, if created by another company as in the case of Microsoft Project, is considered an Enterprise Environmental Factor; if a tool is proprietary and created by the organization doing the project, it is an Organizational Process Asset)

The next post will cover the Tools and Techniques used in this process.

Filed under: Uncategorized | Leave a comment »