Microsoft Word - PMBOK5th_Ed_Pre_publication

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 7-3. Plan Cost Management: Data Flow Diagram

The cost management processes and their associated tools and techniques are

documented in the cost management plan. The cost management plan is a component of the

project management plan.

7.1.1 Plan Cost Management: Inputs

7.1.1.1 Project Management Plan

Described in Section 4.2.3.1. The project management plan contains information used to

develop the cost management plan, which contains, but is not limited to:

 Scope baseline. The scope baseline includes the project scope statement and WBS

detail for cost estimation and management.

 Schedule baseline. The schedule baseline defines when the project costs will be

incurred.

 Other information. Other cost-related scheduling, risk, and communications

decisions from the project management plan.

7.1.1.2 Project Charter

Described in Section 4.1.3.1. The project charter provides the summary budget from

which the detailed project costs are developed. The project charter also defines the project

approval requirements that will influence the management of the project costs.

7.1.1.3 Enterprise Environmental Factors

Described in Section 2.1.5. The enterprise environmental factors that influence the Plan

Cost Management process include, but are not limited to:

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

 Organizational culture and structure can all influence cost management;

 Market conditions describe what products, services, and results are available in the

regional and global market;

 Currency exchange rates for project costs sourced from more than one country;

 Published commercial information such as resource cost rate information is often

available from commercial databases that track skills and human resource costs, and

provide standard costs for material and equipment. Published seller price lists are

another source of information; and

 Project management information system, which provides alternative possibilities for

managing cost.

7.1.1.4 Organizational Process Assets

Described in Section 2.1.4. The organizational process assets that influence the Plan Cost

Management process include, but are not limited to:

 Financial controls procedures (e.g., time reporting, required expenditure and

disbursement reviews, accounting codes, and standard contract provisions);

 Historical information and lessons learned knowledge bases;

 Financial databases; and

 Existing formal and informal cost estimating and budgeting-related policies,

procedures, and guidelines.

7.1.2 Plan Cost Management: Tools and Techniques

7.1.2.1 Expert Judgment

Expert judgment, guided by historical information, provides valuable insight about the

environment and information from prior similar projects. Expert judgment can also suggest

whether to combine methods and how to reconcile differences between them.

Judgment based upon expertise in an application area, Knowledge Area, discipline,

industry, etc., as appropriate for the activity being performed should be used in developing the

cost management plan.

7.1.2.2 Analytical Techniques

Developing the cost management plan may involve choosing strategic options to fund the

project such as: self-funding, funding with equity, or funding with debt. The cost management

plan may also detail ways to finance project resources such as making, purchasing, renting, or

leasing. These decisions, like other financial decisions affecting the project, may affect project

schedule and/or risks.

Organizational policies and procedures may influence which financial techniques are

employed in these decisions. Techniques may include (but are not limited to): payback period,

return on investment, internal rate of return, discounted cash flow, and net present value.

7.1.2.3 Meetings

Project teams may hold planning meetings to develop the cost management plan.

Attendees at these meetings may include the project manager, the project sponsor, selected

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

project team members, selected stakeholders, anyone with responsibility for project costs, and

others as needed.

7.1.3 Plan Cost Management: Outputs

7.1.3.1 Cost Management Plan

The cost management plan is a component of the project management plan and describes

how the project costs will be planned, structured, and controlled. The cost management processes

and their associated tools and techniques are documented in the cost management plan.

For example, the cost management plan can establish the following:

 Units of measure. Each unit used in measurements (such as staff hours, staff days,

weeks for time measures; or meters, liters, tons, kilometers, or cubic yards for

quantity measures; or lump sum in currency form) is defined for each of the

resources.

 Level of precision. The degree to which activity cost estimates will be rounded up or

down (e.g., US$100.49 to US$100, or US$995.59 to US$1,000), based on the scope

of the activities and magnitude of the project.

 Level of accuracy. The acceptable range (e.g., ±10%) used in determining realistic

activity cost estimates is specified, and may include an amount for contingencies;

 Organizational procedures links. The work breakdown structure (WBS) (Section

5.4) provides the framework for the cost management plan, allowing for consistency

with the estimates, budgets, and control of costs. The WBS component used for the

project cost accounting is called the control account. Each control account is assigned

a unique code or account number(s) that links directly to the performing

organization’s accounting system.

 Control thresholds. Variance thresholds for monitoring cost performance may be

specified to indicate an agreed-upon amount of variation to be allowed before some

action needs to be taken. Thresholds are typically expressed as percentage deviations

from the baseline plan.

 Rules of performance measurement. Earned value management (EVM) rules of

performance measurement are set. For example, the cost management plan may:

o Define the points in the WBS at which measurement of control accounts will be

performed;

o Establish the earned value measurement techniques (e.g., weighted milestones,

fixed-formula, percent complete, etc.) to be employed; and

o Specify tracking methodologies and the earned value management computation

equations for calculating projected estimate at completion (EAC) forecasts to

provide a validity check on the bottom-up EAC.

For more specific information regarding earned value management, refer to the Practice

Standard for Earned Value Management – Second Edition.

 Reporting formats. The formats and frequency for the various cost reports are

defined.

 Process descriptions. Descriptions of each of the other cost management processes

are documented.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

 Additional details. Additional details about cost management activities include, but

are not limited to:

o Description of strategic funding choices,

o Procedure to account for fluctuations in currency exchange rates, and

o Procedure for project cost recording.

7.2 Estimate Costs

Estimate Costs is the process of developing an approximation of the monetary resources

needed to complete project activities. The key benefit of this process is that it determines the

amount of cost required to complete project work. The inputs, tools and techniques, and outputs

of this process are depicted in Figure 7-4. Figure 7-5 depicts the data flow diagram of the

process.

Figure 7-4. Estimate Costs: Inputs, Tools & Techniques, and Outputs

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 7-5. Estimate Costs Data Flow Diagram

Cost estimates are a prediction that is based on the information known at a given point in

time. Cost estimates include the identification and consideration of costing alternatives to initiate

and complete the project. Cost trade-offs and risks should be considered, such as make versus

buy, buy versus lease, and the sharing of resources in order to achieve optimal costs for the

project.

Cost estimates are generally expressed in units of some currency (i.e., dollars, euros, yen,

etc.), although in some instances other units of measure, such as staff hours or staff days, are

used to facilitate comparisons by eliminating the effects of currency fluctuations.

Cost estimates should be reviewed and refined during the course of the project to reflect

additional detail as it becomes available and assumptions are tested. The accuracy of a project

estimate will increase as the project progresses through the project life cycle. For example, a

project in the initiation phase may have a rough order of magnitude (ROM) estimate in the range

of −25% to +75%. Later in the project, as more information is known, definitive estimates could

narrow the range of accuracy to -5% to +10%. In some organizations, there are guidelines for

when such refinements can be made and the degree of confidence or accuracy that is expected.

Sources of input information are derived from the outputs of processes in other

Knowledge Areas. Once received, all of this information will remain available as inputs to all of

the cost management processes.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Costs are estimated for all resources that will be charged to the project. This includes, but

is not limited to, labor, materials, equipment, services, and facilities, as well as special categories

such as an inflation allowance, cost of financing, or contingency costs. A cost estimate is a

quantitative assessment of the likely costs for resources required to complete the activity. Cost

estimates may be presented at the activity level or in summary form.

7.2.1 Estimate Costs: Inputs

7.2.1.1 Cost Management Plan

Described in Section 7.1.3.1. The cost management plan defines how project costs will be

managed and controlled. It includes the method used and the level of accuracy required to

estimate activity cost.

7.2.1.2 Human Resource Management Plan

Described in Section 9.1.3.1. The human resource management plan provides project

staffing attributes, personnel rates, and related rewards/recognition, which are necessary

components for developing the project cost estimates.

7.2.1.3 Scope Baseline

The scope baseline is comprised of the following:

 Project scope statement. The project scope statement (Section 5.3.3.1) provides the

product description, acceptance criteria, key deliverables, project boundaries,

assumptions, and constraints about the project. One basic assumption that needs to be

made when estimating project costs is whether the estimates will be limited to direct

project costs only or whether the estimates will also include indirect costs. Indirect

costs are those costs that cannot be directly traced to a specific project and therefore

will be accumulated and allocated equitably over multiple projects by some approved

and documented accounting procedure. One of the most common constraints for

many projects is a limited project budget. Examples of other constraints are required

delivery dates, available skilled resources, and organizational policies.

 Work breakdown structure. The WBS (Section 5.4) provides the relationships

among all the components of the project and the project deliverables.

 WBS dictionary. The WBS dictionary (Section 5.4.3.1) provides detailed

information about the deliverables and a description of the work for each component

in the WBS required to produce each deliverable.

Additional information that may be found in the scope baseline with contractual and legal

implications, such as health, safety, security, performance, environmental, insurance, intellectual

property rights, licenses, and permits. All of this information should be considered when

developing the cost estimates.

7.2.1.4 Project Schedule

Described in Section 6.6.3.2. The type and quantity of resources and the amount of time

which those resources are applied to complete the work of the project are major factors in

determining the project cost. Schedule activity resources and their respective durations are used

as key inputs to this process. Estimate Activity Resources (Section 6.4) involves determining the

availability of staff, the number of staff hours required, and quantities of material and equipment

needed to perform schedule activities. It is closely coordinated with cost estimating. Activity

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

duration estimates (Section 6.5.3.1) will affect cost estimates on any project where the project

budget includes an allowance for the cost of financing (including interest charges) and where

resources are applied per unit of time for the duration of the activity. Activity duration estimates

can also affect cost estimates that have time-sensitive costs included in them, such as union labor

with regularly expiring collective bargaining agreements or materials with seasonal cost

variations.

7.2.1.5 Risk Register

Described in Section 11.2.3.1. The risk register should be reviewed to consider risk

response costs. Risks, which can be either threats or opportunities, typically have an impact on

both activity and overall project costs. As a general rule, when the project experiences a negative

risk event, the near-term cost of the project will usually increase, and there will sometimes be a

delay in the project schedule. In a similar way, the project team should be sensitive to potential

opportunities that can benefit the business either by directly reducing activity costs or by

accelerating the schedule.

7.2.1.6 Enterprise Environmental Factors

Described in Section 2.1.5. The enterprise environmental factors that influence the

Estimate Costs process include, but are not limited to:

 Market conditions. These conditions describe what products, services, and results

are available in the market, from whom, and under what terms and conditions.

Regional and/or global supply and demand conditions greatly influence resource

costs.

 Published commercial information. Resource cost rate information is often

available from commercial databases that track skills and human resource costs, and

provide standard costs for material and equipment. Published seller price lists are

another source of information.

7.2.1.7 Organizational Process Assets

Described in Section 2.1.4. The organizational process assets that influence the Estimate

Costs process include, but are not limited to:

 Cost estimating policies,

 Cost estimating templates,

 Historical information, and

 Lessons learned.

7.2.2 Estimate Costs: Tools and Techniques

7.2.2.1 Expert Judgment

Expert judgment, guided by historical information, provides valuable insight about the

environment and information from prior similar projects. Expert judgment can also be used to

determine whether to combine methods of estimating and how to reconcile differences between

them.

7.2.2.2 Analogous Estimating

Analogous cost estimating uses the values such as scope, cost, budget, and duration or

measures of scale such as size, weight, and complexity from a previous, similar project as the

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

basis for estimating the same parameter or measurement for a current project. When estimating

costs, this technique relies on the actual cost of previous, similar projects as the basis for

estimating the cost of the current project. It is a gross value estimating approach, sometimes

adjusted for known differences in project complexity.

Analogous cost estimating is frequently used to estimate a value when there is a limited

amount of detailed information about the project, for example, in the early phases of a project.

Analogous cost estimating uses historical information and expert judgment.

Analogous cost estimating is generally less costly and less time consuming than other

techniques, but it is also generally less accurate. Analogous cost estimates can be applied to a

total project or to segments of a project, in conjunction with other estimating methods.

Analogous estimating is most reliable when the previous projects are similar in fact and not just

in appearance, and the project team members preparing the estimates have the needed expertise.

7.2.2.3 Parametric Estimating

Parametric estimating uses a statistical relationship between relevant historical data and

other variables (e.g., square footage in construction) to calculate a cost estimate for project work.

This technique can produce higher levels of accuracy depending upon the sophistication and

underlying data built into the model. Parametric cost estimates can be applied to a total project or

to segments of a project, in conjunction with other estimating methods.

7.2.2.4 Bottom-Up Estimating

Bottom-up estimating is a method of estimating a component of work. The cost of

individual work packages or activities is estimated to the greatest level of specified detail. The

detailed cost is then summarized or “rolled up” to higher levels for subsequent reporting and

tracking purposes. The cost and accuracy of bottom-up cost estimating are typically influenced

by the size and complexity of the individual activity or work package.

7.2.2.5 Three-Point Estimating

The accuracy of single-point activity cost estimates may be improved by considering

estimation uncertainty and risk and using three estimates to define an approximate range for an

activity’s cost:

 Most likely (cM). The cost of the activity, based on realistic effort assessment for the

required work and any predicted expenses.

 Optimistic (cO). The activity cost based on analysis of the best-case scenario for the

activity.

 Pessimistic (cP). The activity cost based on analysis of the worst-case scenario for

the activity.

Depending on the assumed distribution of values within the range of the three estimates

the expected cost, cE, can be calculated using a formula. Two commonly used formulas are

triangular and beta distributions. The formulas are:

 Triangular Distribution. cE

= (cO + cM + cP) / 3

 Beta Distribution (from a traditional PERT analysis). cE = (cO + 4cM + cP) / 6

Cost estimates based on three points with an assumed distribution provide an expected

cost and clarify the range of uncertainty around the expected cost.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

7.2.2.6 Reserve Analysis

Cost estimates may include contingency reserves (sometimes called contingency

allowances) to account for cost uncertainty. Contingency reserves are the budget within the cost

baseline that is allocated for identified risks, which are accepted and for which contingent or

mitigating responses are developed. Contingency reserves are often viewed as the part of the

budget intended to address the “known-unknowns” that can affect a project. For example, rework

for some project deliverables could be anticipated, while the amount of this rework is unknown.

Contingency reserves may be estimated to account for this unknown amount of rework.

Contingency reserves can provide for a specific activity, for the whole project, or both. The

contingency reserve may be a percentage of the estimated cost, a fixed number, or may be

developed by using quantitative analysis methods.

As more precise information about the project becomes available, the contingency

reserve may be used, reduced, or eliminated. Contingency should be clearly identified in cost

documentation. Contingency reserves are part of the cost baseline and the overall funding

requirements for the project.

Estimates may also be produced for the amount of management reserve to be funded for

the project. Management reserves are an amount of the project budget withheld for management

control purposes and are reserved for unforeseen work that is within scope of the project.

Management reserves are intended to address the “unknown unknowns” that can affect a project.

The management reserve is not included in the cost baseline but is part of the overall project

budget and funding requirements. When an amount of management reserves is used to fund

unforeseen work, the amount of management reserve used is added to the cost baseline, thus

requiring an approved change to the cost baseline.

7.2.2.7 Cost of Quality (COQ)

Assumptions about costs of quality (Section 8.1.2.2) may be used to prepare the activity

cost estimate.

7.2.2.8 Project Management Software

Project management software applications, computerized spreadsheets, simulation, and

statistical tools are used to assist with cost estimating. Such tools can simplify the use of some

cost-estimating techniques and thereby facilitate rapid consideration of cost estimate alternatives.

7.2.2.9 Vendor Bid Analysis

Cost estimating methods may include analysis of what the project should cost, based on

the responsive bids from qualified vendors. When projects are awarded to a vendor under

competitive processes, additional cost estimating work may be required of the project team to

examine the price of individual deliverables and to derive a cost that supports the final total

project cost.

7.2.2.10 Group Decision-Making Techniques

Team-based approaches, such as brainstorming, the Delphi or nominal group techniques,

are useful for engaging team members to improve estimate accuracy and commitment to the

emerging estimates. By involving a structured group of people who are close to the technical

execution of work in the estimation process, additional information is gained and more accurate

estimates are obtained. Additionally, when people are involved in the estimation process, their

commitment towards meeting the resulting estimates increases.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

7.2.3 Estimate Costs: Outputs

7.2.3.1 Activity Cost Estimates

Activity cost estimates are quantitative assessments of the probable costs required to

complete project work. Cost estimates can be presented in summary form or in detail. Costs are

estimated for all resources that are applied to the activity cost estimate. This includes, but is not

limited to, direct labor, materials, equipment, services, facilities, information technology, and

special categories such as cost of financing (including interest charges),an inflation allowance,

exchange rates, or a cost contingency reserve. Indirect costs, if they are included in the project

estimate, can be included at the activity level or at higher levels.

7.2.3.2 Basis of Estimates

The amount and type of additional details supporting the cost estimate vary by

application area. Regardless of the level of detail, the supporting documentation should provide a

clear and complete understanding of how the cost estimate was derived.

Supporting detail for activity cost estimates may include:

 Documentation of the basis of the estimate (i.e., how it was developed),

 Documentation of all assumptions made,

 Documentation of any known constraints,

 Indication of the range of possible estimates (e.g., €10,000 (±10%) to indicate that the

item is expected to cost between a range of values), and

 Indication of the confidence level of the final estimate.

7.2.3.3 Project Documents Updates

Project documents that may be updated include, but are not limited to, the risk register.

7.3 Determine Budget

Determine Budget is the process of aggregating the estimated costs of individual

activities or work packages to establish an authorized cost baseline. The key benefit of this

process is that it determines the cost baseline against which project performance can be

monitored and controlled. The inputs, tools and techniques, and outputs of this process are

depicted in Figure 7-6. Figure 7-7 depicts the data flow diagram of the process.

Figure 7-6. Determine Budget: Inputs, Tools & Techniques, and Outputs

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 7-7. Determine Budget Data Flow Diagram

A project budget includes all the funds authorized to execute the project. The cost

baseline is the approved version of the time-phased project budget, but excludes management

reserves.

7.3.1 Determine Budget: Inputs

7.3.1.1 Cost Management Plan

Described in Section 7.1.3.1. The cost management plan describes how the project costs

will be managed and controlled.

7.3.1.2 Scope Baseline

 Project scope statement. Formal limitations by period for the expenditure of project

funds can be mandated by the organization, by agreement (Section 12.2.3.2), or by

other entities such as government agencies. These funding constraints are reflected in

the project scope statement.

 Work breakdown structure. The WBS (Section 5.4) provides the relationships

among all the project deliverables and their various components.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

 WBS dictionary. The WBS dictionary (Section 5.4.3.1) and related detailed

statements of work provide an identification of the deliverables and a description of

the work in each WBS component required to produce each deliverable.

7.3.1.3 Activity Cost Estimates

Described in Section 7.2.3.1. Cost estimates for each activity within a work package are

aggregated to obtain a cost estimate for each work package.

7.3.1.4 Basis of Estimates

Described in Section 7.2.3.2. Supporting detail for cost estimates contained in the basis

for estimates should specify any basic assumptions dealing with the inclusion or exclusion of

indirect or other costs in the project budget.

7.3.1.5 Project Schedule

Described in Section 6.6.3.2. The project schedule includes planned start and finish dates

for the project’s activities, milestones, work packages, and control accounts. This information

can be used to aggregate costs to the calendar periods in which the costs are planned to be

incurred.

7.3.1.6 Resource Calendars

Described in Sections 9.2.3.2 and 12.2.3.3. Resource calendars provide information on

which resources are assigned to the project and when they are assigned. This information can be

used to indicate resource costs over the duration of the project.

7.3.1.7 Risk Register

Described in Section 11.2.3.1. The risk register should be reviewed to consider how to

aggregate the risk response costs. Updates to the risk register are included with project document

updates described in Section 11.5.3.2.

7.3.1.8 Agreements

Described in Section 12.2.3.2. Applicable agreement information and costs relating to

products, services, or results that have been or will be purchased are included when determining

the budget.

7.3.1.9 Organizational Process Assets

Described in Section 2.1.4. The organizational process assets that influence the

Determine Budget process include, but are not limited to:

 Existing formal and informal cost budgeting-related policies, procedures, and

guidelines;

 Cost budgeting tools; and

 Reporting methods.

7.3.2 Determine Budget: Tools and Techniques

7.3.2.1 Cost Aggregation

Cost estimates are aggregated by work packages in accordance with the WBS. The work

package cost estimates are then aggregated for the higher component levels of the WBS (such as

control accounts) and ultimately for the entire project.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

7.3.2.2 Reserve Analysis

Budget reserve analysis can establish both the contingency reserves and the management

reserves for the project. Management and contingency reserves are addressed in more detail in

Section 7.2.2.6.

7.3.2.3 Expert Judgment

Expert judgment, guided by experience in an application area, Knowledge Area,

discipline, industry, or similar project, aids in determining the budget. Such expertise may be

provided by any group or person with specialized education, knowledge, skill, experience, or

training. Expert judgment is available from many sources, including, but not limited to:

 Other units within the performing organization,

 Consultants,

 Stakeholders, including customers,

 Professional and technical associations, and

 Industry groups.

7.3.2.4 Historical Relationships

Any historical relationships that result in parametric estimates or analogous estimates

involve the use of project characteristics (parameters) to develop mathematical models to predict

total project costs. Such models may be simple (e.g., residential home construction is based on a

certain cost per square foot of space) or complex (e.g., one model of software development

costing uses multiple separate adjustment factors, each of which has numerous points within it).

Both the cost and accuracy of analogous and parametric models can vary widely. They

are most likely to be reliable when:

 Historical information used to develop the model is accurate,

 Parameters used in the model are readily quantifiable, and

 Models are scalable, such that they work for large projects, small projects, and phases

of a project.

7.3.2.5 Funding Limit Reconciliation

The expenditure of funds should be reconciled with any funding limits on the

commitment of funds for the project. A variance between the funding limits and the planned

expenditures will sometimes necessitate the rescheduling of work to level out the rate of

expenditures. This is accomplished by placing imposed date constraints for work into the project

schedule.

7.3.3 Determine Budget: Outputs

7.3.3.1 Cost Baseline

The cost baseline is the approved version of the time-phased project budget, excluding

any management reserves, which can only be changed through formal change control procedures

and is used as a basis for comparison to actual results. It is developed as a summation of the

approved budgets for the different schedule activities.

Figure 7-8 illustrates the various components of the project budget and cost baseline.

Activity cost estimates for the various project activities along with any contingency reserves

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

(Section 7.2.2.6) for these activities are aggregated into their associated work package costs. The

work package cost estimates, along with any contingency reserves estimated for the work

packages, are aggregated into control accounts. The summation of the control accounts make up

the cost baseline. Since the cost estimates that make up the cost baseline are directly tied to the

schedule activities, this enables a time-phased view of the cost baseline, which is typically

displayed in the form of an S-curve, as is illustrated in Figure 7-9.

Management reserves (Section 7.2.2.6) are added to the cost baseline to produce the

project budget. As changes warranting the use of management reserves arise, the change control

process is used to obtain approval to move the applicable management reserve funds into the cost

baseline.

Figure 7-8. Project Budget Components

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 7-9. Cost Baseline, Expenditures, and Funding Requirements

7.3.3.2 Project Funding Requirements

Total funding requirements and periodic funding requirements (e.g., quarterly, annually)

are derived from the cost baseline. The cost baseline will include projected expenditures plus

anticipated liabilities. Funding often occurs in incremental amounts that are not continuous, and

may not be evenly distributed, which appear as steps as shown in Figure 7-9. The total funds

required are those included in the cost baseline, plus management reserves, if any. Funding

requirements may include the source(s) of the funding.

7.3.3.3 Project Documents Updates

Project documents that may be updated include, but are not limited to:

 Risk register,

 Activity cost estimates, and

 Project schedule.

7.4 Control Costs

Control Costs is the process of monitoring the status of the project to update the project

costs and managing changes to the cost baseline. The key benefit of this process is that it

provides the means to recognize variance from the plan in order to take corrective action and

minimize risk. The inputs, tools and techniques, and outputs of this process are depicted in

Figure 7-10. Figure 7-11 depicts the data flow diagram of the process.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 7-10. Control Costs: Inputs, Tools & Techniques, and Outputs

Figure 7-11. Control Costs Data Flow Diagram

Updating the budget requires knowledge of the actual costs spent to date. Any increase to

the authorized budget can only be approved through the Perform Integrated Change Control

process (Section 4.5). Monitoring the expenditure of funds without regard to the value of work

being accomplished for such expenditures has little value to the project, other than to allow the

project team to stay within the authorized funding. Much of the effort of cost control involves

analyzing the relationship between the consumption of project funds to the physical work being

accomplished for such expenditures. The key to effective cost control is the management of the

approved cost baseline and the changes to that baseline.

Project cost control includes:

 Influencing the factors that create changes to the authorized cost baseline;

 Ensuring that all change requests are acted on in a timely manner;

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

 Managing the actual changes when and as they occur;

 Ensuring that cost expenditures do not exceed the authorized funding by period,

by WBS component, by activity, and in total for the project;

 Monitoring cost performance to isolate and understand variances from the

approved cost baseline;

 Monitoring work performance against funds expended;

 Preventing unapproved changes from being included in the reported cost or

resource usage;

 Informing appropriate stakeholders of all approved changes and associated cost;

and

 Bringing expected cost overruns within acceptable limits.

7.4.1 Control Costs: Inputs

7.4.1.1 Project Management Plan

Described in Section 4.2.3.1. The project management plan contains the following

information that is used to control cost:

 Cost baseline. The cost baseline is compared with actual results to determine if a

change, corrective action, or preventive action is necessary.

 Cost management plan. The cost management plan describes how the project costs

will be managed and controlled (Section 7.1.3.1).

7.4.1.2 Project Funding Requirements

Described in Section 7.3.3.2. The project funding requirements include projected

expenditures plus anticipated liabilities.

7.4.1.3 Work Performance Data

Described in Section 4.3.3.2. Work performance data includes information about project

progress, such as which activities have started, their progress, and which deliverables have

finished. Information also includes costs that have been authorized and incurred.

7.4.1.4 Organizational Process Assets

Described in Section 2.1.4. The organizational process assets that can influence the

Control Costs process include, but are not limited to:

 Existing formal and informal cost control-related policies, procedures, and guidelines;

 Cost control tools; and

 Monitoring and reporting methods to be used.

7.4.2 Control Costs: Tools and Techniques

7.4.2.1 Earned Value Management

Earned value management (EVM) is a methodology that combines scope, schedule, and

resource measurements to assess project performance and progress. It is a commonly used

method of performance measurement for projects. It integrates the scope baseline with the cost

baseline, along with the schedule baseline, to form the performance baseline, which helps the

project management team assess and measure project performance and progress. It is a project

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

management technique that requires the formation of an integrated baseline against which

performance can be measured for the duration of the project. The principles of EVM can be

applied to all projects in any industry. EVM develops and monitors three key dimensions for

each work package and control account:

 Planned value. Planned value (PV) is the authorized budget assigned to scheduled

work. It is the authorized budget planned for the work to be accomplished for an

activity or work breakdown structure component, not including management reserve.

This budget is allocated by phase over the life of the project, but at a given moment,

planned value defines the physical work that should have been accomplished. The

total of the PV is sometimes referred to as the performance measurement baseline

(PMB). The total planned value for the project is also known as budget at completion

(BAC).

 Earned value. Earned value (EV) is a measure of work performed expressed in terms

of the budget authorized for that work. It is the budget associated with the authorized

work that has been completed. The EV being measured needs to be related to the

PMB, and the EV measured cannot be greater than the authorized PV budget for a

component. The EV is often used to calculate the percent complete of a project.

Progress measurement criteria should be established for each WBS component to

measure work in progress. Project managers monitor EV, both incrementally to

determine current status and cumulatively to determine the long-term performance

trends.

 Actual cost. Actual cost (AC) is the realized cost incurred for the work performed on

an activity during a specific time period. It is the total cost incurred in accomplishing

the work that the EV measured. The AC needs to correspond in definition to what

was budgeted in the PV and measured in the EV (e.g., direct hours only, direct costs

only, or all costs including indirect costs). The AC will have no upper limit; whatever

is spent to achieve the EV will be measured.

Variances from the approved baseline will also be monitored:

 Schedule variance. Schedule variance (SV) is a measure of schedule performance

expressed as the difference between the earned value and the planned value. It is the

amount by which the project is ahead or behind the planned delivery date, at a given

point in time. It is a measure of schedule performance on a project. It is equal to the

earned value (EV) minus the planned value (PV). The EVM schedule variance is a

useful metric in that it can indicate when a project is falling behind or is ahead of its

baseline schedule. The EVM schedule variance will ultimately equal zero when the

project is completed because all of the planned values will have been earned.

Schedule variance is best used in conjunction with critical path methodology (CPM)

scheduling and risk management. Equation: SV = EV – PV

 Cost variance. Cost variance (CV) is the amount of budget deficit or surplus at a

given point in time, expressed as the difference between earned value and the actual

cost. It is a measure of cost performance on a project. It is equal to the earned value

(EV) minus the actual cost (AC). The cost variance at the end of the project will be

the difference between the budget at completion (BAC) and the actual amount spent.

The CV is particularly critical because it indicates the relationship of physical

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

performance to the costs spent. Negative CV is often difficult for the project to

recover. Equation: CV= EV − AC

The SV and CV values can be converted to efficiency indicators to reflect the cost

and schedule performance of any project for comparison against all other projects or

within a portfolio of projects. The variances are useful for determining project status.

 Schedule performance index. The schedule performance index (SPI) is a measure of

schedule efficiency expressed as the ratio of earned value to planned value. It

measures how efficiently the project team is using its time. It is sometimes used in

conjunction with the cost performance index (CPI) to forecast the final project

completion estimates. An SPI value less than 1.0 indicates less work was completed

than was planned. An SPI greater than 1.0 indicates that more work was completed

than was planned. Since the SPI measures all project work, the performance on the

critical path also needs to be analyzed to determine whether the project will finish

ahead of or behind its planned finish date. The SPI is equal to the ratio of the EV to

the PV. Equation: SPI = EV/PV

 Cost performance index. The cost performance index (CPI) is a measure of the cost

efficiency of budgeted resources, expressed as a ratio of earned value to actual cost. It

is considered the most critical EVM metric and measures the cost efficiency for the

work completed. A CPI value of less than 1.0 indicates a cost overrun for work

completed. A CPI value greater than 1.0 indicates a cost underrun of performance to

date. The CPI is equal to the ratio of the EV to the AC. The indices are useful for

determining project status and providing a basis for estimating project cost and

schedule outcome. Equation: CPI = EV/AC

The three parameters of planned value, earned value, and actual cost can be monitored

and reported on both a period-by-period basis (typically weekly or monthly) and on a cumulative

basis. Figure 7-12 uses S-curves to display EV data for a project that is performing over budget

and behind the schedule.

Figure 7-12. Earned Value, Planned Value, and Actual Costs

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

7.4.2.2 Forecasting

As the project progresses, the project team may develop a forecast for the estimate at

completion (EAC) that may differ from the budget at completion (BAC) based on the project

performance. If it becomes obvious that the BAC is no longer viable, the project manager should

consider the forecasted EAC. Forecasting the EAC involves making projections of conditions

and events in the project’s future based on current performance information and other knowledge

available at the time of the forecast. Forecasts are generated, updated, and reissued based on

work performance data (Section 4.3.3.2) that is provided as the project is executed. The work

performance information covers the project’s past performance and any information that could

impact the project in the future.

EACs are typically based on the actual costs incurred for work completed, plus an

estimate to complete (ETC) the remaining work. It is incumbent on the project team to predict

what it may encounter to perform the ETC, based on its experience to date. The EVM method

works well in conjunction with manual forecasts of the required EAC costs. The most common

EAC forecasting approach is a manual, bottom-up summation by the project manager and project

team.

The project manager’s bottom-up EAC method builds upon the actual costs and

experience incurred for the work completed, and requires a new estimate to complete the

remaining project work. Equation: EAC = AC + Bottom-up ETC.

The project manager’s manual EAC is quickly compared with a range of calculated

EACs representing various risk scenarios. When calculating EAC values, the cumulative CPI and

SPI values are typically used. While EVM data quickly provide many statistical EACs, only

three of the more common methods are described as follows:

 EAC forecast for ETC work performed at the budgeted rate. This EAC method

accepts the actual project performance to date (whether favorable or unfavorable) as

represented by the actual costs, and predicts that all future ETC work will be

accomplished at the budgeted rate. When actual performance is unfavorable, the

assumption that future performance will improve should be accepted only when

supported by project risk analysis. Equation: EAC = AC + (BAC – EV)

 EAC forecast for ETC work performed at the present CPI. This method assumes

what the project has experienced to date can be expected to continue in the future.

The ETC work is assumed to be performed at the same cumulative cost performance

index (CPI) as that incurred by the project to date. Equation: EAC = BAC / CPI

 EAC forecast for ETC work considering both SPI and CPI factors. In this

forecast, the ETC work will be performed at an efficiency rate that considers both the

cost and schedule performance indices. This method is most useful when the project

schedule is a factor impacting the ETC effort. Variations of this method weight the

CPI and SPI at different values (e.g., 80/20, 50/50, or some other ratio) according to

the project manager’s judgment. Equation: EAC = AC + [(BAC – EV) / (CPI × SPI)]

Each of these approaches is applicable for any given project and will provide the project

management team with an “early warning” signal if the EAC forecasts are not within acceptable

tolerances.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

7.4.2.3 To-Complete Performance Index (TCPI)

The to-complete performance index (TCPI) is a measure of the cost performance that is

required to be achieved with the remaining resources in order to meet a specified management

goal, expressed as the ratio of the cost to finish the outstanding work to the remaining budget.

TCPI is the calculated cost performance index that is achieved on the remaining work to meet a

specified management goal, such as the BAC or the EAC. If it becomes obvious that the BAC is

no longer viable, the project manager should consider the forecasted EAC. Once approved, the

EAC may replace the BAC in the TCPI calculation. The equation for the TCPI based on the

BAC: (BAC – EV) / (BAC – AC).

The TCPI is conceptually displayed in Figure 7-13. The equation for the TCPI is shown

in the lower left as the work remaining (defined as the BAC minus the EV) divided by the funds

remaining (which can be either the BAC minus the AC, or the EAC minus the AC).

If the cumulative CPI falls below the baseline (as shown in Figure 7-13), all future work

of the project will need to be performed immediately in the range of the TCPI (BAC) (as

reflected in the top line of Figure 7-13) to stay within the authorized BAC. Whether this level of

performance is achievable is a judgment call based on a number of considerations, including risk,

schedule, and technical performance. This level of performance is displayed as the TCPI (EAC)

line. The equation for the TCPI based on the EAC: (BAC – EV) / (EAC – AC). The EVM

formulas are provided in Table 7-1.

Figure 7-13. To-Complete Performance Index (TCPI)

7.4.2.4 Performance Reviews

Performance reviews compare cost performance over time, schedule activities or work

packages overrunning and underrunning the budget, and estimated funds needed to complete

work in progress. If EVM is being used, the following information is determined:

 Variance analysis. Variance analysis, as used in EVM, is the explanation (cause,

impact, and corrective actions) for cost (CV = EV – AC), schedule (SV = EV – PV),

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

and variance at completion (VAC = BAC – EAC) variances. Cost and schedule

variances are the most frequently analyzed measurements. For projects not using

earned value management, similar variance analyses can be performed by comparing

planned activity cost against actual activity cost to identify variances between the cost

baseline and actual project performance. Further analysis can be performed to

determine the cause and degree of variance relative to the schedule baseline and any

corrective or preventative actions needed. Cost performance measurements are used

to assess the magnitude of variation to the original cost baseline. An important aspect

of project cost control includes determining the cause and degree of variance relative

to the cost baseline (Section 7.3.3.1) and deciding whether corrective or preventive

action is required. The percentage range of acceptable variances will tend to decrease

as more work is accomplished.

 Trend analysis. Trend analysis examines project performance over time to determine

if performance is improving or deteriorating. Graphical analysis techniques are

valuable for understanding performance to date and for comparison to future

performance goals in the form of BAC versus EAC and completion dates.

 Earned value performance. Earned value performance compares the performance

measurement baseline to actual schedule and cost performance. If EVM is not being

used, then the analysis of the cost baseline against actual costs for the work

performed is used for cost performance comparisons.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Table 7-1. Earned Value Calculations Summary Table

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

7.4.2.5 Project Management Software

Project management software is often used to monitor the three EVM dimensions (PV,

EV, and AC), to display graphical trends, and to forecast a range of possible final project results.

7.4.2.6 Reserve Analysis

During cost control, reserve analysis is used to monitor the status of contingency and

management reserves for the project to determine if these reserves are still needed or if

additional reserves need to be requested. As work on the project progresses, these reserves may

be used as planned to cover the cost of risk mitigation events or other contingencies. Or, if the

probable risk events do not occur, the unused contingency reserves may be removed from the

project budget to free up resources for other projects or operations. Additional risk analysis

during the project may reveal a need to request that additional reserves be added to the project

budget. Management and contingency reserves are addressed in more detail in Section 7.2.2.6.

7.4.3 Control Costs: Outputs

7.4.3.1 Work Performance Information

The calculated CV, SV, CPI, SPI, TCPI, and VAC values for WBS components, in

particular the work packages and control accounts, are documented and communicated to

stakeholders.

7.4.3.2 Cost Forecasts

Either a calculated EAC value or a bottom-up EAC value is documented and

communicated to stakeholders.

7.4.3.3 Change Requests

Analysis of project performance may result in a change request to the cost baseline or

other components of the project management plan. Change requests may include preventive or

corrective actions, and are processed for review and disposition through the Perform Integrated

Change Control process (Section 4.5).

7.4.3.4 Project Management Plan Updates

Elements of the project management plan that may be updated include, but are not

limited to:

 Cost baseline. Changes to the cost baseline are incorporated in response to approved

changes in scope, activity resources, or cost estimates. In some cases, cost variances

can be so severe that a revised cost baseline is needed to provide a realistic basis for

performance measurement.

 Cost management plan. Changes to the cost management plan, such as changes to

control thresholds or specified levels of accuracy required in managing the project’s

cost, are incorporated in response to feedback from relevant stakeholders.

7.4.3.5 Project Documents Updates

Project documents that may be updated include, but are not limited to:

 Cost estimates, and

 Basis of estimates.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

7.4.3.6 Organizational Process Assets Updates

Organizational process assets that may be updated include, but are not limited to:

 Causes of variances,

 Corrective action chosen and the reasons,

 Financial databases, and

 Other types of lessons learned from project cost control.



PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

PROJECT

QUALITY MANAGEMENT

Project Quality Management includes the processes and activities of the performing

organization that determine quality policies, objectives, and responsibilities so that the project

will satisfy the needs for which it was undertaken. Project Quality Management uses policies and

procedures to implement, within the project’s context, the organization’s quality management

system and, as appropriate, it supports continuous process improvement activities as undertaken

on behalf of the performing organization. Project Quality Management works to ensure that the

project requirements, including product requirements, are met and validated.

Figure 8-1 provides an overview of the Project Quality Management processes, which

include:

8.1 Plan Quality Management—The process of identifying quality requirements and/or

standards for the project and its deliverables and documenting how the project will demonstrate

compliance with quality requirements.

8.2 Perform Quality Assurance—The process of auditing the quality requirements and

the results from quality control measurements to ensure that appropriate quality standards and

operational definitions are used.

8.3 Control Quality—The process of monitoring and recording results of executing the

quality activities to assess performance and recommend necessary changes.

These processes interact with each other and with processes in other Knowledge Areas as

described in detail in Section 3 and Annex A1.

Project Quality Management addresses the management of the project and the

deliverables of the project. It applies to all projects, regardless of the nature of their deliverables.

Quality measures and techniques are specific to the type of deliverables being produced by the

project. For example, the project quality management of software deliverables may use different

approaches and measures from those used when building a nuclear power plant. In either case,

failure to meet the quality requirements can have serious, negative consequences for any or all of

the project’s stakeholders. For example:

 Meeting customer requirements by overworking the project team may result in

decreased profits and increased project risks, employee attrition, errors, or rework.

 Meeting project schedule objectives by rushing planned quality inspections may

result in undetected errors, decreased profits, and increased post-implementation

risks.

Quality and grade are not the same concepts. Quality as a delivered performance or result

is “the degree to which a set of inherent characteristics fulfill requirements. (ISO 9000)” Grade

as a design intent is a category assigned to deliverables having the same functional use but

different technical characteristics. The project manager and the project management team are

responsible for managing the tradeoffs associated with delivering the required levels of both

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

quality and grade. While a quality level that fails to meet quality requirements is always a

problem, a low grade of quality may not be a problem. For example:

 It may not be a problem if a suitable low-grade software product (one with a limited

number of features) is of high quality (no obvious defects, readable manual). In this

example, the product would be appropriate for its general purpose of use.

 It may be a problem if a high-grade software product (one with numerous features) is

of low quality (many defects, poorly organized user documentation). In essence, its

high-grade feature set would prove ineffective and/or inefficient due to its low

quality.

The project management team should determine the appropriate levels of accuracy and

precision for use in the quality management plan. Precision is a measure of exactness. For

example, the magnitude for each increment on the measurement’s number line is the interval that

determines the measurement’s precision—the greater the number of increments, the greater the

precision. Accuracy is an assessment of correctness. For example, if the measured value of an

item is very close to the true value of the characteristic being measured, the measurement is more

accurate. An illustration of this concept is the comparison of archery targets. Arrows clustered

tightly in one area of the target, even if they are not clustered in the bull’s-eye, are considered to

have high precision. Targets where the arrows are more spread out but equidistant from the

bull’s-eye are considered to have the same degree of accuracy. Targets where the arrows are both

tightly grouped and within the bull’s-eye are considered to be both accurate and precise. Precise

measurements are not necessarily accurate measurements, and accurate measurements are not

necessarily precise measurements.

The basic approach to project quality management as described in this section is intended

to be compatible with that of the International Organization for Standardization (ISO) quality

standards. Every project should have a quality management plan. Project teams should follow the

quality management plan and should have data to demonstrate compliance with the plan.

In the context of achieving ISO compatibility, modern quality management approaches

seek to minimize variation and to deliver results that meet defined requirements. These

approaches recognize the importance of:

 Customer satisfaction. Understanding, evaluating, defining, and managing

requirements so that customer expectations are met. This requires a combination of

conformance to requirements (to ensure the project produces what it was created to

produce) and fitness for use (the product or service needs to satisfy the real needs).

 Prevention over inspection. Quality should be planned, designed, and built into—

not inspected into the project’s management or the project’s deliverables. The cost of

preventing mistakes is generally much less than the cost of correcting mistakes when

they are found by inspection or during usage.

 Continuous improvement. The PDCA (plan-do-check-act) cycle is the basis for

quality improvement as defined by Shewhart and modified by Deming. In addition,

quality improvement initiatives such as Total Quality Management (TQM), Six

Sigma, and Lean Six Sigma could improve the quality of the project’s management as

well as the quality of the project’s product. Commonly used process improvement

models include Malcolm Baldrige, Organizational Project Management Maturity

Model (OPM3

), and Capability Maturity Model Integrated (CMMI

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

 Management Responsibility. Success requires the participation of all members of

the project team. Nevertheless, management retains, within its responsibility for

quality, a related responsibility to provide suitable resources at adequate capacities.

 Cost of quality (COQ). Cost of quality refers to the total cost of the conformance

work and the nonconformance work that should be done as a compensatory effort

because, on the first attempt to perform that work, the potential exists that some

portion of the required work effort may be done or has been done incorrectly. The

costs for quality work may be incurred throughout the deliverable’s life cycle. For

example, decisions made by the project team can impact the operational costs

associated with using a completed deliverable. Post-project quality costs may be

incurred because of product returns, warranty claims, and recall campaigns.

Therefore, because of the temporary nature of projects and the potential benefits that

may be derived from reducing the post-project cost of quality, sponsoring

organizations may choose to invest in product quality improvement. These

investments generally are made in the areas of conformance work that act to prevent

defects or act to mitigate the costs of defects by inspecting out nonconforming units.

Refer to Figure 8-2 and Section 8.1.2.2. Moreover, the issues related to post-project

COQ should be the concern of program management and portfolio management such

that project, program, and portfolio management offices should apply appropriate

reviews, templates, and funding allocations for this purpose.

Figure 8-1. Project Quality Management Overview

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 8-2. Fundamental Relationships of Quality Assurance and Control Quality to the IPECC,

PDCA, Cost of Quality Models and Project Management Process Groups

8.1 Plan Quality Management

Plan Quality Management is the process of identifying quality requirements and/or

standards for the project and its deliverables, and documenting how the project will demonstrate

compliance with relevant quality requirements. The key benefit of this process is that it provides

guidance and direction on how quality will be managed and validated throughout the project.

The inputs, tools and techniques, and outputs of this process are depicted in Figure 8-3. Figure 8-

4 depicts the data flow diagram of the process.

Figure 8-3. Plan Quality Management Inputs, Tools & Techniques, and Outputs

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 8-4. Plan Quality Management Data Flow Diagram

Quality planning should be performed in parallel with the other planning processes. For

example, proposed changes in the deliverables to meet identified quality standards may require

cost or schedule adjustments and a detailed risk analysis of the impact to plans.

The quality planning techniques discussed here are those used most frequently on

projects. There are many others that may be useful on certain projects or in some application

areas.

8.1.1 Plan Quality Management: Inputs

8.1.1.1 Project Management Plan

Described in Section 4.2.3.1. The project management plan is used to develop the quality

management plan. The information used for the development of the quality management plan

includes, but is not limited to:

 Scope baseline. The scope baseline (Section 5.4.3.1) includes:

o Project scope statement. The project scope statement contains the project

description, major project deliverables, and acceptance criteria. The product scope

often contains details of technical issues and other concerns that can affect quality

planning and that should have been identified as a result of the planning processes

in Project Scope Management. The definition of acceptance criteria may

significantly increase or decrease quality costs and therefore, project costs.

Satisfying all acceptance criteria that the needs of the sponsor and/or customer

have been met.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

o Work breakdown structure (WBS). The WBS identifies the deliverables and the

work packages used to measure project performance.

o WBS dictionary. The WBS dictionary provides detailed information for WBS

elements.

 Schedule baseline. The schedule baseline documents the accepted schedule

performance measures, including start and finish dates (Section 6.6.3.1).

 Cost baseline. The cost baseline documents the accepted time interval being used to

measure cost performance (Section 7.3.3.1).

 Other management plans. These plans contribute to the overall project quality and

may highlight actionable areas of concern with regard to the project’s quality.

8.1.1.2 Stakeholder Register

Described in Section 13.1.3.1. The stakeholder register aids in identifying those

stakeholders possessing a particular interest in, or having an impact on, quality.

8.1.1.3 Risk Register

Described in Section 11.2.3.1. The risk register contains information on threats and

opportunities that may impact quality requirements.

8.1.1.4 Requirements Documentation

Described in Section 5.2.3.1. Requirements documentation captures the requirements that

the project shall meet pertaining to stakeholder expectations. The components of the

requirements documentation include, but are not limited to, project (including product) and

quality requirements. The requirements are used by the project team to help plan how quality

control will be implemented on the project.

8.1.1.5 Enterprise Environmental Factors

Described in Section 2.1.5. The enterprise environmental factors that influence the Plan

Quality Management process include, but are not limited to:

 Governmental agency regulations;

 Rules, standards, and guidelines specific to the application area;

 Working or operating conditions of the project or its deliverables that may affect

project quality; and

 Cultural perceptions that may influence expectations about quality.

8.1.1.6 Organizational Process Assets

Described in Section 2.1.4. The organizational process assets that influence the Plan

Quality Management process include, but are not limited to:

 Organizational quality policies, procedures, and guidelines. The performing

organization’s quality policy, as endorsed by senior management, sets the

organization’s intended direction on implementing its quality management approach.

 Historical databases; and

 Lessons learned from previous phases or projects.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

8.1.2 Plan Quality Management: Tools and Techniques

8.1.2.1 Cost-Benefit Analysis

The primary benefits of meeting quality requirements include less rework, higher

productivity, lower costs, increased stakeholder satisfaction, and increased profitability. A cost-

benefit analysis for each quality activity compares the cost of the quality step to the expected

benefit.

8.1.2.2 Cost of Quality (COQ)

Cost of quality includes all costs incurred over the life of the product by investment in

preventing nonconformance to requirements, appraising the product or service for conformance

to requirements, and failing to meet requirements (rework). Failure costs are often categorized

into internal (found by the project) and external (found by the customer). Failure costs are also

called cost of poor quality. Figure 8-5 provides some examples to consider in each area.

Figure 8-5. Cost of Quality

8.1.2.3 Seven Basic Quality Tools

The seven basic quality tools, also known in the industry as 7QC Tools, are used within

the context of the PDCA Cycle to solve quality-related problems. As conceptually illustrated in

Figure 8-7, the seven basic quality tools are:

 Cause-and-effect diagrams, which are also known as fishbone diagrams or as

Ishikawa diagrams. The problem statement placed at the head of the fishbone is used

as a starting point to trace the problem’s source back to its actionable root cause. The

problem statement typically describes the problem as a gap to be closed or as an

objective to be achieved. The causes are found by looking at the problem statement

and asking “why” until the actionable root cause has been identified or until the

reasonable possibilities on each fishbone have been exhausted. Fishbone diagrams

often prove useful in linking the undesirable effects seen as special variation to the

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

assignable cause on which project teams should implement corrective actions to

eliminate the special variation detected in a control chart.

 Flowcharts, which are also referred to as process maps because they display the

sequence of steps and the branching possibilities that exist for a process that

transforms one or more inputs into one or more outputs. Flowcharts show the

activities, decision points, branching loops, parallel paths, and the overall order of

processing by mapping the operational details of procedures that exist within a

horizontal value chain of a SIPOC model (Figure 8-6). Flowcharts may prove useful

in understanding and estimating the cost of quality in a process. This is obtained by

using the workflow branching logic and associated relative frequencies to estimate

expected monetary value for the conformance and nonconformance work required to

deliver the expected conforming output.

Figure8‐6.TheSIPOCModel

 Checksheets, which are also known as tally sheets and may be used as a checklist

when gathering data. Checksheets are used to organize facts in a manner that will

facilitate the effective collection of useful data about a potential quality problem.

They are especially useful for gathering attributes data while performing inspections

to identify defects. For example, data about the frequencies or consequences of

defects collected in checksheets are often displayed using Pareto diagrams.

 Pareto diagrams, exist as a special form of vertical bar chart and are used to identify

the vital few sources that are responsible for causing most of a problem’s effects. The

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

categories shown on the horizontal axis exist as a valid probability distribution that

accounts for 100% of the possible observations. The relative frequencies of each

specified cause listed on the horizontal axis decrease in magnitude until the default

source named “other” accounts for any nonspecified causes. Typically, the Pareto

diagram will be organized into categories that measure either frequencies or

consequences.

 Histograms, are a special form of bar chart and are used to describe the central

tendency, dispersion, and shape of a statistical distribution. Unlike the control chart,

the histogram does not consider the influence of time on the variation that exists

within a distribution.

 Control charts, are used to determine whether or not a process is stable or has

predictable performance. Upper and lower specification limits are based on

requirements of the agreement. They reflect the maximum and minimum values

allowed. There may be penalties associated with exceeding the specification limits.

Upper and lower control limits are different from specification limits. The control

limits are determined using standard statistical calculations and principles to

ultimately establish the natural capability for a stable process. The project manager

and appropriate stakeholders may use the statistically calculated control limits to

identify the points at which corrective action will be taken to prevent unnatural

performance. The corrective action typically seeks to maintain the natural stability of

a stable and capable process. For repetitive processes, the control limits are generally

set at ±3 s around a process mean that has been set at 0 s. A process is considered out

of control when: (1) a data point exceeds a control limit; (2) seven consecutive plot

points are above the mean; or (3) seven consecutive plot points are below the mean.

Control charts can be used to monitor various types of output variables. Although

used most frequently to track repetitive activities required for producing

manufactured lots, control charts may also be used to monitor cost and schedule

variances, volume, and frequency of scope changes, or other management results to

help determine if the project management processes are in control.

 Scatter diagrams, plot ordered pairs (X, Y) and are sometimes called correlation

charts because they seek to explain a change in the dependent variable, Y, in

relationship to a change observed in the corresponding independent variable, X. The

direction of correlation may be proportional (positive correlation), inverse (negative

correlation), or a pattern of correlation may not exist (zero correlation). If correlation

can be established, a regression line can be calculated and used to estimate how a

change to the independent variable will influence the value of the dependent variable.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 8-7. Storyboard Illustrating a Conceptual Example of Each of the Seven Basic Quality Tools

8.1.2.4 Benchmarking

Benchmarking involves comparing actual or planned project practices to those of

comparable projects to identify best practices, generate ideas for improvement, and provide a

basis for measuring performance.

Benchmarked projects may exist within the performing organization or outside of it, or

can be within the same application area. Benchmarking allows for analogies from projects in a

different application area to be made.

8.1.2.5 Design of Experiments

Design of experiments (DOE) is a statistical method for identifying which factors may

influence specific variables of a product or process under development or in production. DOE

may be used during the Plan Quality Management process to determine the number and type of

tests and their impact on cost of quality.

DOE also plays a role in optimizing products or processes. DOE is used to reduce the

sensitivity of product performance to sources of variations caused by environmental or

manufacturing differences. One important aspect of this technique is that it provides a statistical

framework for systematically changing all of the important factors, rather than changing the

factors one at a time. Analysis of the experimental data should provide the optimal conditions for

the product or process, highlight the factors that influence the results, and reveal the presence of

interactions and synergy among the factors. For example, automotive designers use this

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

technique to determine which combination of suspension and tires will produce the most

desirable ride characteristics at a reasonable cost.

8.1.2.6 Statistical Sampling

Statistical sampling involves choosing part of a population of interest for inspection (for

example, selecting ten engineering drawings at random from a list of seventy-five). Sample

frequency and sizes should be determined during the Plan Quality Management process so the

cost of quality will include the number of tests, expected scrap, etc.

There is a substantial body of knowledge on statistical sampling. In some application

areas, it may be necessary for the project management team to be familiar with a variety of

sampling techniques to assure the sample selected represents the population of interest.

8.1.2.7 Additional Quality Planning Tools

Other quality planning tools are used to define the quality requirements and to plan

effective quality management activities. These include, but are not limited to:

 Brainstorming. This technique is used to generate ideas (defined in Section

11.2.2.2).

 Force field analysis. These are diagrams of the forces for and against change.

 Nominal group technique. This technique is used to allow ideas to be brainstormed

in small groups and then reviewed by a larger group.

 Quality management and control tools. These tools are used to link and sequence

the activities identified (defined in Section 8.2.2.1).

8.1.2.8 Meetings

Project teams may hold planning meetings to develop the quality management plan.

Attendees at these meetings may include the project manager; the project sponsor; selected

project team members; selected stakeholders; anyone with responsibility for Project Quality

Management activities namely Plan Quality Management, Perform Quality Assurance, or

Control Quality; and others as needed.

8.1.3 Plan Quality Management: Outputs

8.1.3.1 Quality Management Plan

The quality management plan is a component of the project management plan that

describes how the organization’s quality policies will be implemented. It describes how the

project management team plans to meet the quality requirements set for the project.

The quality management plan may be formal or informal, detailed, or broadly framed.

The style and detail of the quality management plan are determined by the requirements of the

project. The quality management plan should be reviewed early in the project to ensure that

decisions are based on accurate information. The benefits of this review can include a sharper

focus on the project’s value proposition and reductions in costs and in the frequency of schedule

overruns that were caused by rework.

8.1.3.2 Process Improvement Plan

The process improvement plan is a subsidiary or component of the project management

plan (Section 4.2.3.1). The process improvement plan details the steps for analyzing project

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

management and product development processes to identify activities that enhance their value.

Areas to consider include:

 Process boundaries. Describe the purpose of the process, the start and end of the

process, its inputs and outputs, the process owner, and the stakeholders of the process.

 Process configuration. Provides a graphic depiction of processes, with interfaces

identified, used to facilitate analysis.

 Process metrics. Along with control limits, allows analysis of process efficiency.

 Targets for improved performance. Guide the process improvement activities.

8.1.3.3 Quality Metrics

A quality metric specifically describes a project or product attribute and how the control

quality process will measure it. A measurement is an actual value. The tolerance defines the

allowable variations to the metric. For example, if the quality objective is to stay within the

approved budget by ± 10%, the specific quality metric is used to measure the cost of every

deliverable and determine the percent variance from the approved budget for that deliverable.

Quality metrics are used in the perform quality assurance and control quality processes. Some

examples of quality metrics include on-time performance, cost control, defect frequency, failure

rate, availability, reliability, and test coverage.

8.1.3.4 Quality Checklists

A checklist is a structured tool, usually component-specific, used to verify that a set of

required steps has been performed. Based on the project’s requirements and practices, checklists

may be simple or complex. Many organizations have standardized checklists available to ensure

consistency in frequently performed tasks. In some application areas, checklists are also

available from professional associations or commercial service providers. Quality checklists

should incorporate the acceptance criteria included in the scope baseline.

8.1.3.5 Project Documents Updates

Project documents that may be updated include, but are not limited to:

 Stakeholder register (Section 13.1.3.1); and

 Responsibility assignment matrix (Section 9.1.2.1); and

 WBS and WBS Dictionary.

8.2 Perform Quality Assurance

Perform Quality Assurance is the process of auditing the quality requirements and the

results from quality control measurements to ensure that appropriate quality standards and

operational definitions are used. The key benefit of this process is that it facilitates the

improvement of quality processes. The inputs, tools and techniques, and outputs of this process

are depicted in Figure 8-8. Figure 8-9 depicts the data flow diagram of the process.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 8-8. Perform Quality Assurance: Inputs, Tools & Techniques, and Outputs

Figure 8-9. Perform Quality Assurance Data Flow Diagram

The quality assurance process implements a set of planned and systematic acts and

processes defined within the project’s quality management plan. Quality assurance seeks to build

confidence that a future output or an unfinished output, also known as work in progress, will be

completed in a manner that meets the specified requirements and expectations. Quality assurance

contributes to the state of being certain about quality by preventing defects through the planning

processes or by inspecting out defects during the work-in-progress stage of implementation.

Perform Quality Assurance is an execution process that uses data created during Plan Quality

Management (Section 8.1) and Control Quality (Section 8.3) processes.

In project management, the prevention and inspection aspects of quality assurance should

have a demonstrable influence on the project. Quality assurance work will fall under the

conformance work category in the cost of quality framework.

A quality assurance department, or similar organization, often oversees quality assurance

activities. Quality assurance support, regardless of the unit’s title, may be provided to the project

team, the management of the performing organization, the customer or sponsor, as well as other

stakeholders not actively involved in the work of the project.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Perform Quality Assurance also provides an umbrella for continuous process

improvement, which is an iterative means for improving the quality of all processes. Continuous

process improvement reduces waste and eliminates activities that do not add value. This allows

processes to operate at increased levels of efficiency and effectiveness.

8.2.1 Perform Quality Assurance: Inputs

8.2.1.1 Quality Management Plan

Described in Section 8.1.3.1. The quality management plan describes the quality

assurance and continuous process improvement approaches for the project.

8.2.1.2 Process Improvement Plan

Described in Section 8.1.3.2. The project’s quality assurance activities should be

supportive of and consistent with the performing organization’s process improvement plans.

8.2.1.3 Quality Metrics

Described in Section 8.1.3.3. The quality metrics provide the attributes that should be

measured and the allowable variations.

8.2.1.4 Quality Control Measurements

Described in Section 8.3.3.1. Quality control measurements are the results of control

quality activities. They are used to analyze and evaluate the quality of the processes of the

project against the standards of the performing organization or the requirements specified.

Quality control measurements can also compare the processes used to create the measurements,

and validate actual measurements to determine their level of correctness.

8.2.1.5 Project Documents

Project documents may influence quality assurance work and should be monitored within

the context of a system for configuration management.

8.2.2 Perform Quality Assurance: Tools and Techniques

8.2.2.1 Quality Management and Control Tools

The Perform Quality Assurance process uses the tools and techniques of the Plan Quality

Management and Control Quality processes. In addition, other tools that are available include

(see also Figure 8-10):

 Affinity diagrams. The affinity diagram is similar to mind-mapping techniques in

that they are used to generate ideas that can be linked to form organized patterns of

thought about a problem. In project management, the creation of the WBS may be

enhanced by using the affinity diagram to give structure to the decomposition of

scope.

 Process decision program charts (PDPC). Used to understand a goal in relation to

the steps for getting to the goal. The PDPC is useful as a method for contingency

planning because it aids teams in anticipating intermediate steps that could derail

achievement of the goal.

 Interrelationship digraphs. An adaptation of relationship diagrams. The

interrelationship digraphs provide a process for creative problem solving in

moderately complex scenarios that possess intertwined logical relationships for up to

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

50 relevant items. The interrelationship digraph may be developed from data

generated in other tools such as the affinity diagram, the tree diagram, or the fishbone

diagram.

 Tree diagrams. Also known as systematic diagrams and may be used to represent

decomposition hierarchies such as the WBS, RBS (risk breakdown structure), and

OBS (organizational breakdown structure). In project management, tree diagrams are

useful in visualizing the parent-to-child relationships in any decomposition hierarchy

that uses a systematic set of rules that define a nesting relationship. Tree diagrams can

be depicted horizontally (such as a risk breakdown structure) or vertically (such as a

team hierarchy or OBS). Because tree diagrams permit the creation of nested

branches that terminate into a single decision point, they are useful as decision trees

for establishing an expected value for a limited number of dependent relationships

that have been diagramed systematically.

 Prioritization matrices. Identify the key issues and the suitable alternatives to be

prioritized as a set of decisions for implementation. Criteria are prioritized and

weighted before being applied to all available alternatives to obtain a mathematical

score that ranks the options.

 Activity network diagrams. Previously known as arrow diagrams. They include

both the AOA (Activity on Arrow) and, most commonly used, AON (Activity on

Node) formats of a network diagram. Activity network diagrams are used with project

scheduling methodologies such as program evaluation and review technique (PERT),

critical path method (CPM), and precedence diagramming method (PDM).

 Matrix diagrams. A quality management and control tool used to perform data

analysis within the organizational structure created in the matrix. The matrix diagram

seeks to show the strength of relationships between factors, causes, and objectives

that exist between the rows and columns that form the matrix.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 8-10. Storyboard illustrating the seven quality management and control tools

8.2.2.2 Quality Audits

A quality audit is a structured, independent process to determine if project activities

comply with organizational and project policies, processes, and procedures. The objectives of a

quality audit may include:

 Identify all good and best practices being implemented;

 Identify all nonconformity, gaps, and shortcomings;

 Share good practices introduced or implemented in similar projects in the

organization and/or industry;

 Proactively offer assistance in a positive manner to improve implementation of

processes to help the team raise productivity; and

 Highlight contributions of each audit in the lessons learned repository of the

organization.

The subsequent effort to correct any deficiencies should result in a reduced cost of quality

and an increase in sponsor or customer acceptance of the project’s product. Quality audits may

be scheduled or random, and may be conducted by internal or external auditors.

Quality audits can confirm the implementation of approved change requests including

updates, corrective actions, defect repairs, and preventive actions.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

8.2.2.3 Process Analysis

Process analysis follows the steps outlined in the process improvement plan to identify

needed improvements. This analysis also examines problems experienced, constraints

experienced, and non-value-added activities identified during process operation. Process analysis

includes root cause analysis—a specific technique used to identify a problem, discover the

underlying causes that lead to it, and develop preventive actions.

8.2.3 Perform Quality Assurance: Outputs

8.2.3.1 Change Requests

Change requests are created and used as input into the Perform Integrated Change

Control process (Section 4.5) to allow full consideration of the recommended improvements.

Change requests are used to take corrective action, preventive action, or to perform defect repair.

8.2.3.2 Project Management Plan Updates

Elements of the project management plan that may be updated include, but are not

limited to:

 Quality management plan (Section 8.1.3.1),

 Scope management plan (Section 5.1.3.1),

 Schedule management plan (Section 6.1.3.1), and

 Cost management plan (7.1.3.1).

8.2.3.3 Project Documents Updates

Project documents that may be updated include, but are not limited to:

 Quality audit reports,

 Training plans, and

 Process documentation.

8.2.3.4 Organizational Process Assets Updates

Elements of the organizational process assets that may be updated include, but are not

limited to, the organization’s quality standards and the quality management system.

8.3 Control Quality

Control Quality is the process of monitoring and recording results of executing the

quality activities to assess performance and recommend necessary changes. The key benefits of

this process include: (1) identifying the causes of poor process or product quality and

recommending and/or taking action to eliminate them; and (2) validating that project deliverables

and work meet the requirements specified by key stakeholders necessary for final acceptance.

The inputs, tools and techniques, and outputs of this process are depicted in Figure 8-11. Figure

8-12 depicts the data flow diagram of the process.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 8-11. Control Quality: Inputs, Tools & Techniques, and Outputs

Figure 8-12. Control Quality Data Flow Diagram

The Control Quality process uses a set of operational techniques and tasks to verify that

the delivered output will meet the requirements. Quality assurance should be used during the

project’s planning and executing phases to provide confidence that the stakeholder’s

requirements will be met and quality control should be used during the project executing and

closing phases to formally demonstrate, with reliable data, that the sponsor and/or customer’s

acceptance criteria have been met.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

The project management team may have a working knowledge of statistical control

processes to evaluate data contained in the control quality outputs. Among other subjects, the

team may find it useful to know the differences between the following pairs of terms:

 Prevention (keeping errors out of the process) and inspection (keeping errors out of

the hands of the customer).

 Attribute sampling (the result either conforms or does not conform) and variables

sampling (the result is rated on a continuous scale that measures the degree of

conformity).

 Tolerances (specified range of acceptable results) and control limits (that identify the

boundaries of common variation in a statistically stable process or process

performance).

8.3.1 Control Quality: Inputs

8.3.1.1 Project Management Plan

Described in Section 8.1.3.1. The project management plan contains the quality

management plan, which is used to control quality. The quality management plan describes how

quality control will be performed within the project.

8.3.1.2 Quality Metrics

Described in Section 4.2.3.1. A quality metric describes a project or product attribute and

how it will be measured. Some examples of quality metrics include: function points, mean time

between failure (MTBF), and mean time to repair (MTTR).

8.3.1.3 Quality Checklists

Described in Section 8.1.3.4. Quality checklists are structured lists that help to verify that

the work of the project and its deliverables fulfill a set of requirements.

8.3.1.4 Work Performance Data

Described in Section 4.3.3.2. Work performance data can include:

 Planned vs. actual technical performance,

 Planned vs. actual schedule performance, and

 Planned vs. actual cost performance.

8.3.1.5 Approved Change Requests

As part of the Perform Integrated Change Control process, a change log update indicates

that some changes are approved and some are not. Approved change requests may include

modifications such as defect repairs, revised work methods, and revised schedule. The timely

implementation of approved changes needs to be verified.

8.3.1.6 Deliverables

Described in Section 4.3.3.1. A deliverable is any unique and verifiable product, result, or

capability that results in a validated deliverable required by the project.

8.3.1.7 Project Documents

Project documents may include, but are not limited to:

 Agreements,

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

 Quality audit reports and change logs supported with corrective action plans,

 Training plans and assessments of effectiveness, and

 Process documentation such as those obtained using either the seven basic quality

tools or the quality management and control tools shown in Figures 8-7 and 8-10.

8.3.1.8 Organizational Process Assets

Described in Section 2.1.4. The organizational process assets that influence the Control

Quality process include, but are not limited to:

 The organization’s quality standards and policies,

 Standard work guidelines, and

 Issue and defect reporting procedures and communication policies.

8.3.2 Control Quality: Tools and Techniques

8.3.2.1 Seven Basic Quality Tools

Described in Section 8.1.2.3. The seven basic quality tools are illustrated conceptually in

Figure 8-7.

8.3.2.2 Statistical Sampling

Described in Section 8.1.2.6. Samples are selected and tested as defined in the quality

management plan.

8.3.2.3 Inspection

An inspection is the examination of a work product to determine if it conforms to

documented standards. The results of an inspection generally include measurements and may be

conducted at any level. For example, the results of a single activity can be inspected, or the final

product of the project can be inspected. Inspections may be called reviews, peer reviews, audits,

or walkthroughs. In some application areas, these terms have narrow and specific meanings.

Inspections also are used to validate defect repairs.

8.3.2.4 Approved Change Requests Review

All approved change requests should be reviewed to verify that they were implemented

as approved.

8.3.3 Control Quality: Outputs

8.3.3.1 Quality Control Measurements

Quality control measurements are the documented results of control quality activities.

They should be captured in the format that was specified through the Plan Quality Management

process (Section 8.1).

8.3.3.2 Validated Changes

Any changed or repaired items are inspected and will be either accepted or rejected

before notification of the decision is provided. Rejected items may require rework.

8.3.3.3 Verified Deliverables

A goal of the Control Quality process is to determine the correctness of deliverables. The

results of performing the Control Quality process are verified deliverables. Verified deliverables

are an input to Validate Scope (5.5.1.4) for formalized acceptance.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

8.3.3.4 Work Performance Information

Work performance information is the performance data collected from various

controlling processes, analyzed in context and integrated based on relationships across areas.

Examples include information about the project requirements fulfillment such as causes for

rejections, rework required, or the need for process adjustments.

8.3.3.5 Change Requests

If the recommended corrective or preventive actions or a defect repair requires a change

to the project management plan, a change request (Section 4.4.3.1) should be initiated in

accordance with the defined Perform Integrated Change Control (4.5) process.

8.3.3.6 Project Management Plan Updates

Elements of the project management plan that may be updated include, but are not

limited to:

 Quality management plan (Section 8.1.3.1), and

 Process improvement plan (Section 8.1.3.2).

8.3.3.7 Project Documents Updates

Project documents that may be updated include, but are not limited to,

 Quality standards;

 Agreements;

 Quality audit reports and change logs supported with corrective action plans;

 Training plans and assessments of effectiveness; and

 Process documentation, such as information obtained using the seven basic quality

tools or the quality management and control tools.

8.3.3.8 Organizational Process Assets Updates

Elements of the organizational process assets that may be updated include, but are not

limited to:

 Completed checklists. When checklists are used, the completed checklists become

part of the project documents and organizational process assets (Section 4.1.1.5).

 Lessons learned documentation. The causes of variances, the reasoning behind the

corrective action chosen, and other types of lessons learned from control quality are

documented so they become part of the historical database for both the project and the

performing organization.



PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

PROJECT

HUMAN RESOURCE MANAGEMENT

Project Human Resource Management includes the processes that organize, manage, and

lead the project team. The project team is comprised of the people with assigned roles and

responsibilities for completing the project. Project team members may have varied skill sets, may

be assigned full or part-time, and may be added or removed from the team as the project

progresses. Project team members may also be referred to as the project’s staff. Although

specific roles and responsibilities for the project team members are assigned, the involvement of

all team members in project planning and decision making is beneficial. Participation of team

members during planning adds their expertise to the process and strengthens their commitment to

the project.

Figure 9-1 provides an overview of the Project Human Resource Management processes,

which are as follows:

9.1 Plan Human Resource Management—The process of identifying and documenting

project roles, responsibilities, required skills, reporting relationships, and creating a staffing

management plan.

9.2 Acquire Project Team—The process of confirming human resource availability and

obtaining the team necessary to complete project activities.

9.3 Develop Project Team—The process of improving competencies, team member

interaction, and overall team environment to enhance project performance.

9.4 Manage Project Team—The process of tracking team member performance,

providing feedback, resolving issues, and managing changes to optimize project performance.

These processes interact with each other and with processes in other Knowledge Areas as

described in detail in Section 3 and Annex A1.

As a result of these interactions additional planning may be required throughout the

project. For example:

 After initial team members create a work breakdown structure, additional team

members may need to be added to the team.

 As additional team members are added to the team, their experience levels, or lack

thereof, could decrease or increase project risk, creating the need for additional risk

planning.

 When activity durations are estimated, budgeted, scoped, or planned prior to

identifying all project team members and their competency levels, the activity

durations may change.

The project management team is a subset of the project team and is responsible for the

project management and leadership activities such as initiating, planning, executing, monitoring,

controlling, and closing the various project phases. This group can also be referred to as the core,

executive, or leadership team. For smaller projects, the project management responsibilities may

be shared by the entire team or administered solely by the project manager. The project sponsor

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

works with the project management team, typically assisting with matters such as project

funding, clarifying scope, monitoring progress, and influencing stakeholders in both the

requesting and performing organization for the project benefit.

Managing and leading the project team includes, but is not limited to:

 Influencing the project team. The project manager needs to be aware of and

influence, when possible, human resource factors that may impact the project. These

factors includes team environment, geographical locations of team members,

communications among stakeholders, internal and external politics, cultural issues,

organizational uniqueness, and others factors that may alter project performance.

 Professional and ethical behavior. The project management team should be aware

of, subscribe to, and ensure that all team members follow professional and ethical

behavior.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

Figure 9-1. Project Human Resource Management Overview

9.1 Plan Human Resource Management

Plan Human Resource Management is the process of identifying and documenting project

roles, responsibilities, required skills, reporting relationships, and creating a staffing management

plan. The key benefit of this process is that it establishes project roles and responsibilities,

project organization charts, and the staffing management plan including the timetable for staff

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

acquisition and release. The inputs, tools and techniques, and outputs of this process are depicted

in Figure 9-2. Figure 9-3 depicts the data flow diagram of the process.

Figure 9-2. Plan Human Resource Management: Inputs, Tools & Techniques, and Outputs

Figure 9-3. Plan Human Resource Management Data Flow Diagram

Human resource planning is used to determine and identify human resources with the

necessary skills required for project success. The human resource management plan describes

how the roles and responsibilities, reporting relationships, and staffing management will be

addressed and structured within a project. It also contains the staffing management plan

including timetables for staff acquisition and release, identification of training needs, team-

building strategies, plans for recognition and rewards programs, compliance considerations,

safety issues, and the impact of the staffing management plan on the organization.

Effective human resource planning should consider and plan for the availability of or

competition for scarce resources. Project roles can be designated for teams or team members.

Those teams or team members can be from inside or outside the organization performing the

project. Other projects may be competing for human resources with the same competencies or

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

skill sets. Given these factors, project costs, schedules, risks, quality, and other project areas may

be significantly affected.

9.1.1 Plan Human Resource Management: Inputs

9.1.1.1 Project Management Plan

Described in Section 4.2.3.1. The project management plan is used to develop the human

resource management plan as described in Section 9.1.3.1. The information used for the

development of the human resource management plan includes, but is not limited to:

 The project life cycle and the processes that will be applied to each phase,

 How work will be executed to accomplish the project objectives,

 A change management plan that documents how changes will be monitored and

controlled,

 A configuration management plan that documents how configuration management

will be performed,

 How integrity of the project baselines will be maintained, and

 Needs and methods of communication among stakeholders.

9.1.1.2 Activity Resource Requirements

Described in Section 6.4.3.1. Human resource planning uses activity resource

requirements to determine the human resource needs for the project. The preliminary

requirements regarding the required project team members and their competencies are

progressively elaborated as part of the Plan Human Resource Management process.

9.1.1.3 Enterprise Environmental Factors

Described in Section 2.1.5. The enterprise environmental factors that can influence the

Plan Human Resource Management process include, but are not limited to:

 Organizational culture and structure,

 Existing human resources,

 Geographical dispersion of team members,

 Personnel administration policies, and

 Marketplace conditions.

9.1.1.4 Organizational Process Assets

Described in Section 2.1.4. The organizational process assets that can influence the Plan

Human Resource Management process include, but are not limited to:

 Organizational standard processes, policies, and role descriptions;

 Templates for organizational charts and position descriptions;

 Lessons learned on organizational structures that have worked in previous projects;

and

 Escalation procedures for handling issues within the team and within the performing

organization.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

9.1.2 Plan Human Resource Management: Tools and Techniques

9.1.2.1 Organization Charts and Position Descriptions

Various formats exist to document team member roles and responsibilities. Most of the

formats fall into one of three types (Figure 9-4): hierarchical, matrix, and text-oriented.

Additionally, some project assignments are listed in subsidiary plans, such as the risk, quality, or

communications management plans. Regardless of the method utilized, the objective is to ensure

that each work package has an unambiguous owner and that all team members have a clear

understanding of their roles and responsibilities. For example, a hierarchical format may be used

to represent high-level roles, while a text-based format may be better suited to document the

detailed responsibilities.

Figure 9-4. Roles and Responsibility Definition Formats

 Hierarchical-type charts. The traditional organization chart structure can be used to

show positions and relationships in a graphical, top-down format. Work breakdown

structures (WBS) designed to show how project deliverables are broken down into

work packages provide a way of showing high-level areas of responsibility. While the

WBS shows a breakdown of project deliverables, the organizational breakdown

structure (OBS) is arranged according to an organization’s existing departments,

units, or teams with the project activities or work packages listed under each

department. An operational department such as information technology or purchasing

can see all of its project responsibilities by looking at its portion of the OBS. The

resource breakdown structure (RBS) is a hierarchical list of resources related by

category and resource type that is used to facilitate planning and controlling of project

work. Each descending (lower) level represents an increasingly detailed description

of the resource until small enough to be used in conjunction with the work breakdown

structure (WBS) to allow the work to be planned, monitored and controlled. The

resource breakdown structure is helpful in tracking project costs and can be aligned

with the organization’s accounting system. It can contain resource categories other

than human resources.

 Matrix-based charts. A responsibility assignment matrix (RAM) is a grid that shows

the project resources assigned to each work package. It is used to illustrate the

connections between work packages or activities and project team members. On

larger projects, RAMs can be developed at various levels. For example, a high-level

RAM can define what a project team group or unit is responsible for within each

component of the WBS, while lower-level RAMs are used within the group to

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

designate roles, responsibilities, and levels of authority for specific activities. The

matrix format shows all activities associated with one person and all people

associated with one activity. This also ensures that there is only one person

accountable for any one task to avoid confusion of responsibility. One example of a

RAM is a RACI (responsible, accountable, consult, and inform) chart, shown in

Figure 9-5. The sample chart shows the work to be done in the left column as

activities. The assigned resources can be shown as individuals or groups. The project

manager can select other options such as “lead” and “resource” designations or

others, as appropriate for the project. A RACI chart is a useful tool to use when the

team consists of internal and external resources in order to ensure clear divisions of

roles and expectations.

Figure 9-5. RACI Matrix

 Text-oriented formats. Team member responsibilities that require detailed

descriptions can be specified in text-oriented formats. Usually in outline form, the

documents provide information such as responsibilities, authority, competencies, and

qualifications. The documents are known by various names including position

descriptions and role-responsibility-authority forms. These documents can be used as

templates for future projects, especially when the information is updated throughout

the current project by applying lessons learned.

9.1.2.2 Networking

Networking is the formal and informal interaction with others in an organization,

industry, or professional environment. It is a constructive way to understand political and

interpersonal factors that will impact the effectiveness of various staffing management options.

Human resource management benefits from successful networking by improving knowledge of

and access to human resource assets such as strong competencies, specialized experience, and

external partnership opportunities. Examples of human resources networking activities include

proactive correspondence, luncheon meetings, informal conversations including meetings and

events, trade conferences, and symposia. Networking can be a useful technique at the beginning

of a project. It can also be an effective way to enhance project management professional

development during the project and after the project ends.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

9.1.2.3 Organizational Theory

Organizational theory provides information regarding the way in which people, teams,

and organizational units behave. Effective use of common themes identified in organizational

theory can shorten the amount of time, cost, and effort needed to create the Plan Human

Resource Management process outputs and improve planning efficiency. It is important to

recognize that different organizational structures have different individual response, individual

performance, and personal relationship characteristics. Also, applicable organizational theories

may recommend exercising a flexible leadership style that adapts to the changes in a team’s

maturity level throughout the project life cycle.

9.1.2.4 Expert Judgment

When developing the human resource management plan, expert judgment is used to:

 List the preliminary requirements for the required skills;

 Assess the roles required for the project based on standardized role descriptions

within the organization;

 Determine the preliminary effort level and number of resources needed to meet

project objectives;

 Determine reporting relationships needed based on the organizational culture;

 Provide guidelines on lead time required for staffing, based on lessons learned and

market conditions;

 Identify risks associated with staff acquisition, retention, and release plans; and

 Identify and recommend programs for complying with applicable government and

union contracts.

9.1.2.5 Meetings

When planning human resource management of the project, the project management team

will hold planning meetings. These meetings leverage a combination of other tools and

techniques to allow for all project management team members to reach consensus on the human

resource management plan.

9.1.3 Plan Human Resource Management: Outputs

9.1.3.1 Human Resource Management Plan

The human resource management plan, a part of the project management plan, provides

guidance on how project human resources should be defined, staffed, managed, and eventually

released. The human resource management plan and any subsequent revisions are also inputs

into the Develop Project Management Plan process.

The human resource management plan includes, but is not limited to, the following:

 Roles and responsibilities. The following should be addressed when listing the roles

and responsibilities needed to complete a project:

o Role. The function assumed by or assigned to a person in the project.

Examples of project roles are civil engineer, business analyst, and testing

coordinator. Role clarity concerning authority, responsibilities, and boundaries

should also be documented.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

o Authority. The right to apply project resources, make decisions, sign

approvals, accept deliverables, and influence others to carry out the work of

the project. Examples of decisions that need clear authority include the

selection of a method for completing an activity, quality acceptance, and how

to respond to project variances. Team members operate best when their

individual levels of authority match their individual responsibilities.

o Responsibility. The assigned duties and work that a project team member is

expected to perform in order to complete the project’s activities.

o Competency. The skill and capacity required to complete assigned activities

within the project constraints. If project team members do not possess

required competencies, performance can be jeopardized. When such

mismatches are identified, proactive responses such as training, hiring,

schedule changes, or scope changes are initiated.

 Project organization charts. A project organization chart is a graphic display of

project team members and their reporting relationships. It can be formal or informal,

highly detailed or broadly framed, based on the needs of the project. For example, the

project organization chart for a 3,000-person disaster response team will have greater

detail than a project organization chart for an internal, twenty-person project.

 Staffing management plan. The staffing management plan is a component of the

human resource management plan that describes when and how project team

members will be acquired and how long they will be needed. It describes how human

resource requirements will be met. The staffing management plan can be formal or

informal, highly detailed, or broadly framed, depending upon the needs of the project.

The plan is updated continually during the project to direct ongoing team member

acquisition and development actions. Information in the staffing management plan

varies by application area and project size, but items to consider include:

o Staff acquisition. A number of questions arise when planning the acquisition

of project team members. For example, whether the human resources come

from within the organization or from external, contracted sources; whether the

team members need to work in a central location or may work from distant

locations; costs associated with each level of expertise needed for the project;

and level of assistance that the organization’s human resource department and

functional managers are able to provide to the project management team.

o Resource calendars. Calendars that identify the working days and shifts on

which each specific resource is available. The staffing management plan

describes necessary time frames for project team members, either individually

or collectively, as well as when acquisition activities such as recruiting should

start. One tool for charting human resources is a resource histogram, used by

the project management team as a means of providing a visual representation

or resources allocation to all interested parties. This chart illustrates the

number of hours a person, department, or entire project team that will be

needed each week or month over the course of the project. The chart can

include a horizontal line that represents the maximum number of hours

available from a particular resource. Bars that extend beyond the maximum

available hours identify the need for a resource optimization strategy (Section

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

6.6.2.4), such as adding more resources or modifying the schedule. An

example of a resource histogram is illustrated in Figure 9-6.

Figure 9-6. Illustrative Resource Histogram

o Staff release plan. Determining the method and timing of releasing team

members benefits both the project and team members. When team members

are released from a project, the costs associated with those resources are no

longer charged to the project, thus reducing project costs. Morale is improved

when smooth transitions to upcoming projects are already planned. A staff

release plan also helps mitigate human resource risks that may occur during or

at the end of a project.

o Training needs. If it is expected that the team members to be assigned will not

have the required competencies, a training plan can be developed as part of

the project. The plan can also include ways to help team members obtain

certifications that would support their ability to benefit the project.

o Recognition and rewards. Clear criteria for rewards and a planned system for

their use help promote and reinforce desired behaviors. To be effective,

recognition and rewards should be based on activities and performance under

a person’s control. For example, a team member who is to be rewarded for

meeting cost objectives should have an appropriate level of control over

decisions that affect expenses. Creating a plan with established times for

distribution of rewards ensures that recognition takes place and is not

forgotten. Recognition and rewards are part of the Develop Project Team

process (Section 9.3).

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

o Compliance. The staffing management plan can include strategies for

complying with applicable government regulations, union contracts, and other

established human resource policies.

o Safety. Policies and procedures that protect team members from safety hazards

can be included in the staffing management plan as well as in the risk register.

9.2 Acquire Project Team

Acquire Project Team is the process of confirming human resource availability and

obtaining the team necessary to complete project activities. The key benefit of this process

consists of outlining and guiding the team selection and responsibility assignment to obtain a

successful team. The inputs, tools and techniques, and outputs of this process are depicted in

Figure 9-7. Figure 9-8 depicts the data flow diagram of the process.

Figure 9-7. Acquire Project Team: Inputs, Tools & Techniques, and Outputs

Figure 9-8. Acquire Project Team Data Flow Diagram

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

The project management team may or may not have direct control over team member

selection because of collective bargaining agreements, use of subcontractor personnel, matrix

project environment, internal or external reporting relationships, or other various reasons. It is

important that the following factors are considered during the process of acquiring the project

team:

 The project manager or project management team should effectively negotiate and

influence others who are in a position to provide the required human resources for the

project.

 Failure to acquire the necessary human resources for the project may affect project

schedules, budgets, customer satisfaction, quality, and risks. Insufficient human

resources or capabilities decrease the probability of success and, in a worst case

scenario, could result in project cancellation.

 If the human resources are not available due to constraints, such as economic factors

or previous assignments to other projects, the project manager or project team may be

required to assign alternative resources, perhaps with lower competencies, provided

there is no violation of legal, regulatory, mandatory, or other specific criteria.

These factors should be considered and planned for in the planning stages of the project.

The project manager or project management team will be required to reflect the impact of any

unavailability of required human resources in the project schedule, project budget, project risks,

project quality, training plans, and the other project management plans.

9.2.1 Acquire Project Team: Inputs

9.2.1.1 Human Resource Management Plan

Described in Section 9.1.3.1. The human resource management plan provides guidance

on how project human resources should be identified, staffed, managed, and eventually released.

It includes:

 Roles and responsibilities defining the positions, skills, and competencies that the

project demands;

 Project organization charts indicating the number of people needed for the project;

and

 Staffing management plan delineating the time periods each project team member

will be needed and other information important to engage the project team.

9.2.1.2 Enterprise Environmental Factors

Described in Section 2.1.5. The enterprise environmental factors that influence the

Acquire Project Team process include, but are not limited to:

 Existing information on human resources including availability, competency levels,

prior experience, interest in working on the project and their cost rate;

 Personnel administration policies such as those that affect outsourcing;

 Organizational structure as described in Section 2.3.1; and

 Colocation or multiple locations.

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

9.2.1.3 Organizational Process Assets

Described in Section 2.1.4. The organizational process assets that influence the Acquire

Project Team process include, but are not limited to, organizational standard policies, processes,

and procedures.

9.2.2 Acquire Project Team: Tools and Techniques

9.2.2.1 Pre-assignment

When project team members are selected in advance, they are considered pre-assigned.

This situation can occur if the project is the result of specific people being identified as part of a

competitive proposal, if the project is dependent upon the expertise of particular persons, or if

some staff assignments are defined within the project charter.

9.2.2.2 Negotiation

Staff assignments are negotiated on many projects. For example, the project management

team may need to negotiate with:

 Functional managers, to ensure that the project receives appropriately competent staff

in the required time frame and that the project team members will be able, willing,

and authorized to work on the project until their responsibilities are completed;

 Other project management teams within the performing organization, to appropriately

assign scarce or specialized human resources; and

 External organizations, vendors, suppliers, contractors, etc., for appropriate, scarce,

specialized, qualified, certified, or other such specified human resources. Special

consideration should be given to external negotiating policies, practices, processes,

guidelines, legal, and other such criteria.

The project management team’s ability to influence others plays an important role in

negotiating staff assignments, as do the politics of the organizations involved. For example, a

functional manager will weigh the benefits and visibility of competing projects when

determining where to assign exceptional performers requested by various project teams.

9.2.2.3 Acquisition

When the performing organization is unable to provide the staff needed to complete a

project, the required services may be acquired from outside sources. This can involve hiring

individual consultants or subcontracting work to another organization.

9.2.2.4 Virtual Teams

The use of virtual teams creates new possibilities when acquiring project team members.

Virtual teams can be defined as groups of people with a shared goal who fulfill their roles with

little or no time spent meeting face to face. The availability of communication technology such

as e-mail, audio conferencing, social media, web-based meetings and video conferencing has

made virtual teams feasible. The virtual team model makes it possible to:

 Form teams of people from the same organization who live in widespread geographic

areas;

 Add special expertise to a project team even though the expert is not in the same

geographic area;

 Incorporate employees who work from home offices;

PMBOK®Guide—FifthEdition

Pre‐ReleaseVersionOctober10,2012

NotforDistributionorReproduction.

 Form teams of people who work different shifts, hours, or days;

 Include people with mobility limitations or disabilities; and

 Move forward with projects that would have been ignored due to travel expenses.

There are some disadvantages related to virtual teams, such as possibility for

misunderstandings, feeling of isolation, difficulties in sharing knowledge and experience

between team members, and cost of appropriate technology. Communication planning becomes

increasingly important in a virtual team environment. Additional time may be needed to set clear

expectations, facilitate communications, develop protocols for resolving conflict, include people

in decision making, understand cultural differences, and share credit in successes.

9.2.2.5 Multi-Criteria Decision Analysis

Selection criteria are often used as a part of acquiring the project team. By use of a multi-

criteria decision analysis tool, criteria are developed and used to rate or score potential team

members. The criteria are weighted according to the relative importance of the needs within the

team. Some examples of selection criteria that can be used to score team members are shown as

follows:

 Availability. Identify whether the team member is available to work on the project

within the time period needed. If there are there any concerns for availability during

the project timeline.

 Cost. Verify if the cost of adding the team member is within the prescribed budget.

 Experience. Verify that the team member has the relevant experience that will

contribute to the project success.

 Ability. Verify that the team member has the competencies needed by the project.

 Knowledge. Consider if the team member has relevant knowledge of the customer,

similar implemented projects, and nuances of the project environment.

 Skills. Determine whether the member has the relevant skills to use a project tool,

implementation, or training.

 Attitude. Determine whether the member has the ability to work with others as a

cohesive team.

 International factors. Consider team member location, time zone and

communication capabilities.

9.2.3 Acquire Project Team: Outputs

9.2.3.1 Project Staff Assignments

The project is staffed when appropriate people have been assigned to the team. The

documentation of these assignments can include a project team directory, memos to team

members, and names inserted into other parts of the project management plan, such as project

organization charts and schedules.

9.2.3.2 Resource Calendars

Resource calendars document the time periods that each project team member is available

to work on the project. Creating a reliable schedule (Section 6.6.3.1) depends on having a good

understanding of each person’s availability and schedule constraints, including time zones, work

hours, vacation time, local holidays, and commitments to other projects.