Week 3,4 Discussion 1 & 2

ContemporaryProjectManagementChapter11-12.pdf

Home >Business & Finance homework help >Operations Management homework help >Week 3,4 Discussion 1 & 2

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&snap… 1/2

Chapter 11 Project Risk Planning

Chapter Introduction

11-1 Plan Risk Management 11-1a Roles and Responsibilities

11-1b Categories and Definitions

11-2 Identify Risks 11-2a Information Gathering

11-2b Reviews

11-2c Understanding Relationships

11-2d Risk Register

11-3 Risk Analysis 11-3a Perform Qualitative Risk Analysis

11-3b Perform Quantitative Risk Analysis

11-3c Risk Register Updates

11-4 Plan Risk Responses 11-4a Strategies for Responding to Risks

11-4b Risk Register Updates

11-5 PMP/CAPM Study Ideas

Chapter Review Summary

Key Terms Consistent with PMI Standards and Guides

Chapter Review Questions

Discussion Questions

PMBOK® Guide Questions

Exercises

Integrated Example Projects

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&snap… 2/2

Casa de Paz Development Project

Semester Project Instructions

Project Management in Action

References

© 2020 Cengage Learning Inc. All rights reserved. No part of this work may by reproduced or used in any form or by any means - graphic, electronic, or mechanical, or in any other manner - without the written permission of the copyright holder.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/4

Chapter Introduction

David R. Frazier Photolibrary, Inc./Alamy Stock Photo

Chapter Objectives

After completing this chapter, you should be able to:

Core Objectives:

Describe how to plan for risk management, identify risks, analyze risks, and create response plans for identified risks.

Identify and classify risks for a project and populate a risk register.

Describe various risk assessment techniques and tell when each is appropriate to use.

Prioritize each risk on a project using an appropriate assessment technique and develop and defend at least one strategy for each of the high-priority risks.

Compare and contrast the various strategies for dealing with risks.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 2/4

PMBOK® Guide

Topics:

Behavioral Objectives:

Determine an individual’s propensity to accept risk and use that to strategize about which risks to accept.

Determine an organization’s propensity to accept risk and use that knowledge to strategize about which risks to accept.

Technical Objectives:

Select and utilize an appropriate quantitative risk analysis tool if qualitative risk analysis is not sufficient.

The Texas Medical Center (TMC) is composed of forty-nine not-for-profit institutions that are dedicated to the highest standards of patient care, research, and education. These institutions include thirteen renowned hospitals and two specialty institutions, two medical schools, four nursing schools, and schools of dentistry, public health, pharmacy, and virtually all health-related careers. People come from all walks of life and from all over the world to have access to the best healthcare anywhere. Member institutions specialize in every imaginable aspect of healthcare, including care for children and cancer patients, heart care, organ transplantation, terminal illness, mental health, and wellness and prevention.

Currently, 11 major construction projects are underway, including the Texas Children’s Hospital’s 407,000-square-foot Neurological Research Institute and 720,000-square-foot Maternity Center, along with a 12-story, 27,000-square-foot concrete-frame addition to the M. D. Anderson Cancer Center of the University of Texas Medical Center. Collectively, these major projects will add facilities that will be staffed by up to 27,000 additional employees. When complete, TMC will have 40 million square feet of occupied space. If you consider downtown business space, by itself it forms the seventh-largest downtown business district in the United States.

With hurricane season approaching, TMC held a conference for over 100 contractors to review how to prepare for a potential hurricane. Contractors must have a plan in place detailing how they

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 3/4

Plan risk management

Identify risks

Perform qualitative risk analysis

Perform quantitative risk analysis

Plan risk responses

Chapter Outputs

Risk register

are going to secure their construction sites and keep materials from becoming airborne missiles in the event of a hurricane. Conference attendees were given a handout describing TMC’s hurricane guidelines. These guidelines call for storm preparations to be completed 24 hours before tropical storm winds are predicted to hit land. Examples of storm preparations include dismantling scaffolds and privacy screens, securing giant cranes, emptying and weighting down dumpsters, photographing all buildings and assets, and unblocking all streets for emergency access.

While project managers cannot prevent hurricanes, through careful risk planning, actions can be taken to greatly mitigate the impact.

Rhonda Wendler, Texas Medical Center News

Imagine you are asked to plan for risks on two different projects. One is a major construction project at TMC with hurricane season approaching. The other is planning a small fund- raising event for charity. Would you handle the risks on these two projects the same way? Would you invest the same level of time and energy into planning these two projects? The answers are yes and no. Yes, you would approach the risks in the same way. But you would not spend the same amount of time planning for risk on both projects. You would spend considerably more time and money on risk management planning for the major construction project that is vulnerable to a hurricane than for the small fund-raiser project. Just as in other types of project planning, there is an approach to planning for risks that all projects follow; however, the depth of planning depends greatly on the potential project risks and consequences if some of these risks are not managed. In other words, a smart project manager gladly spends $100 in risk planning to save $1,000 in expected consequences, but does not gladly spend $1,000 to save $100.

The purpose of risk management is to reduce the overall project risk to a level that is acceptable to the project sponsor and other key stakeholders. The methods that project managers use in risk management start with identifying as many risks as possible. Once the risks are identified, each risk is analyzed in terms of its likelihood of occurrence and impact on project goals if it occurs. Using this analysis, the project team can concentrate their attention on the most critical risks. Analysis always consists of a qualitative or judgmental approach for all the identified risks and sometimes also includes a quantitative approach for the critical risks. In the final risk management process, the project team decides how to respond to each potential risk. Once all the risk management planning has initially been accomplished, the response plans are incorporated into the overall project management

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 4/4

plan. Changes may need to be made to the schedule, budget, scope, or communication plans to account for certain risks. These risk management planning processes are covered in this chapter. Risk management also includes monitoring and controlling the risks according to plan. These are covered, along with ongoing risk planning, in Chapter 14: Determining Project Progress and Results.

Agile

Agile projects are similar to other projects in regard to developing early

risk planning, assessment, and response planning at a high level. However, more detailed and timely risk management occurs in planning each subsequent iteration, in daily stand-up meetings, and in retrospectives at the end of each iteration.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/4

11-1 Plan Risk Management Plan risk management (process of defining how to conduct risk management activities for a project.) is “the process of defining how to conduct risk management activities for a project.” A future event is considered a project risk if it threatens the successful accomplishment of a project goal. Obviously, a project manager must first understand the project’s objectives to plan for project risks. A project manager develops this understanding initially by realizing what project success in general is and then by understanding the specific priorities of the most important project stakeholders, as discussed in Chapter 6. Exhibit 11.1 summarizes current project success research results.

Exhibit 11.1

Project Success Measures

Meeting Agreements

Cost, schedule, and specifications met

Customer’s Success

Needs met, deliverables used, customer satisfied

Performing Organization’s Success

Market share, new products, new technology

Project Team’s Success

Loyalty, development, satisfaction

Source: Kloppenborg, Timothy J., Debbie Tesch, and Broderick King, “21st Century Project Success

Measures: Evolution, Interpretation, and Direction,” Proceedings, Project Management Institute Research

and Education Conference, July 2012, Limerick, Ireland.

The first set of general project success measures is meeting various agreements associated with a project. This includes meeting the project requirements while not going over the cost and schedule agreements. The second set of project success measures focuses on the project’s customers, specifically addressing questions such as the following: Did the project results or outcomes meet the customers’ needs? Did the customers use the project result?

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 2/4

Did it enhance the customers’ satisfaction? The third set deals with the future of the performing organization, the one that manages the project. The specific measures vary, but essentially, they focus on whether the project helped the performing organization. The performing organization (an enterprise whose employees have a direct involvement in executing and completing the project.) is an enterprise whose employees have a direct involvement in executing and completing the project. Typical project success measures for the performing organization include market share, new markets and/or technologies, and commercial success of the project output. The final set of project success measures deals with the project team, for example: Did they become better and more dedicated employees? Did they meet professional and personal aspirations and personal development goals?

The specific priorities of the project’s most important stakeholders can be summarized in a table such as Exhibit 11.2. In general, the unspoken expectations from the project team are to complete the project sooner and below the budget while delivering the agreed-upon scope and quality. A project manager and the project team need to understand not only what the project plans call for but also what area(s) the most important stakeholders would like to improve and what area(s) they are willing to sacrifice to enable those improvements. For example, consider a project that calls for building a four-bedroom house of 2,800 square feet. Perhaps the homeowner (the most important stakeholder) insists on keeping the size at 2,800 square feet and insists on the normal quality (no leaks, square walls, etc.), but would like to improve on the cost (pay less money). To improve on the cost objective, one of the other objectives probably needs to be sacrificed. Perhaps the homeowner would be willing to move in a month late if the savings were $5,000.

Exhibit 11.2

Specific Project Stakeholder Priorities

IMPROVE KEEP

Scope X

Quality X

Time ≤ 1 month to save $5,000

Cost Want to save

Contribution to Organization

Contribution to Society X

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 3/4

Source: Adapted from Timothy J. Kloppenborg and Joseph A. Petrick, Managing Project Quality (Vienna,

VA: Management Concepts, Inc., 2002), 46.

Once the project team understands the project success measures and priorities, attention is turned to understanding the project risks. All projects have some risk, and the more unique a project is, the more risk there will be. Uniqueness of a project is usually associated with uncertainties and unknowns, which contribute to project risks. It is impossible to remove all sources of risk. It is undesirable to even try to remove all risks because that means the organization is not trying anything new. Without risk, there is no gain or progress.

A project risk (anything that may impact the project team’ s ability to achieve the general project success measures and the specific project stakeholders’ priorities.) is anything that may impact the project team’s ability to achieve the general project success measures and the specific project stakeholders’ priorities. This impact can be something that poses a threat (a condition or situation unfavorable to the project that presents a negative set of circumstances or events or consequences. A threat also is a risk that will have a negative impact on a project objective if it occurs.) , which is “a condition or situation unfavorable to the project that presents a negative set of circumstances or events or consequences. A threat also is a risk that will have a negative impact on a project objective if it occurs.”

The impact of a threat, on the other hand, could be something that poses an opportunity (a condition or situation favorable to the project, a positive set of circumstances, a positive set of events, a risk that will have a positive impact on project objectives.) or “a condition or situation favorable to the project, a positive set of circumstances, a positive set of events, a risk that will have a positive impact on project objectives.”

Wise project managers strive to develop a risk management plan (an important plan that is integral to the comprehensive project management plan that describes how risks are prioritized, monitored for changing priorities, and how prioritized risk management activities will be planned and performed.) , an important plan that is integral to the comprehensive project management plan that describes how risks are prioritized, monitored for changing priorities, and how prioritized risk management activities will be planned and performed. Usually, a risk management plan develops a mitigation strategy for all the prioritized risks before these risk events occur. By documenting risk information in a proactive manner, a project manager can eliminate or reduce the impact of some threats and capitalize on some opportunities. The risk management plan is also useful for communicating with the various project stakeholders and for later analysis to determine what worked well and may be good practice to use on future projects, as well as what went poorly and should be avoided on future projects.

Some risk management plans include all the topics in this chapter. Others are smaller. For example, a risk management plan template for an IT consulting company is shown in Exhibit 11.3.

Exhibit 11.3

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 4/4

Risk Management Plan Guidance for an IT Consulting Company

Risk management includes guidance on how to perform three risk management activities:

1. Decide what level of risk premium to charge for the project. The team must rate factors such as project size, complexity, technology, and type. The combined ratings dictate that a risk premium of 0, 10, or 20 percent be added to the estimated project cost or, for very risky projects, that executive approval is mandated.

2. Mitigate risk external to the firm through contract clauses and risk internal to the firm through agreements.

3. Manage the risk very carefully through specifically designed weekly conference call meetings and reports.

Source: Rachana Thariani, PMP®

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/1

11-1a Roles and Responsibilities

It is a good practice to encourage wide participation in risk management activities. One reason is that everyone brings a different perspective, and the more perspectives that are considered, the more likely it is that important risks will be uncovered early. Another good reason is that people often resist when they are told what to do but work with great enthusiasm if they participated in the planning. The surest way to get the various project stakeholders to buy into a risk management approach is to involve them in risk management planning right from the beginning. Potential critics can be turned into allies if their concerns are included.

The risk management plan should define who is responsible for each risk management activity. On small projects, often the project manager or a core team member is responsible for most risk activities. On larger projects, the plan can be more elaborate and subject matter experts may be involved at many points.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/6

11-1b Categories and Definitions

Most projects have many types of possible risks. Therefore, it is helpful to look at risks in a systematic manner so as to consider as many types of risks as possible. One way to look at risk is by considering when it occurs in the project life cycle. For example:

Certain types of risks, such as a customer not agreeing on the price, may occur during project initiation.

Others, such as not finding a capable supplier, may occur during project planning.

Risks, such as delivery difficulties from a supplier, may occur during project execution.

Omission of some of the essential activities in the WBS may also be realized during the project execution.

Risks, such as the project deliverable not actually working properly, may even appear near the project conclusion.

The number and costs of project risks over a project life cycle are graphed in Exhibit 11.4. More project risks are typically uncovered early in the life of a project. However, the cost per risk discovered early is often less since there will be an opportunity and time to make changes to the project plan. Risks discovered late in a project can prove to be very expensive. Experienced project managers work hard to uncover risks as early in the project as feasible. Usually, some risks are uncovered when chartering the project. On small or simple projects, this may be the biggest risk identification push, but on other projects, a great deal of time and effort may also be expended during project planning.

Exhibit 11.4

Risks Over the Project Life Cycle

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 2/6

In addition to being categorized by when they might occur in a project, risks can also be categorized by what project objective they may impact, such as cost, schedule, scope, and/or quality. Risks can also be classified as external to the performing organization and internal to it, or by whether they are operational or strategic. Many organizations have developed lists of risks for certain types of projects they routinely perform. In addition, many writers have created general lists of risk factors for certain types of projects. For example, recent research has shown the largest risks on megaprojects include risks from nine causes:

1. Design

2. Legal and political

3. Contractual

4. Construction

5. Operation and maintenance

6. Labor

7. Customer/user/society

8. Financial

9. Force majeure (an unforeseen event that prevents a contract from being fulfilled)

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 3/6

Another recent study found that green retrofit projects classify their biggest risks as coming from eight areas:

1. Post-tenants’ cooperation

2. Regulatory

3. Industry

4. Financial

5. Pre-retrofit tenant’s cooperation

6. Varying concerns from different stakeholders

7. Material supply and availability

8. Quality

For a few further examples, Exhibit 11.5 shows the biggest 14 risks on the Panama Canal expansion (which might be similar to those of other major construction projects). Exhibit 11.6 shows major risk categories for international projects generally, and Exhibit 11.7 shows common risks for information systems projects. Any of these categorizations can be shown as a risk breakdown structure (presents a hierarchical organization of risks based on categories such as operational, strategic, finance, external, and project management.) , which presents a hierarchical organization of risks based on categories such as operational, strategic, finance, external, and project management. A Risk Breakdown Structure is similar to a WBS or a resource breakdown structure (RBS) in its hierarchical representation. It can be presented in graphic or table format.

Exhibit 11.5

Fourteen Most Important Risks in Panama Canal Expansion

Changes in design and quantities

Extreme bad weather

General inflation Inadequate claims administration

Ineffective contracting process Inefficient planning

Insufficient revenues Lack of controls

Lack of skilled and local labor Local labor strikes

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 4/6

Material, equipment, and labor cost

Organizational risks

Owner-driven changes Referendum delays

Source: Alarcon, Luis F., et al., “Risk Planning and Management for the Panama Canal Expansion

Program,” Journal of Construction Engineering and Management (October 2011): 762–770.

Exhibit 11.6

Top Risks in Each Factor for Internatonal Projects

CULTURAL VIRTUAL

Number of languages Communication issues

Trust level Number of countries

Economic culture Management experience

Number of religions Number of time zones

POLITICAL REGIONAL

Government desire for project

Crime rate

Government unrest Climate/weather

Laws and regulations Housing availability

Relationship with government

Safety issues and procedures

Source: Steffey, Robert W., and Vittal S. Anantatmula, “International Projects Proposal Analysis: Risk

Assessment Using Radial Maps,” Project Management Journal (April 2011): 62–70.

Exhibit 11.7

Top Risks in Each Factor for Software Projects

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 5/6

EXECUTION MANAGEMENT USER COORDINATION

Configuration management system User evaluation of progress

Formality of status reports User understanding of complexity

Specification approval process Care in user manual preparation

Post-project audits Coordination with user

Regularity of technical reviews Informal communication channels

HUMAN RESOURCE MANAGEMENT PROJECT PLANNING

Flexibility of working hours Frequency of software reuse

Individual performance incentives Planning tools used

Technical assistance availability Minimum cost software design

Recognition for extra work Removal of unnecessary requirements

Enforced attendance system Individual accountability

Source: Thomas, Sam, and M. Bhasi, “A Structural Model for Software Project Risk Management,”

Journal of Management (March 2011): 71–84.

Yet another method to classify project risk is by what is known and what is not known about each risk. Something that is a known known can be planned and managed with certainty; therefore, it is not a risk. An example is that cement will harden. The next level is known unknowns, which are risks that can be identified as risk but the likelihood of them is not known. In other words, a known unknown may or may not happen. These risks should be identified, and an analysis (qualitative for sure and quantitative if helpful) must be made to identify a mitigation strategy before a contingency reserve is established to pay for them. An example on a long construction project is that bad weather will probably happen at some points, but no one knows exactly when or how bad it will be. The final level is for the true uncertainties. These are called unknown unknowns (or unk unks by people who must deal with them). Since they cannot even be envisioned, it is hard to know how much reserve time and money are needed to cover them. They are usually covered by a management reserve, and the amount of this reserve is often negotiated based upon the confidence level the project manager and key stakeholders have regarding how well they understand the project. An example could be a 100-year flood that covers a construction site that everyone thought was on high enough ground to stay dry—an event so rare it is expected to happen only

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 6/6

once a century. The tsunami that devastated a part of Japan in March 2011 was completely unexpected and an unknown risk that many projects in that region did not anticipate.

Savvy organizations are now often encouraging their project managers to reduce the number of unk unks by learning more about them so they can be known unknowns. They learn more by a combination of design approaches such as analyzing scenarios, using checklists, considering weak signals that might have been previously ignored, and mining big data. They also use behavioral approaches such as frequent and effective communication and creating incentives for discovery.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/1

11-2 Identify Risks Once the risk management planning is in place, it is time to begin identifying specific risks. Identify risks (the process of determining which risks may affect the project and documenting their characteristics.) is “the process of determining which risks may affect the project and documenting their characteristics.”  Project managers are ultimately responsible for identifying all risks, but often they rely upon subject matter experts to take a lead in identifying certain technical risks.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/2

11-2a Information Gathering

A large part of the risk identification process is gathering information. The categories shown in Exhibits 11.5, 11.6, and 11.7 and/or project stages can be a good starting point in this information gathering. The project manager either needs to act as a facilitator or get another person to serve as facilitator for information gathering. This is essentially a brainstorming technique, during which time the question “What could go wrong?” is repeatedly asked of everyone who is present for every activity identified in the WBS. It is helpful to use Post-it Notes and write one risk per note to prepare for further processing the risks during risk analysis.

Classic rules for brainstorming are used. For example, every idea is treated as a useful idea. The risks will be assessed next. Even if a suggested risk does not prove to be important, it is preferable to keep it on the list. Also, sometimes a risk that is obviously not important—or is even humorous—may cause another person to think of an additional risk they would not have considered otherwise.

While it is helpful to have as many stakeholders together as possible to “piggyback” on each other’s ideas, with the information technology available today, much of the same interaction can be achieved by global and virtual teams; it just takes more careful planning. Variations, combinations, and extensions of possible risks can help a project team to identify additional risks.

Several other techniques are also used in risk identification. The project team members may choose to interview stakeholders, specifically when a project is big, complex, and is associated with many uncertainties. In certain cases, SWOT analysis (a detailed analysis of the project’ s and project management’ s strengths, weaknesses, opportunities, and threats, might be used.) , which is a detailed analysis of the project’s and project management’s strengths, weaknesses, opportunities, and threats, might be used. Remember, risks can be both threats to overcome and opportunities to exploit. Yet another method of identifying risks is the Delphi technique (information gathering technique used as a way to reach a consensus among experts on a subject, with the experts participating anonymously in order to avoid groupthink and prejudice.) , an information gathering technique used as a way to reach a consensus among experts on a subject, with the experts participating anonymously in order to avoid groupthink and prejudice. Responses are summarized and recirculated for further comments and improvements. Finally, a team can use a structured review to identify risks.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 2/2

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/2

11-2b Reviews

A project manager and team can review a variety of project documents to uncover possible risks. Exhibit 11.8 lists some of the documents a project manager may use and typical questions he or she would ask for each. Project teams can often identify risks from each type of review shown in the exhibit. Of these, assumptions and the WBS are especially important sources for identifying risks. Every wrong assumption becomes a project risk. We initially develop a list of assumptions and constraints in the project charter. However, the list needs to be updated during the project planning phase and must be critically examined during the risk management planning to assess if all these assumptions are correct. Likewise, each work package in the WBS must be examined to identify risks associated with it. It is important to maintain balance between the extent of the reviews and the amount of useful information for identifying risks. As with the brainstorming mentioned previously, it is better to identify many possible risks and later determine that some of them are not major, rather than to not identify what does turn out to be a big risk.

Exhibit 11.8

Project Risk Reviews

TYPE OF REVIEW QUESTION

Charter Is there clarity and common understanding in each section?

Stakeholder register

What could upset any of them?

Communication plan

Where could poor communications cause trouble?

Assumptions Can you verify that each assumption is correct?

Constraints How does each constraint make the project more difficult?

WBS What risks can you find going through the WBS item by item?

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 2/2

TYPE OF REVIEW QUESTION

Schedule What milestones and other merge points might be troublesome?

Resource demands

At what points are certain people overloaded?

Touch points What difficulties may arise when some project work is handed off from one person to another?

Literature What problems and opportunities have been published concerning similar projects?

Previous projects What projects and opportunities have similar projects in your own organization experienced?

Peers Can your peers identify any additional risks?

Senior management

Can senior management identify any additional risks?

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/1

Chapter 11: Project Risk Planning: 11-2c Understanding Relationships Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

11-2c Understanding Relationships

Project managers can also seek to identify risks by learning the cause-and-effect relationships of risk events. One useful technique is a flow chart that shows how people, money, data, or materials flow from one person or location to another. This is essentially what the team does when it reviews the project schedule, provided it looks at the arrows that show which activities must precede others. By studying the flows, a person can consider which “handoffs” (when one person or team passes deliverables to another) might be risky.

A second method of understanding risk relationships is to ask why a certain risk event may happen. This can be accomplished through root cause analysis (an analytical technique to ascertain the fundamental or causal reason or reasons that affect one or more variances, defects, or risks.) , which is an analytical technique to ascertain the fundamental or causal reason or reasons that affect one or more variances, defects, or risks. A simple approach to root cause analysis is to simply consider each risk one at a time and ask, “Why might this happen?” At this point, since many potential risks have probably been identified, project teams do not spend a large amount of time on any single risk. If necessary, the project team can perform more detailed root cause analysis of the few risks that have been designated as major risks during risk analysis.

One more type of relationship project managers like to understand is trigger conditions (circumstance under which a risk strategy or risk action will be invoked.) , or a “circumstance under which a risk strategy or risk action will be invoked.” A trigger can be specific to an individual risk, such as when a key supplier stops returning phone calls, which may jeopardize their delivery of materials.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/5

11-2d Risk Register

The primary output of risk identification is the risk register. When complete, the risk register (the document containing the results of the qualitative risk analysis, quantitative risk analysis, and risk response planning. It details all identified risks, including description, category, cause, probability of occurring, impact(s) on objectives, proposed responses, owners, and current status.) is “the document containing the results of the qualitative risk analysis, quantitative risk analysis, and risk response planning. It details all identified risks, including description, category, cause, probability of occurring, impact(s) on objectives, proposed responses, owners, and current status.” At this point (the end of risk identification), the risk register includes only the risk categories, identified risks, potential causes, and potential responses. The other items are developed during the remainder of risk planning. An example of a partial risk register is shown in Exhibit 11.9.

Exhibit 11.9

Partial Risk Register

RISK DESCRIPTION (EVENT) IMPACT CATEGORY PROB IMPACT SCORE

MITIGATION STRATEGY- RESOLUTION

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 2/5

RISK DESCRIPTION (EVENT) IMPACT CATEGORY PROB IMPACT SCORE

MITIGATION STRATEGY- RESOLUTION

Incomplete requirements were identified in the RFP and Exhibits (see Risk 7).

Greater possibility of gaps in functionality.

Greater possibility of missing State specific functionality.

Greater possibility of “Scope Creep.”

Greater possibility of delay in finalizing requirements.

Greater possibility of rework in subsequent phases.

Business Requirements

5 4 20 MAXIMUS will begin conducting the detailed BA sessions 09/20/2012. Additional requirements will be gathered in those sessions and documented in subsequent versions of the Requirements Validation Documentation.

A schedule of future Business Architecture and Technical sessions is being developed.

State will provide closure and decisions regarding requirements and system scope.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 3/5

RISK DESCRIPTION (EVENT) IMPACT CATEGORY PROB IMPACT SCORE

MITIGATION STRATEGY- RESOLUTION

Since there are various vendor products (IBM/Curam, Connecture), each with its own rules engines, it is not clear which rules engine takes precedence.

Potential duplication of rules or conflicting rules that lead to different outcomes.

Technology 3 4 12 Engage Point will provide an explanation of how to mitigate this risk.

(See Risk Response Plan for resolution.)

Difficulty integrating to States end- to- end Infrastructure.

Potential difficulty integrating new technology into existing infrastructure.

Technology 4 4 16 Work with the State to define infrastructure requirements and ensure we are providing any necessary information to the MN-IT staff.

Going through hierarchical reporting structure will impact real- time decision making.

Potential bottlenecks in document reviews and decision making may affect task completion according to the Project Schedule.

Communications 4 4 16 Identifying a Point-of- Contact for each functional area from vendor and state to eliminate bottlenecks.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 4/5

RISK DESCRIPTION (EVENT) IMPACT CATEGORY PROB IMPACT SCORE

MITIGATION STRATEGY- RESOLUTION

State functional POCs may have competing priorities that will hinder their ability to response in a timely manner.

Secondary risk—related to Risk 6.

Communications 4 4 16 Identifying multiple Points- of-Contact for each functional area from vendor and state to eliminate bottlenecks.

Delays in procurement process may negatively impact project schedule.

Inability to acquire resources in a timely manner may negatively impact related activities in the Project Schedule.

Procurement 2 5 10 Add lead time as early as possible. Evaluate procurement requirements during the change order process. Make sure Commerce procurement staff are engaged in the PO development process.

Source: http://mn.gov/hix/images/BC9-l-ITAttachmentN.pdf, accessed April 26, 2013.

The risk register is a living document. As a risk is identified, it is added. More information regarding a risk can be added when it is discovered. It is normal to identify more risks during all the phases of the project. As risks are addressed, they can be removed from the risk register because they no longer are of the same level of concern. On smaller projects, a spreadsheet works fine for a risk register. On larger, more complex projects, some organizations use databases.

Chapter 11: Project Risk Planning: 11-2d Risk Register Book Title: Contemporary Project Management

http://mn.gov/hix/images/BC9-l-ITAttachmentN.pdf

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 5/5

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/1

11-3 Risk Analysis Every project team must consider risks diligently. If a project team is serious about risk identification, they will uncover quite a few risks. Next, the team needs to decide which risks are major and need to be managed carefully, as opposed to those minor risks that can be handled more casually. The project team should determine how well they understand each risk and whether they have the necessary reliable data. Ultimately, they must be able to report the major risks to decision makers.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/4

Chapter 11: Project Risk Planning: 11-3a Perform Qualitative Risk Analysis Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

11-3a Perform Qualitative Risk Analysis

Perform qualitative risk analysis (the process of prioritizing risks for further analysis or action by assessing and combining their probability of occurrence and impact.) is “the process of prioritizing risks for further analysis or action by assessing and combining their probability of occurrence and impact.” All project teams should perform this analysis. If the project team understands enough about the risks at this point, it can proceed directly to risk response planning for the major risks. If not, they use more quantitative techniques to help them understand the risks better. The risk factor of a risk is the product of probability and consequence. Risks with higher risk factors are considered for quantitative analysis.

Differentiating Between Major and Minor Risks

Project teams use two primary questions in qualitative risk analysis: How likely is this risk to happen? If it does happen, how big will the impact be? This was shown in Exhibit 3.8. A somewhat more involved example is shown in Exhibit 11.9. Note that for each dimension— probability and impact—in Exhibit 11.10, a scale of 1 to 5 is used with descriptions. The scale used does not matter, as long as it is applied consistently and is easy for everyone to understand. Note also the dark line. This line separates the major and catastrophic risks that need either further analysis and/or specific contingency plans from minor and moderate risks that can just be listed and informally monitored. Without making a distinction like this, project teams may be tempted to either ignore all risks or to make contingency plans for all risks. Ignoring all risks is not desirable because it almost warrants that the project has problems. Making contingency plans for even minor risks is a terrible waste of time and draws focus away from the critical risks.

Exhibit 11.10

Qualitative Risk Assessment

Some people choose to make a finer distinction in their risk analysis by coding the biggest risks red, moderate ones yellow, and smaller ones green like stoplights. This may be good

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 2/4

practice on bigger, more complex projects. The important point is to make sure to have specific plans for big risks while not overreacting to small ones.

Teams should assess potential risks and predict possible outcomes involved in a project.

Paul Hennessy/Alamy Stock Photo

Project teams must ask, regarding each risk: When it is likely to occur in the project lifecycle? This can be useful because those risks that are likely to occur earlier often need to be assigned a higher priority. Teams may also inquire how easy it is to notice and correctly interpret the trigger condition. Risks with triggers that are difficult to notice or interpret often are assigned a higher priority.

Cause-and-Effect Relationships

One additional type of qualitative risk analysis is to determine cause-and-effect relationships. This is part of root cause analysis, which was described in the previous section on understanding relationships. While effects are often more visible, it is easier to change the effect by changing the underlying cause. For example, assume that a construction worker is not laying stones evenly for a patio (the effect). Perhaps the easiest way to ensure that future stones are placed evenly is to understand why the worker is having problems. The cause may turn out to be inconsistent stone size, incorrectly prepared

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 3/4

ground, the cement for holding the stones having bigger gravel than normal, or an improperly functioning leveling tool. Once the causes are understood, they can serve as trigger conditions to identify that a risk event may be about to happen. This knowledge is useful when developing responses to risks.

Cause-and-Effect Diagram

A tool that is useful in this analysis is the cause-and-effect diagram. Many project teams use this diagram to identify possible causes for a risk event. An example is shown in Exhibit 11.11.

Exhibit 11.11

Cause-and-Effect Diagram

The cause-and-effect diagram is also known as the fishbone diagram because its many lines make it look like the skeleton of a dead fish. To construct the cause-and-effect diagram, the project team first lists the risk as the effect in a box at the head of the fish. In this example, it is late delivery. The more specifically the risk is stated, the more likely it is that the team can uncover its real causes. The next step is to name the big bones. In this case, there are four big bones named people, machines, methods, and materials. There can be any number of big bones, and they can be named whatever makes sense to the team constructing the diagram. Team members are then encouraged to keep asking the question “Why?” For example: Why could people be a cause? Two reasons are shown: they are not trained properly or they are overallocated. Often, a team proposes many possible reasons. The team continues to break down the reasons—that is, asking “why” until it no longer makes sense to ask why. Cause-and-effect diagrams are frequently much fuller than this small example (Exhibit 11.11), with dozens of potential causes. Once the team no longer can think of possible causes, they need to determine which of the many possible causes are true causes. Selecting a few likely causes and then testing them can determine this.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 4/4

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/2

Chapter 11: Project Risk Planning: 11-3b Perform Quantitative Risk Analysis Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

11-3b Perform Quantitative Risk Analysis

Perform quantitative risk analysis (process of numerically analyzing the effect of identified risks on overall project objectives.) is “the process of numerically analyzing the effect of identified risks on overall project objectives.” While all projects use qualitative risk analysis, quantitative risk analysis is used only when necessary and only on selected risks. Bigger, more complex, riskier, and more expensive projects often can benefit from the additional rigor of these more structured techniques. Quantitative risk analysis is often used when predicting with confidence the probability of completing a project on time, on budget, and with the agreed-upon scope and/or when the agreed-upon quality is critical. Some of the more frequently used quantitative techniques follow:

Decision tree analysis (a graphic tool depicting alternative choices as branches, multiple options for each alternative, and evaluating potential outcomes in terms of uncertainty and monetary value.) : a graphic tool depicting alternative choices as branches, multiple options for each alternative, and evaluating potential outcomes in terms of uncertainty and monetary value.

Expected monetary value (EMV) analysis (a statistical technique to calculate present value of future outcomes to choose the best alternative. It is generally used for engineering economics and cost-benefit analysis.) : a statistical technique to calculate present value of future outcomes to choose the best alternative. It is generally used for engineering economics and cost-benefit analysis.

Failure mode and effect analysis (FMEA) (a step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service.) : “a step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service.”

Sensitivity analysis (a quantitative what-if risk analysis technique that presents comparative analyses of various desirable outcomes with respect to a financial measure or uncertainty.) : a quantitative what-if risk analysis technique that presents comparative analyses of various desirable outcomes with respect to a financial measure or uncertainty. It can be used to determine which risks have the most impact on the project outcomes or goals.

Tornado diagrams are often used to represent this analysis. A tornado diagram (a special type of bar chart and data where project goals are listed vertically and risk uncertainties are depicted horizontally as probability.) is a special type of bar chart

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 2/2

and data where project goals are listed vertically and risk uncertainties are depicted horizontally as probability. The order of presenting the categories is that that the largest bar appears on the top and the smallest bar appears at the bottom.

Simulation (a technique that mimics real situations using uncertainties and assessing their impact on project objectives.) : a technique that mimics real situations using uncertainties and assessing their impact on project objectives. In the context of projects, the simulation technique called Monte Carlo analysis develops probability distribution of risks and their impact on project goals such as cost and time.

Criteria to help select a suitable quantitative risk technique or methodology should do the following:

Use explicit knowledge of the project team members.

Allow quick response.

Help determine project cost and schedule contingency.

Foster clear communication.

Be easy to learn and use.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/1

11-3c Risk Register Updates

The probability of each risk occurring and the impact if it does happen are added to the register for each risk. The priority for each risk is also listed. Some organizations use a “Top 10” list to call attention to the highest-priority risks. In addition, some organizations choose to place higher priority on risks that are likely to happen soon. Some organizations want to call attention to risks that are difficult to detect—that is, risks with obscure trigger conditions. Any of these means of calling attention to certain risks are also listed in the risk register. If the project team performed any quantitative risk analysis, the results are also documented in the risk register.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/1

11-4 Plan Risk Responses Once risks have been identified and analyzed, the project team decides how they will handle each risk. Plan risk responses (process of developing options and actions to enhance opportunities and to reduce threats to project objectives.) is “the process of developing options and actions to enhance opportunities and to reduce threats to project objectives.” This is often a creative time for project teams as they decide how they will respond to each major risk. Sometimes a team develops multiple strategies for a single risk because they do not believe one strategy will reduce the threat or exploit the opportunity as much as the stakeholders would like. The team may decide that it is not worth the effort to eliminate a threat completely. In those cases, the goal is to reduce the threat to a level that the sponsor and other stakeholders deem acceptable.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/6

Chapter 11: Project Risk Planning: 11-4a Strategies for Responding to Risks Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

11-4a Strategies for Responding to Risks

Because so many possible strategies can be developed for dealing with project risks, it helps to classify the strategies. Common risk strategies are shown in Exhibit 11.12.

Exhibit 11.12

Common Project Risk Strategies

STRATEGY TYPE OF RISK EXAMPLES

Avoid Threat 1. Change project plan and/or scope

2. Improve project communications

3. Decide not to perform project

Transfer Threat 1. Insurance

2. Fixed-price contract

3. Hire expert

Mitigate Threat 1. Lower probability and/or impact of threat

2. Build in redundancy

3. Use more reliable methods

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 2/6

STRATEGY TYPE OF RISK EXAMPLES

Accept Threat and opportunity

1. Deal with it if and when it happens

2. Establish triggers and update frequently

3. Establish time and/or cost contingencies

Research Threat and opportunity

1. Get more and/or better information

2. Verify assumptions

3. Use prototype

Exploit Opportunity 1. Assign talented resources to project

2. Give more emphasis to project

Share Opportunity 1. Allocate partial ownership to third party

2. Form joint venture

Enhance Opportunity 1. Increase probability and/or positive impact

2. Identify and maximize key drivers

3. Add more resources

Source: Adapted from A Guide to the Project Management Body of Knowledge (PMBOK®

Guide) (Newtown Square, PA: Project Management Institute, 2008): 261–263; Paul S. Royer,

Project Risk Management: A Proactive Approach (Vienna, VA: Management Concepts, Inc.,

2002): 35; and Eric Verzuh, The Fast Forward MBA in Project Management, 2nd ed. (Hoboken,

NJ: John Wiley & Sons, 2005): 100–103.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 3/6

Leo/ Shutterstock.com

Avoid Risk

Many people prefer to avoid a risk if possible, and often, that is the best strategy. Sometimes, a project plan can be altered to avoid a risk by deleting the risky section or work element. For example, if the local police tell the organizers of a parade that traffic patterns on one section of their route are very difficult to control, perhaps they may alter the route. Project risk response strategy decisions often must be made with a thorough understanding of the key stakeholders’ priorities of cost, schedule, scope, and quality. In this example, if no powerful stakeholder had a strong interest in the exact route, the change might be easily made. However, project managers need to understand that every decision they make regarding risk response strategies may impact something else.

Another avoidance strategy is to ensure communications are good, especially concerning risky issues. Many risks can be more easily addressed with prompt and accurate information. The ultimate avoidance strategy is to not perform the project at all. This choice is sometimes made when the risks posed by the project are deemed unacceptably large compared to the potential benefits. Before a decision is made not to perform a project at all, normally each of the other strategies is considered.

Transfer Risk

Sometimes, a decision is made to transfer a part of or an entire project risk to another organization. One common means to do so is through insurance. Project insurance works like any other type of insurance: a premium is paid to another organization, which will assume a level of risk. Higher premiums need to be paid for more risk to be assumed (think of lower deductibles). Therefore, using insurance as a risk transfer strategy is a two-part

http://shutterstock.com/

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 4/6

decision: Do we transfer risk, and, if so, how much risk do we transfer? The answer generally is “enough so the overall risk is acceptable to key stakeholders.”

A second transfer strategy deals with the type of contract used. An owner wishing to transfer risk to a developer will want to use a fixed-price contract. The developer who accepts the risk would insist on a higher price to cover her uncertainty. A fixed-price contract can be used when the scope is well defined. A developer who wishes to transfer risk to an owner would prefer a cost-plus contract under which she is compensated for her cost plus a certain amount of profit. The owner, in turn, would prefer to drive for a low cost in such an arrangement because he is assuming the risk. This risk transfer strategy of using contracts is employed when the scope cannot be defined completely. Other types of contracts can be written so that both parties share the project risk.

A third risk transfer strategy is to hire an expert to perform the risk and to hold that person accountable. None of the transfer strategies eliminate risk; they just transfer the risk and let someone else assume it.

Mitigate Risk

Mitigation strategies are those in which an effort is made to lower risk. In general, this means either reducing the probability of a risk event happening and/or reducing the impact if it does happen. For example, a major risk could be that a key resource may not be available. To reduce the probability of that happening, perhaps the person could be hired well in advance of the project and then not be assigned to work on any other projects. To reduce the impact if this person were not available, perhaps the project team would like to use the second mitigation strategy of building redundancy. They could train another team member to do the work of the key resource. Redundancy is a way of life in systems projects. An example is building a redundant system when developing an aircraft to increase reliability and safety. However, we must be judicious in selecting redundancy because the weight of the aircraft would increase and could become prohibitive in cost. In such cases, a third mitigation strategy is often utilized: use more reliable methods. If the primary way of performing a key activity is highly reliable, there is less need for other mitigation strategies.

Accept Risk

A fourth risk response strategy is to accept the risk. This is often used for risks that are deemed to be minor. The project team deals with them if and when they happen. If the risks are deemed to be minor, most of them will not happen, and when they do, most will not cause major disruptions. However, some risks can have significant impact on the project if left untended. Therefore, project teams often define a trigger condition for some of these accepted risks. The trigger condition marks the dividing point where, instead of just monitoring the risk, the team starts to deal with it.

For fruit and vegetable growers in California, the trigger condition may be a weather report predicting cold temperatures. Armed with that knowledge, the growers enact strategies to protect their crops to the extent possible. The growers are willing to accept the risk of cold

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 5/6

weather occasionally because they make enough money at other times to compensate for the loss. If they were in a climate with more cold weather, they may choose not to grow sensitive crops during the cold season. One other acceptance strategy is to put contingencies of time and/or money into the project plan to cover the risks that transpire. Each of these acceptance strategies can also be used to take advantage of opportunities. All the strategies—establishing trigger conditions to notify the team when an opportunity is present, dealing with it as it happens, and having a little extra time and money to alter the project plans to reap the potential benefits—make sense. An example of these three strategies applied to an opportunity could be when a company develops a new style of hat, a celebrity wears it on TV, and then the demand takes off. By using more money to advertise to the unexpected customers, the company may generate many additional sales.

Research Risk

In certain instances, the best way to handle a risk is to learn more about it. The first research strategy, therefore, is to secure better and/or more information so the project team understands what they are dealing with. Projects often are conducted in a rapidly changing environment in which decisions need to be made quickly, often based upon imperfect and incomplete information. It is unusual to gather and verify all the information desired, and we may not be able to do so; however, at times it is useful to gather as much information as possible.

Another research strategy is to verify assumptions that have been made. Assumptions that prove to be false become risks. Yet another research strategy is to perform the project on a small scale first to see if it works. This can include developing a prototype, test marketing a new product, running new software in one department first, and so on. Project teams can often learn a great deal from trying their ideas on a small scale first. These research strategies work well for both reducing threats and capitalizing on opportunities.

Exploit Opportunity

One strategy that is aimed exclusively at opportunities is exploitation. A project manager may identify trigger conditions that, if reached, will allow her to go to her sponsor to request that the project be assigned a higher priority. If the organization wants to exploit opportunities, they can assign more or better resources to the project, remove barriers, and give it more visibility in management reviews.

Share Opportunity

One additional exploitation strategy deals with the results of the project. Perhaps the project team can develop a new product or service so revolutionary that the parent organization is not capable of fully exploiting it. In a case like this, the parent organization may spin off a nimble subsidiary, form a joint venture with another firm, or sell the rights to the product.

Enhance Opportunity

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 6/6

Essentially, a project team wants to either maximize the probability that an opportunity will occur and/or maximize the benefit if it does. The project manager wants to identify key drivers of these positive impacts and develop strategies to capitalize upon them. Certainly, adding more or better resources is one way to enhance opportunities.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/1

11-4b Risk Register Updates

The project manager sees that the risk register is updated with the results of the response planning. For each risk, the response strategy is noted. It also means that a single person is assigned as the “owner” of each risk, and that person is responsible for understanding the trigger and for implementing the strategy. Finally, any changes that need to be made to the project schedule, budget, resource assignments, and communications plan should be included.

Agile

Risks associated with agile projects are often associated with

development process conflicts, business process conflicts, and people conflicts. Development process conflicts relate to functionality and short and focused iterations. They are different from traditional projects that aim at optimizing development. Business process conflicts in agile projects are due to higher ambiguity and uncertainty that compel us to focus on short-term results and long- term haziness. Further, the WBS is developed incrementally.

On the other hand, agile projects demand that the product owner remain closely involved throughout the project. This focus can reduce risk because many details are handled as they arise. Also, since something of value needs to be delivered at each iteration with a test to confirm that it works, risks tend to be uncovered quickly, before they become too significant.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/1

11-5 PMP/CAPM Study Ideas As a project manager, your goal is to complete your project on time, on budget, at an agreed-upon level of quality, and to the satisfaction of your client and other stakeholders. Risks are anything that could impede—or help—you in this goal. Remember that, according to the Project Management Institute, project risks can be negative or positive. The strategies for dealing with negative risks, or threats, are as follows: avoid, transfer, mitigate, research, and accept. Conversely, the strategies for dealing with positive threats, or opportunities are the following: exploit, enhance, share, research, and accept.

In creating a risk management plan, the first step is to identify all possible risks. While it may seem counterintuitive (and, therefore, you may see a question or two about it on your CAPM or PMP test), you do not want to plan for all risks. That is why your next step is to categorize them based on both probability of occurrence and potential impact. Only the risks that emerge as “major” based on these two criteria are actively planned for. All projects make use of qualitative planning, and larger projects often proceed to quantitative planning (if may help you to remember that the “l” in qualitative comes alphabetically before the “n” in quantitative). You won’t need to be an expert, but you should be familiar with the most common quantitative assessments.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 1/2

Chapter Review

Summary

All projects have some risks. More unique projects have more uncertainties and unknowns and, therefore, more risks. A project manager needs to use an appropriate level of detail in risk planning—enough to plan for major risks, yet not so much that a great deal of time is spent on minor risks.

Risk management planning starts with understanding what constitutes success for the upcoming project. This may require understanding the trade-off decisions that key stakeholders are willing to make among the project scope, cost, time, and quality. Risk management planning is part of the overall project management plan and may be performed concurrently with other project planning components.

Identifying risks includes gathering information on potential risks. This can be accomplished by having the project core team and selected subject matter experts brainstorm all of the possible risks. Many times, a core team can review documents such as the project charter, WBS, communication plan, or schedule to help identify risks. The core project team can look beyond project documents for external risks using reviews of literature and consulting with external experts. Once risks have been identified, the core team creates the risk register with each risk categorized. Sometimes, a team also lists potential causes for each risk and potential responses.

The next major activity is to analyze the risks. At a minimum, this involves determining which risks are major—at least from the standpoints of how likely each risk event is to occur and how big of an impact it will have if it does occur. Sometimes, more sophisticated analysis is performed to identify the root causes of risks, to identify the trigger conditions that signify the risk event is about to happen, or to consider more complex relationships among risks. Quantitative techniques are sometimes used to determine which risks are major in terms of probability to occur and potential to impact project goals.

Risk response planning involves determining in advance how to respond to each major risk. Minor risks are handled by simply being aware of their potential and dealing with them if they occur. Eight types of risk response strategies that can be applied to major risks are avoid, transfer, mitigate, accept, research, exploit, share, and enhance. A project manager may decide to use multiple strategies on a large and critical risk. Armed with proper risk planning, a project manager can confidently begin even a risky project.

Chapter 11: Project Risk Planning Chapter Review Book Title: Contemporary Project Management

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376795&nbId=… 2/2

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&snap… 1/2

Chapter 12: Project Quality Planning and Project Kickoff Chapter Contents Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

Chapter 12 Project Quality Planning and Project Kickoff

Chapter Introduction

12-1 Development of Contemporary Quality Concepts 12-1a Quality Gurus

12-1b Total Quality Management/Malcolm Baldrige

12-1c ISO 9001:2008

12-1d Lean Six Sigma

12-2 Core Project Quality Concepts 12-2a Stakeholder Satisfaction

12-2b Process Management

12-2c Fact-Based Management

12-2d Fact-Based Project Management Example

12-2e Empowered Performance

12-2f Summary of Core Concepts

12-3 Plan Quality Management 12-3a Quality Policy

12-3b Quality Management Plan Contents

12-3c Quality Baseline

12-3d Process Improvement Plan

12-4 Manage Quality

12-5 Control Quality

12-6 Cost of Quality

12-7 Develop Project Management Plan 12-7a Resolve Conflicts

12-7b Establish Configuration Management

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&snap… 2/2

12-7c Apply Sanity Tests to All Project Plans

12-8 Kickoff Project 12-8a Preconditions to Meeting Success

12-8b Meeting Activities

12-9 Baseline and Communicate Project Management Plan

12-10 Using MS Project for Project Baselines 12-10a Baseline the Project Plan

12-10b Create the First Time Baseline

12-10c Subsequent Baselines

12-10d Viewing Baselines and Variances

12-11 PMP/CAPM Study Ideas

Chapter Review Summary

Key Terms Consistent with PMI Standards and Guides

Chapter Review Questions

Discussion Questions

PMBOK® Guide Questions

Exercises

Integrated Example Projects

Casa de Paz Development Project

Semester Project Instructions

Project Management in Action

References

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/4

Chapter 12: Project Quality Planning and Project Kickoff Chapter Introduction Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

Chapter Introduction

Bettmann/Getty Images

Chapter Objectives

After completing this chapter, you should be able to:

Core Objectives:

Define each core project quality concept and explain why each is vital in planning and managing projects.

Explain what may be included in a project quality management plan.

Compile a complete project management plan, including all parts covered in the last several chapters.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/4

PMBOK® Guide

Topics:

Plan quality management

Technical Objectives:

Baseline your complete project plan in Microsoft Project.

Behavioral Objectives:

Describe the major contributions to contemporary project quality made by each of the quality gurus and by TQM, ISO, and Six Sigma.

Kick off a project with effective premeeting preparation, a kickoff meeting, and documentation.

Develop a quality-conscious approach to managing project activities and decisions.

Founded in 1947, General Tool Company is a Cincinnati-based contract manufacturer of highly engineered defense and aerospace hardware. GTC’s Fortune 500 customers include Lockheed Martin, General Electric, General Dynamics, Raytheon, Boeing, and others.

Performing to the exacting standards of such a demanding clientele is an entry barrier that few contract manufacturers can overcome. A failure to provide objective quality evidence of sound and auditable project, risk, and quality planning systems can (and usually does) exclude would-be subcontractors from the bid and proposal process. For example, most major manufacturers of flight safety hardware are required to adhere to AS 9100c, which incorporates the well-known ISO 9001:2000 quality management system standards. In short, for GTC, proper quality planning is more than good project management—it is a matter of survival!

Quality and Risk

As if manufacturing highly complex, tight-tolerance aerospace and defense hardware is not challenging enough, the majority of related contracts transfer risk to the subcontractor through firm-fixed- price arrangements. Under such arrangements, the subcontractor agrees

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/4

Perform quality assurance

Control quality

Develop project management plan

Chapter Outputs

Project quality management plan

to manufacture hardware at an agreed- upon fixed price, assuming all risks associated with schedule and cost overruns (unless otherwise specified through an approved change order process).

In such an environment, it is imperative for the subcontractor to understand all quality and technical performance requirements prior to beginning the manufacturing process. Within GTC’s quality planning system, vendor selection requires special investigation to ensure the following criteria can be met:

The vendor is on the GTC “Approved Vendor” list.

The vendor is capable of providing the service in the required timeframe and has available capacity to meet the demand.

The vendor can meet all the procedural requirements and provide the required certifications for traceability and part pedigree.

Failing to “flow-down” all quality requirements at the start of a project can create significant, if not irreversible, challenges to part delivery. This makes the quality planning process especially important to companies operating within the firm-fixed-price environments, like GTC.

Few knowledge areas are more important than project quality management; and this is especially true where the safety of aviation and defense personnel are involved.

Source: Brad Brezinski, Jim Stewart, Korey Bischoff, and Mark Butorac of General Tool Corporation

Perhaps the best way to understand the contemporary approach to project management is to learn how the contemporary approach to project quality management developed. Many people have influenced the modern approaches to quality, and their contributions have largely been meshed together to give project managers a full understanding of project quality demands, processes, and tools. With this understanding, project managers are ready to perform project quality management—all the necessary work to ensure that project deliverables satisfy their intended purpose. This chapter includes the first part of project quality management, namely plan quality management (process of identifying quality requirements and/or standards for the project and its deliverables, and documenting how the project will demonstrate compliance.) , which is “the process of identifying quality requirements and/or standards for the project and its deliverables, and documenting how the project will demonstrate compliance.” The remaining parts of quality management are covered in Chapter 14.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 4/4

This is the final chapter dealing with project planning. Quality planning is often performed simultaneously with other aspects of project planning. In certain ways, quality of the project deliverable is integrated with scope planning as requirements are translated into specification with clearly defined qualitative and quantitative parameters based on standards and industry practices.

Once the various aspects of planning are complete, the project manager leads the team in sorting out any inconsistencies. The team then takes the completed project plan to the sponsor and other stakeholders for approval. Once the plan is accepted, it is communicated widely, and the project execution formally begins. Completing and approving the overall project management plan in this manner demonstrates how contemporary project management is integrative, iterative, and collaborative.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-1 Development of Contemporary Quality Concepts Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-1 Development of Contemporary Quality Concepts The contemporary approach to quality management has evolved first from the teachings of several quality “gurus” from the 1950s through the 1980s and then through various frameworks popularized during the last 25 years.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/3

Chapter 12: Project Quality Planning and Project Kickoff: 12-1a Quality Gurus Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-1a Quality Gurus

Arguably the most influential thought leader in quality was W. Edwards Deming. One concise way to summarize his ideas is his four-part Profound Knowledge System, shown in Exhibit 12.1. Deming started as a statistician and initially preached that understanding variation was essential to improving quality. By the time he had fully developed this system, he also stated that it is important to understand how companies operate as systems; that managers need insight in order to accurately predict the future; and that leaders need to understand individual motivations.

Exhibit 12.1

Deming’s Profound Knowledge System

Systems Interactions occur among parts of a system, and parts cannot be managed in isolation.

Variation Managers need to understand common and special causes of variation and then work to reduce both.

Knowledge Managers need to learn from the past and understand cause-and-effect relationships to predict future behavior.

Psychology Leaders need to understand what motivates each individual and how different people and groups interact.

Source: Adapted from James R. Evans and William M. Lindsay, The Management and Control

of Quality, 8th ed. (Mason, OH: Cengage Learning South-Western, 2011): 94–99.

Joseph Juran, who was a contemporary of Deming, also wrote and lectured prolifically for decades. Juran is perhaps best known for his Quality Trilogy of quality planning, quality control, and quality improvement, as shown in Exhibit 12.2. The PMBOK® Guide coverage of quality largely mirrors Juran’s approach.

Exhibit 12.2

Juran’s Quality Trilogy

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/3

Quality Planning Identify all customers and their needs, develop requirements based upon those needs, and develop the methods to satisfy those requirements.

Quality Control Determine what to control, establish measurement systems, establish standards, compare performance to standards, and act on differences.

Quality Improvement Select and support improvement projects, prove causes, select and implement solutions, and maintain control of improved processes.

Source: Adapted from James R. Evans and William M. Lindsay, The Management and Control

of Quality, 8th ed. (Mason, OH: Cengage Learning South-Western, 2011): 104–106.

Many other pioneers in quality, particularly Japanese and American, have added to the body of quality concepts and tools. Several of the most influential thought leaders and their contributions that apply specifically to project quality are shown in Exhibit 12.3.

Exhibit 12.3

Other Project Quality Pioneers

THOUGHT LEADER ADDITIONAL KEY PROJECT QUALITY CONTRIBUTIONS

Clifton High-quality organizations encourage individuals to develop their strengths.

Crosby Quality is meeting requirements, not exceeding them.

The burden of quality falls on those who do the work.

Quality costs least when work is done correctly the first time.

Quality improves more by preventing defects rather than fixing them.

Harrington Business processes can be improved using a systematic method.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/3

THOUGHT LEADER ADDITIONAL KEY PROJECT QUALITY CONTRIBUTIONS

Ishikawa Quality outputs start with understanding customers and their desires.

Work to identify and remove root causes, not just symptoms.

All workers at all levels must engage to improve quality.

Most quality problems can be solved by using simple tools.

Senge Team learning is necessary to improve quality.

Shiba Societal networking accelerates quality improvement.

When continual improvement is not enough, a breakthrough is needed.

Taguchi Reducing variation saves money.

Project deliverables will be better with a focus on improving methods.

Zeithaml Services pose different challenges from manufacturing when improving quality.

Much of the work of these pioneers and many others has been incorporated into three popular frameworks that many organizations use to define and organize their quality initiatives. These frameworks are Total Quality Management (TQM), the International Organization for Standardization (ISO), and Six Sigma.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/2

Chapter 12: Project Quality Planning and Project Kickoff: 12-1b Total Quality Management/Malcolm Baldrige Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-1b Total Quality Management/Malcolm Baldrige

TQM came into vogue during the late 1980s when it was becoming more widely apparent that the old way of trying to catch quality problems by inspection was not adequate. Many early advocates of TQM used slightly different ways of describing it. What they had in common was implied by the first word in the name: total. Most serious practitioners included several components in their TQM system. In the United States, government, business, consulting, and academic specialists in quality worked together to develop a common means of describing TQM. This description forms the key areas of the Malcolm Baldrige National Quality Award, as shown in Exhibit 12.4.

Exhibit 12.4

Malcolm Baldrige National Quality Award Key Areas and Specific Criteria

KEY AREA SPECIFIC CRITERIA

1. Leadership Senior leaders’ personal ethical behavior and integrity

Organization governance system

2. Strategic Planning Develop strategic objectives and action plans

Deploy strategic objectives and action plans

Measure progress

3. Customer Focus Engage customers

Build customer-focused culture

Listen to voice of customer and use this information to improve

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/2

KEY AREA SPECIFIC CRITERIA

4. Measurement, Analysis, and Knowledge Management

Select, gather, analyze, manage, and improve data, information, and knowledge assets

Manage information technology

Reviews and uses reviews for performance improvement

5. Workforce Focus Engage, manage, and develop workforce; assess workforce capability and capacity; build workforce environment conducive to high performance

6. Operations Focus Design, manage, and improve work systems

Design, manage, and improve key processes

Prepare for emergencies

7. Results Performance and improvement in all focus areas

Performance levels relative to competitors

Source: Adapted from

https://www.nist.gov/sites/default/files/documents/baldrige/publications/Baldrige_20_20.pdf,

accessed April 10, 2017.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/2

Chapter 12: Project Quality Planning and Project Kickoff: 12-1c ISO 9001:2008 Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-1c ISO 9001:2008

While the Baldrige Award is a framework developed in the United States, ISO represents a framework developed in Europe. The International Organization for Standardization has developed many technical standards since 1947. ISO 9001 is the quality management standard, and the 2015 designation is the latest revision of the standard. When the standards first appeared, they focused largely on documenting work processes. However, over the years, the standards have evolved, and the current seven quality management areas with specific requirements are shown in Exhibit 12.5. Notice that they contain many of the same ideas as the current Baldrige Award key areas and specific responsibilities.

Exhibit 12.5

AREA SPECIFIC REQUIREMENT

Context Understand your organization and its unique context

Clarify the needs and expectations of interested parties

Define the scope of your quality management system (QMS)

Leadership Focus on quality and customers

Establish a suitable quality policy

Define roles and responsibilities

Planning Define actions to manage risks and address opportunities

Set quality objectives and develop plans

Plan changes to your QMS

Support Provide the necessary resources

Ensure that people are competent and know how to help

Manage your communications and documentation

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/2

AREA SPECIFIC REQUIREMENT

Operations Develop, implement, and control your operational processes

Determine and document product and service requirements

Control product and service release

Control nonconforming outputs and document actions taken

Evaluation Monitor, measure, analyze, and evaluate QMS performance

Use internal audits to examine conformance and performance

Carry out management reviews and document your results

Improvement Determine improvement opportunities and make them

Control nonconformities and take corrective action

Enhance the effectiveness of your QMS

Source: Adapted ISO 9001 2015 Translated into Plain English, http://www.praxiom.com/iso-

9001.htm and ISO/DIS Quality Management Systems-Guidelines for quality management on

projects, https://www.iso.org/obp/ui/#iso:std:iso:10006:dis:ed-3:v1:en, accessed April 10, 2017.

http://www.praxiom.com/iso-9001.htm

https://www.iso.org/obp/ui/#iso:std:iso:10006:dis:ed-3:v1:en

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/2

Chapter 12: Project Quality Planning and Project Kickoff: 12-1d Lean Six Sigma Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-1d Lean Six Sigma

Lean evolved from lean manufacturing ideas of eliminating as much waste as possible from work processes. Sigma stands for standard deviation—a statistical term for the amount of variation in data. Six Sigma quality literally means quality problems are measured in parts per million opportunities. Many projects have few routine activities and many unusual and nonroutine activities, so the rigor of the statistics in Six Sigma is not always applicable. However, the ideas behind Six Sigma provide a meaningful framework for project quality. As of this writing, Six Sigma is a popular approach to quality as Motorola, General Electric, and many other companies have promoted its application and usage. General Electric, in particular, expanded the focus of Six Sigma to include many service processes that people had previously said were too difficult to measure.

Six Sigma uses a disciplined process called the define, measure, analyze, improve, and control (DMAIC) process to plan and manage improvement projects. The DMAIC methodology is a 15-step process broken up into five project phases: define, measure, analyze, improve, and control, as shown in Exhibit 12.6. The DMAIC process is illustrated to show objectives within each of the five key stages. It is shown as a continuous, circular flow because DMAIC is typically used as a method of implementing continuous improvement and thus can be practiced repeatedly. Lean Six Sigma uses DMAIC and waste elimination together to improve performance.

Exhibit 12.6

The DMAIC Methodology

Source: Timothy J. Kloppenborg and Laurence J. Laning, Strategic Leadership of Portfolio and Project

Management (New York: Business Expert Press, 2012), 122.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/2

Agile

On agile projects, quality is planned at a high level for the entire project at

the outset and at a detailed level just before the start of each iteration. Therefore, you might envision conducting the equivalent of a small kickoff meeting and plan for each iteration rather than a large one for the entire project.

All of the gurus and approaches described above have a general characteristic in common. They all build upon established technical approaches with an increased emphasis on human behavior. Agile does the same in terms of project management. While some agile proponents deemphasize many project management techniques, essentially, agile builds upon good project practice and much of what is added emphasizes behavioral possibilities. Just as total quality dramatically changed general management in the 1990s, agile is dramatically changing project management in the 2010s.

In agile projects, the conditions of acceptance are the proxy for quality. We have general quality requirements for all stories, like it must run on this set of web browsers. We must have unit test coverage above 90 percent, and so forth.

As an agile thought exercise, consider what the quality expectations are for an e-mail. This similar to the discussion that the Product Owner and team may have while they are refining a story in the backlog.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-2 Core Project Quality Concepts Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-2 Core Project Quality Concepts Each of the quality gurus and frameworks provides input into the contemporary understanding of project quality. When defining quality, a number of perspectives should be considered, including:

Product—the presence of desired attributes

Value—the ratio of benefits to price

Manufacturing—consistency in goods and services

Customers—ability to satisfy given needs and expectations

We condense these ideas, as stated in Chapter 1, into a simple definition of project quality (the characteristics of a product or service that bear on its ability to satisfy stated or implied needs.) : “the characteristics of a product or service that bear on its ability to satisfy stated or implied needs.” Remembering that customer satisfaction is the most important goal on most projects, this emphasis on satisfying needs is critical to project success. However, to fully understand both the meaning of this definition and how to achieve it, one needs to understand the four contemporary core project quality concepts that have evolved from the sources above:

1. Stakeholder satisfaction

2. Process management

3. Fact-based management

4. Empowered performance

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/2

Chapter 12: Project Quality Planning and Project Kickoff: 12-2a Stakeholder Satisfaction Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-2a Stakeholder Satisfaction

Stakeholder satisfaction (identifying all stakeholders and understanding the stakeholders’ ultimate quality goals using a structured process to determine relevant quality standards.) consists of identifying all stakeholders and understanding the stakeholders’ ultimate quality goals using a structured process to determine relevant quality standards. External stakeholders may include customers, suppliers, the public, and other groups. Internal stakeholders may include shareholders and workers at all levels and all functions within the organization.

Developing Quality Standards Based upon Stakeholder Requirements

The decision process for developing relevant quality standards on a project consists of the following steps:

Identify all stakeholders.

Prioritize among the stakeholders.

Understand the prioritized stakeholders’ requirements.

Develop standards to ensure the requirements are met.

Make trade-off decisions.

Some stakeholders actively participate in the process of developing quality standards. Therefore, they make judgments about the quality of a process based on what they see. Thus, the quality both of project work processes and of deliverables is monitored and judged. When making trade-off decisions, the project manager often facilitates the process, and the stakeholders actually make the decisions. Stakeholders frequently need to be reminded that the relative importance of cost, schedule, scope, and quality can be very

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/2

helpful in determining sensible standards. Often, quality costs money and requires more time. Sacrificing quality may save money and time, but the stakeholder satisfaction could be in jeopardy.

Stakeholder Satisfaction Sayings

When satisfying stakeholders, it is helpful to remember a few sayings. One is the old carpenters’ advice of “measure twice, cut once.” This careful planning tends to yield less variation, less cost, and faster delivery—all of which satisfy stakeholders. Another saying is “meet requirements, but exceed expectations.” Contractually, a project must meet the agreed-upon specifications, but if stakeholders see excellent work processes and experience clear communications, their expectations will be exceeded, and they will be even happier. This point regarding meeting requirements while exceeding expectations comes from two sources. Good project management practice is to meet requirements without spending extra money or time. Good quality practice is to not only satisfy but also to delight customers. The third saying is “a smart project manager develops capable customers.” That means the customer is able to use the project deliverables to do his or her job better. This often results in opportunities for additional revenue streams by partnering, training, and supporting the customer.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/4

Chapter 12: Project Quality Planning and Project Kickoff: 12-2b Process Management Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-2b Process Management

A process (a sequence of linked activities that is intended to achieve some result, such as producing a good or service for a customer.) is “a sequence of linked activities that is intended to achieve some result, such as producing a good or service for a customer.” To effectively manage project processes, project managers need to understand, control, and improve them.

Process Understanding with a Sipoc Model

The first part of understanding a project is to demonstrate that all work flows from suppliers, through the project, to customers. A useful way to envision this is a tool called a supplier- input-process-output-customer (SIPOC) model, as shown in Exhibit 12.7.

Exhibit 12.7

PDE Deliverable Analysis Functional Model

An illustration depicts the PDE deliverable analysis functional model. An arrow labeled as Input points the Supplier, Upstream Functional Interface to the Deliverable process. A flowchart representing a set of connected processes is shown as a deliverable process. An arrow labeled as Deliverable points the deliverable process to the customer, Downstream functional interface. The text associated with the arrows input and Deliverable reads, Qualities; Characteristics; Standards; Localized Items; Timing; Conditional Needs. An arrow marked with $ also points to the deliverable process and the text associated with the arrow reads, Resources: Labor/Skill Sets; Materials/Equipment; Vendors; Applications. An arrow labeled as Deliverable adjustment Feedback points the customer to the deliverable process. An arrow labeled as the Input adjustment feedback points deliverable process to the supplier.

Source: Paul Kling, PMP.

In Exhibit 12.7, the process boundaries are clearly defined. This prevents future scope creep from occurring by eliminating previous or later steps in the process. The SIPOC above also begins to identify key stakeholders who both provide inputs into the process (suppliers) and receive benefits from the process (customers) and shows feedback loops that provide useful information.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/4

One way to interpret the SIPOC is to think backward from the project’s customers. As described previously in the stakeholder satisfaction section, it is helpful for a project manager to identify all the customers for his or her project and their desired outputs. Since that is usually a far-reaching list, prioritization decisions need to be made. At that point, the project manager can work with the project core team to define the work processes necessary to create those outputs. Then they can identify the inputs to accomplish those activities and determine who will supply them.

Once the supplier-customer view is understood, it is time to determine whether the process is capable of creating the project deliverables. This discussion should be initiated when the project charter is developed. As people discuss the milestone schedule, risks, and constraints, any serious doubts people have should be raised. On some small projects, that may be enough to determine if the proposed methods of creating the project deliverables will work. On others, more detailed analysis of schedule, resources, and risks may yield further insight. When considering if a project process is capable, the project manager needs to understand the conditions in which the project may operate and ensure that the methods can be flexible enough to handle various contingencies that might develop.

Experienced project managers understand that it is far better to design quality into their processes than to find problems only upon inspection. In the first place, it costs more to make junk and then remake to obtain good outputs. Second, having to rework anything aggravates time pressure that already exists on many projects. Finally, even the best inspectors do not find every mistake, and some of the mistakes are likely to reach customers.

Process Control

The second aspect of process management is process control. Control (the activity of ensuring conformance to the requirements and taking corrective action when necessary to correct problems and maintain stable performance.) is “the activity of ensuring conformance to the requirements and taking corrective action when necessary to correct problems and maintain stable performance.” The purpose of process control is to have confidence that outputs are predictable. Process control is covered in Chapter 14. If the outputs are not predictable—or if they are predictable but not satisfactory—then a project manager needs to use the third aspect of process management: process improvement.

Process Improvement with a PDCA Model

Processes can be improved in either a continuous or a breakthrough fashion. All project core team members and subject matter experts (SMEs) should be thinking of little ways they can improve at any time. Slow and steady improvement is a good foundation. However, sometimes substantial improvement is necessary, and a breakthrough is in order. Regardless of the size of improvement desired, many models exist to guide the effort. Improvement models such as DMAIC are usually based upon the plan-do-check-act (PDCA) improvement cycle, as displayed in Exhibit 12.8.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/4

Exhibit 12.8

Plan-Do-Check-Act Model

A four-part pie chart depicts the Plan-Do-Check-Act model represented as a cycle. The four parts of the circle are labeled as A, P, C, and D. The data read in clockwise from top left are as follows: A represents, Act, the corresponding text reads, If results are good enough, implement the improvement, otherwise try again. P represents Plan, the corresponding text reads, Select needed improvement, understand process and reasons for trouble, and create a plan. D represents Do, the corresponding text reads, Try the change on a small scale and collect data. C represents Check, the corresponding text reads, Compare the results after the change with those before to see if there was an improvement.

When project managers are considering process improvements, they often involve suppliers and/or customers in a partnering arrangement. Often, they need to forecast changes in their work environment, technology, or customer desires. Organizations that take a balanced view of long-term improvement and short-term results create a culture in which project process improvement can thrive. Organizations that focus almost exclusively on short-term results make it hard for project managers to devote much energy to process improvement.

Even with good inspectors, somemistakes will reach customers if poor quality exists in project processes.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 4/4

A photo shows a lady observing the working of a baking unit.

Akimov Igor/ Shutterstock.com

http://shutterstock.com/

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/3

Chapter 12: Project Quality Planning and Project Kickoff: 12-2c Fact-Based Management Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-2c Fact-Based Management

One challenge many project managers face is making decisions based upon facts. Making decisions using facts sounds like an obvious thing to do, yet it is difficult because:

Opinions get in the way.

It is hard to know what data need to be collected.

Projects often operate with so much time pressure that decisions need to be made quickly.

Four aspects of fact-based management (understanding variation, deciding what to measure, working correctly with data, and using the resulting information appropriately.) are understanding variation, deciding what to measure, working correctly with data, and using the resulting information appropriately.

Understanding Variation

Project decision makers need to understand the difference between two types of variation. A common cause is variation that is a result of the product design and the method of making it and is exhibited by a random pattern within predictable limits. On the other hand, a special cause is variation that comes from external sources that are not inherent in the process and can be quite unpredictable. It is important to determine when there is variation on a project whether it is within the range of what can be expected for that particular work activity or deliverable (common cause) or whether something unusual is happening (special cause). If the variation is due to a common cause, but the results are still not acceptable, some change needs to be made to the system—the way in which the work is accomplished. However, if the change is due to a particular cause, then the way to improve is to change that particular cause and not the entire system. Many quality proponents estimate that a large majority of variation is due to common causes, yet many managers are quick to try to find a person or issue to blame (special cause). The problem is often compounded when a cause is really part of the system, yet individuals are blamed. The problem does not go away, and people become fearful. Management by facts requires an understanding that variation can be due to either common or special causes, a determination to discover which type, and the resolve to act appropriately upon that discovery.

Determining What to Measure

A project manager wants to avoid the extreme of not measuring anything since he or she is in a hurry and there is not enough time and the other extreme of measuring many things just to be sure. As project managers become more experienced, they develop an understanding

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/3

(1)

(2)

(3)

(4)

of how many data are useful to collect and when they need to move into action regardless of the data they have.

A quality metric (a measurement used to ensure customers receive acceptable products or deliverables.) is “a measurement used to ensure customers receive acceptable products or deliverables.” Measures may include project attributes such as on-time or on-budget performance or product attributes such as defect frequency. A milestone schedule, in a good project charter, with acceptance criteria for each milestone can provide useful measures. Project teams often can seek useful measures when they study lessons learned from previous projects. Many lessons state either what worked well and should be repeated on future projects or what worked poorly and should be avoided on future projects. Both of these aspects can provide ideas for useful measures. The project manager and sponsor should agree on what measures will be taken, when they will be taken, and under what circumstances. While many sponsors can be quite busy, the more specific this agreement becomes, the more useful the data collected are likely to be.

Working Correctly with Data

A third aspect of management by facts is how the identified data are collected, handled, and stored. Data (information in a raw or unorganized form that refer to, or represent, conditions, ideas, or objects.) is information in a raw or unorganized form that refer to, or represent, conditions, ideas, or objects. Generally, the persons closest to the situation are best for collecting data. Efforts should be made to ensure that the data are complete, without errors, and timely. Many project teams either use templates from their organization or create their own forms for collecting data. When more than one person is involved, consistency must be ensured. Once the data are collected, they should be analyzed. A great deal can be learned by using simple tools to look for patterns and trends in data. On larger, more complex projects and sophisticated Six Sigma projects, more detailed statistical analysis is often used. The analysis should turn the raw data into information for decision making.

Using the Resulting Information Appropriately

The final aspect of making fact-based decisions is how the information is used. Information (data that is (1) accurate and timely, (2) specific and organized for a purpose, (3) presented within a context that gives meaning and relevance, and (4) can lead to an increase in understanding and decrease in uncertainty.) is data that is

accurate and timely,

specific and organized for a purpose,

presented within a context that gives meaning and relevance, and

can lead to an increase in understanding and decrease in uncertainty.

Project communications plans often spell out how the information is disseminated. The best project cultures encourage facts and transparency in communication—even when it is

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/3

inconvenient. People are encouraged to use information to challenge opinions and decisions. Making decisions based upon facts often requires courage. It also requires judgment because challenges that are of a factual nature are helpful; yet, if the challenges become personal and are not fact based, they can be destructive and demotivating.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/2

Chapter 12: Project Quality Planning and Project Kickoff: 12-2d Fact-Based Project Management Example Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-2d Fact-Based Project Management Example

A rapidly growing, fast, casual restaurant chain was experiencing growing pains that were manifest in delays for restaurant openings. SWOT analysis revealed a number of broad issues that were threats to opening the restaurants on time, but the issues needed to be quantified for improvement. The company had been keeping records on the time required to open a restaurant after breaking ground. Exhibit 12.9 shows that 80 percent of the restaurants opened within 160 days or fewer, but some of the others took much longer. At $5,000 lost revenue per day for the franchisee and a 4 percent loss for the franchisor, it was in the interest of all stakeholders to dissect the facts and determine the causes for delayed openings. With the anticipation of expanding to an additional 500 restaurants in the next two to three years, every improvement of one day would result in a $0.5 M increase to revenue, assuming the same 20 percent of the troubled projects were lagging the average for the 80 percent of excellent or healthy performing projects. The corporate franchising organization needed to determine the root cause of the delays.

Exhibit 12.9

Days from Breaking Ground to Opening

Exhibit 12.10 is a Pareto chart showing the frequency of causes in the troubled projects. Seven causes for delays were identified for the troubled projects. The top four causes were

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/2

found in 80 percent of the troubled projects. This led to a focus on improving projects by better managing the risks associated with each cause or by making changes to management processes that were negatively impacting the project’s time objective. Based on root cause information, a risk breakdown structure was used to categorize threats causing delays and develop appropriate responses to avoid or mitigate the risks for future openings.

Exhibit 12.10

Frequency of Causes in the Troubled Projects

Source: Scott C Wright, PhD, P.E., PMP (University of Wisconsin–Platteville)

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/3

Chapter 12: Project Quality Planning and Project Kickoff: 12-2e Empowered Performance Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-2e Empowered Performance

The fourth and final core project quality concept is empowered performance. The goal of empowered performance is to have capable and willing workers at every level and every function within a company. Corporate leaders set the stage for this by developing the organizational culture. Project sponsors and managers, in turn, develop the project culture. Remember from Chapter 4 that organizational culture includes the formal and informal practices utilized, along with the values shared by members of an organization. Part of an empowered performance culture is setting an expectation for managers to encourage their associates to take appropriate risks and to treat risk events as learning opportunities, not as a time to punish. Part of it is training and equipping workers so they are willing to take risks. Part is getting managers to let go of some decision-making authority so those lower in the organization can make some decisions. Yet another aspect of empowered performance is helping to develop specialists who can aid anyone in the organization. For example, a person trained as a Black Belt in a Six Sigma organization can become an expert in guiding process improvement projects, or an internal coach/mentor in an organization that is adopting agile can observe the team and provide suggestions.

Recognize Individuality

One essential understanding in creating capable and willing workers is to recognize everyone’s individuality and diversity. Leaders at all levels must promote inclusiveness and recognize that diversity is not only to be accepted, but it is also very helpful as projects develop.

Capitalize on Individual Strengths

Outstanding project managers not only want to recruit people with unique skills and develop a strong project team, but they also want to capitalize on each person’s strengths. Every team member feels validated when he uses his unique skills and gets an opportunity to improve them. When a person feels his boss understands him and works to create opportunities for him to do both what he most wants to do and what he has the potential to be best at doing, he is motivated to perform at the highest level.

Emphasize Individual Responsibilities

Empowered performance requires that people understand and accept their responsibilities. Much of the responsibility falls upon the project manager and core team. However, SMEs are responsible for their individual activities. Functional managers, who are the technical supervisors of the SMEs, are responsible for work methods in their functional areas. Sponsors share a high-level responsibility for project completion with project managers. Customer representatives are responsible for understanding the impact of directives they

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/3

may give a project manager. Ultimately, everyone must understand what they need to do, realize how it fits in the bigger picture, and then commit to both completing their work correctly and accepting the consequences of their decisions.

Use Appropriate Collaboration

Finally, appropriate collaboration is a key to developing empowered performance. This is true both within and beyond the organizational boundaries. Cross-functional teams perform a great deal of project work and are most effective when individual, team, and organizational learning flourishes. One effective method of encouraging this learning in projects is to develop lessons learned at the completion of project milestones and at project closure. These lessons then need to be shared openly with other project teams. Collaboration and learning accelerate when people share information outside their parent organization. Of course, some things such as information that provides a competitive advantage cannot be shared, but a surprising number of things can be shared. When the recipients of those lessons reciprocate, the first team learns something new. This type of external sharing can take place through conferences, company exchanges, or other means. An example of a unique project challenge that required empowered performance to be successful is the vintage aircraft-shipping project in Exhibit 12.11.

Exhibit 12.11

Vintage Aircraft Shipping Project

Global Shipping Company (GSC) was approached by an individual who was interested in selling and shipping an antique $1 million 1942 Staggered-Wing Beech aircraft from Cincinnati to a buyer in Australia. Since the aircraft was fragile, a plan needed to be developed for moving it as economically as possible while avoiding damage.

One challenge was handling the entire project in-house using only the company’s staff, equipment, and resources, and the other was devising a custom solution for moving this unusual piece of cargo.

GSC has an organizational culture that encourages cross-training, collaboration among departments, risk-taking, and designing creative approaches to problem solving while minimizing cost. Because of the size and fragility of the aircraft, a strategy was devised to dismantle it and ship via containerized ocean freight. The project was broken down into five distinct segments: pickup, dismantling, packing, loading, and shipping.

To pick up the entire aircraft, the equipment, permits, and escorts had to be arranged to get the aircraft intact from the airport and move it to the warehouse down a major street on the back of a flatbed truck. In order to fit in a standard ocean container, the aircraft had to be dismantled—under the supervision of the FAA—and documented to meet FAA regulations. To avoid damage, each piece had to be individually packaged. Different types of cloth and foam had to be tested and selected in order to prevent scratching the aircraft. Due to the height restrictions, the warehouse personnel had to design and build a custom gurney to allow the body of the plane to be wheeled into the container and secured. Once packaged,

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/3

the individual pieces were then loaded, blocked, and braced into the container to prevent damage while in transit; then the aircraft was shipped. The dismantling, documentation, and packing process was designed in a way that the new owner of the aircraft could replicate it in order to move the plane for air shows and events.

The project’s success was achieved by having the courage to take on the project in the first place, the ability to use the company’s resources creatively and efficiently, and the ability to adapt the plan when unexpected events occurred. The result was a project that was successfully completed, meeting all FAA standards, exceeding stakeholder expectations, and developing a shipping process that can be replicated.

Source: Danny McKee, Global Shipping Company.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/3

Chapter 12: Project Quality Planning and Project Kickoff: 12-2f Summary of Core Concepts Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-2f Summary of Core Concepts

A summary of project quality core concepts is shown in Exhibit 12.12.

Exhibit 12.12

Summary of Project Quality Core Concepts

CONCEPT SPECIFIC GUIDANCE

Stakeholder

Satisfaction

Identify all internal and external stakeholders.

Prioritize among the stakeholders.

Understand the prioritized stakeholders’ requirements.

Develop standards to ensure the requirements are met.

Make trade-off decisions.

Realize stakeholders will judge quality both of work processes and deliverables. Measure twice, cut once. (Plan and check the plan.)

Meet requirements, but exceed expectations.

Develop capable customers.

Process Improvement

Learn about process with the supplier-input-process- output-customer model. Realize designing a quality process is far better than merely trying to find mistakes.

Ensure project processes are capable and flexible.

Control project processes to make them predictable.

Improve project processes using a model based upon the plan-do-check-act concept.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/3

CONCEPT SPECIFIC GUIDANCE

Fact-Based Management

Understand the difference between common and special causes of variation. Select a few key well-defined items to measure.

Carefully collect data and use appropriate analysis techniques to create useful information.

Encourage truthful, transparent, and challenging communication when making decisions.

Empowered Performance

Develop capable and willing workers at every level and every function.

Develop a risk-taking project culture.

D Understand each person is an individual.

To the extent possible, let everyone do what they will enjoy doing and what their strengths support.

Ensure everyone understands and accepts their responsibilities.

Share lessons learned and other information as widely as possible.

Agile

Advice given on agile projects is to communicate often (maybe daily) with

the owner and other stakeholders. This is good advice for any project. This approach provides shorter faster feedback loops. Everything in this section applies to agile. It is a discussion of how much of these tools you need for the product of the project.

As such, an agile project deliverable often goes through routine quality checks and tests to confirm desired performance and these checks are used as feedback to modify project management processes and plans. Customer involvement throughout the project execution presents the unique advantage of quality audit and control.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/3

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-3 Plan Quality Management Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-3 Plan Quality Management The quality management plan (defines the acceptable level of quality, which is typically defined by the customer, and describes how the project will ensure this level of quality in its deliverables and work processes.) “defines the acceptable level of quality, which is typically defined by the customer, and describes how the project will ensure this level of quality in its deliverables and work processes.” Therefore, a logical place to start is by understanding what a quality policy is and how it governs the actions of a project manager and team. The remainder of this section discusses the components of a project quality management plan and process improvement plan.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/3

Chapter 12: Project Quality Planning and Project Kickoff: 12-3a Quality Policy Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-3a Quality Policy

The top management of an organization normally writes a concise statement to guide their company’s quality efforts. This policy reflects top management’s principles of achieving quality and the benefits they hope to achieve with good quality. Project managers normally first consider using the quality policy of their parent company—if it is a good fit. If not, or if the project is a partnership between organizations, the project manager may need to combine and/or supplement the quality policies. However, the project’s quality policy should never violate the intent of the quality policies of either the parent company or of a major customer.

A study of 25 organizational quality policies in 2017 found that they vary widely. Some are fewer than 30 words, while others are over 100 words. The content and style can be quite different. The frequency of terms that interest project managers is shown in Exhibit 12.13.

Exhibit 12.13

Evolution of Terms in Quality Policies 2013 to 2017

TERM

PERCENT OF POLICIES IN 2013

PERCENT OF POLICIES IN 2017

Customer 92 80

Improve Process 84 80

Satisfy Requirements/Meet Standards or Laws

68 72

Sustainable/Reliable/Dependable 36 64

Employee 44 60

Commitment/Leadership 40 52

Product 72 48

Best/Excellent/High Quality/Exceed Requirements

44 44

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/3

TERM

PERCENT OF POLICIES IN 2013

PERCENT OF POLICIES IN 2017

Service 64 36

Value/Cost 56 28

Communication 28

Suppliers 16 24

Safety/Risk 16 20

Several interesting patterns can easily be found. First, the most frequent terms are customers and improving processes. Many include satisfying requirements, but very few include exceeding requirements. This means that, for most companies, quality is measured by how well requirements are met, not surpassed. A large percentage of policies mention both products and services—a reminder to project managers that services and information are frequently needed along with products to satisfy a customer’s needs.

What is interesting is that five concepts now appear in a higher percentage of quality policies than a few years ago:

1. Sustainability

2. Employee engagement

3. Leadership and commitment

4. Communication

5. Suppliers

This shows that more organizational leaders are concerned both with sustainability and with a variety of behavioral aspects of great project leadership. Remember, many of these policies are very short and only include a few key thoughts. They are meant to set direction, not plan detail.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/3

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-3b Quality Management Plan Contents Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-3b Quality Management Plan Contents

In addition to the quality policy, most project quality management plans describe which quality standards the project will use and how the project team will implement them. The quality management plan may include a description of the quality baseline by which the project will be judged, along with methods for quality assurance and control.

The quality management plan is a portion of the overall project management plan. On many small, simple projects, the quality planning is performed concurrently with other planning, and the quality plan is seamlessly incorporated into the project plan. On some large, complex, or unusual projects, the quality planning is handled separately, and the plan, while a portion of the overall project plan, appears as an additional plan document.

A project quality management plan should describe how to identify some or all of the following:

Quality objectives

Key project deliverables and processes to be reviewed for satisfactory quality level

Quality standards

Quality control and assurance activities

Quality roles and responsibilities

Quality tools

Plan for reporting quality control and assurance problems

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-3c Quality Baseline Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-3c Quality Baseline

At the point of developing the quality baseline, the project work should be clearly defined in a scope statement and/or a work breakdown structure. Appropriate quality standards are selected for the materials and other inputs, work activities, documentation, and project deliverables. These standards might be industry norms, customer-specific standards, or government regulations. The project manager is ultimately responsible for selecting appropriate standards and developing additional standards that may be needed. However, project managers normally take their cues from functional managers and SMEs for many standards dealing with methods and from customers on standards dealing with documentation and deliverables.

The quality baseline reflects the agreed-upon quality objectives. It can include metrics that define exactly what will be measured, how each will be measured, and the target value of each.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-3d Process Improvement Plan Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-3d Process Improvement Plan

A process improvement plan (a subsidiary plan of the project management plan. It documents the steps for analyzing processes with the purpose of improvement. It considers process boundaries, process configuration, process metrics, and targets for improved performance.) is “a subsidiary plan of the project management plan. It documents the steps for analyzing processes with the purpose of improvement. It considers process boundaries, process configuration, process metrics, and targets for improved performance.” Process improvement was discussed earlier in the process management core concept.

Agile

On agile projects, a definition of done (completion) is explicitly stated.

This includes acceptance criteria of features, agreement of what done is for each iteration, and a demonstration to prove the deliverables work as intended.

Quality is what happens to the product in agile. It normally is not focused on other aspects or ideas. So when we think about agile projects and quality, it is worth maintaining this focus. For all other areas, it is about continual improvement.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/4

Chapter 12: Project Quality Planning and Project Kickoff: 12-4 Manage Quality Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-4 Manage Quality Manage quality (process of using the quality plan and policy to perform tasks that will most likely lead to creating project outputs to customers’ satisfaction.) is the process of using the quality plan and policy to perform tasks that will most likely lead to creating project outputs to customers’ satisfaction. A key part of managing quality is the forward-looking quality assurance. Perform quality assurance (an executing process that is primarily concerned with overall process improvements to ensure that each time a deliverable is produced it is error free.) is “an executing process that is primarily concerned with overall process improvements to ensure that each time a deliverable is produced it is error free.” Quality assurance ensures that proper methods and standards are used. It consists of a broad set of proactive management activities designed to give key stakeholders confidence that sensible methods and capable people are working on the project. This hopefully yields good project deliverables and documentation. Quality assurance is one way to simultaneously improve quality and manage stakeholder relations.

Perhaps quality assurance is best understood by considering two of its primary methods: the quality audit and process analysis. A quality audit (a key tool used in quality assurance. Quality audits enable us to review the project to evaluate which activities taking place in the project should be improved and which meets the quality standards. Quality audits have dual objectives in improving acceptance of the product, identifying areas of improvement, and improving the overall cost of quality.) is “a key tool used in quality assurance. Quality audits enable us to review the project to evaluate which activities taking place in the project should be improved and which meets the quality standards. Quality audits have dual objectives in improving acceptance of the product, identifying areas of improvement, and improving the overall cost of quality.” A quality audit is used to determine what methods are being used (hopefully the methods determined in the quality baseline) and whether they are effective. For audits to be effective, people need to be convinced that the real purpose is to improve work methods and not to punish individuals.

Quality audits sometimes show the need to request changes. These requests may include recommendations for:

Preventive actions (keeping errors out of a process, while inspection is trying to find errors after they occur to correct these errors before they reach the customer.) —“steps taken when the project is trending away from the planned scope, schedule, cost, or quality requirements. Preventive actions are proactive in nature, based on a variance and trend analysis.” Preventive actions are taken to ensure future performance is acceptable.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/4

Corrective actions (reactive approach of making a change to fix a problem that has occurred.) —“steps taken when the project has deviated from the planned scope, schedule, cost, or quality requirements. Corrective actions are reactive in nature and are intended to bring the project’s performance back into alignment with the agreed- upon project baselines.”

Defect repair (steps taken when the product or deliverable does not meet the documented quality requirements.) —“steps taken when the product or deliverable does not meet the documented quality requirements.” Not all defects can be repaired, so judgment is required to decide if the output is repairable or if it needs to be scrapped and a new output will be created.

Process analysis (a step-by-step breakdown of the phases of a process, used to determine the inputs, outputs, and operations that take place during each phase. A process analysis can be used to improve understanding of how the process operates, and to determine potential targets for process improvement through eliminating waste and increasing efficiency.) is “a step-by-step breakdown of the phases of a process, used to determine the inputs, outputs, and operations that take place during each phase. A process analysis can be used to improve understanding of how the process operates, and to determine potential targets for process improvement through eliminating waste and increasing efficiency.” It can follow an improvement model such as the DMAIC method shown in Exhibit 12.6 or the PDCA model shown in Exhibit 12.8. Process improvement is used to improve both quality and productivity. It can be of a continuous nature, in which many incremental improvements are made over time, or of a breakthrough nature, in which a substantial change is planned and implemented at once.

Processes can be measured for both efficiency and effectiveness. Efficiency is the ratio of outputs to inputs. A more efficient process uses fewer inputs to create the same number of outputs. This could equate to fewer work hours or less money spent to create the same project deliverable. Effectiveness is the extent to which a process is creating the desired deliverables. A more effective process is one that creates higher-quality deliverables and better pleases the stakeholders. Process improvement can deal with both efficiency and effectiveness and is akin to the concept of value engineering for products and services.

There are many avenues for improving project processes. One is to interpret the results of quality control measurements with an eye toward process improvement. Feedback from customers, suppliers, work associates, and other stakeholders can often lead to suggestions for improving processes. These suggestions might pinpoint opportunities to improve both the inputs into a process and the actions within the process.

Another useful method of process improvement is benchmarking. Benchmarking is a structured consideration of how another organization performs a process with an eye toward determining how to improve one’s own performance. It is not directly copying the methods. Benchmarking consists of 10 steps:

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/4

Determine a process that needs dramatic improvement.

Identify another organization that performs that process very well.

Make a deal with that organization to learn from them (they might require payment or the sharing of one of the observer’s best practices with them).

Determine what needs to be observed and what questions need to be asked.

Make a site visit to observe and question the other organization.

Decide which observed methods will help the organization.

Adapt the methods to fit the organization’s culture and situation.

Try the new methods on a small scale.

Evaluate the results.

10.

If the methods are good enough, adopt them.

Quality assurance is a continuous process in each iteration and provides incremental progress toward higher product or service quality for the customer.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 4/4

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/4

Chapter 12: Project Quality Planning and Project Kickoff: 12-5 Control Quality Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-5 Control Quality Control quality (the activities … used to verify that deliverables are of acceptable quality and that they are complete and correct. Examples of quality control activities include inspection, deliverable peer reviews, and the testing process.) is “the activities … used to verify that deliverables are of acceptable quality and that they are complete and correct. Examples of quality control activities include inspection, deliverable peer reviews, and the testing process.” This detailed set of reactive technical activities verifies whether specific project deliverables meet their quality standards. The purposes of quality control on projects are to reduce the number of defects and inefficiencies, as well as to improve the project process and outputs. Quality control consists of the following:

Monitoring the project to ensure that everything is proceeding according to plan

Identifying when things are different enough from the plan to warrant preventive or corrective actions

Repairing defects

Determining and eliminating root causes of problems

Providing specific measurements for quality assurance

Providing recommendations for corrective and preventive actions

Implementing approved changes as directed by the project’s integrated change control system.

Monitor the Project Quality

Project managers use quality control focus on project inputs, processes, and outputs. When considering inputs, a project manager wants to ensure that the assigned people can do their work. He also works with suppliers to ensure that materials, information, and other inputs meet the required specifications and perform satisfactorily. When considering the project processes, the manager wants to minimize rework because it wastes time, effort, and money, which are in short supply on most projects. Rework also often has negative impacts on both worker morale and stakeholder relations because it is very discouraging to make and/or receive an inferior product, even if it is fixed eventually. When considering outputs, a project manager may first use internal inspection to ensure the deliverables work before they are sent to the customer. External inspection may also be required to convince the customer that the deliverables are developed to meet the desired performance.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/4

While the specifics vary greatly from project to project, there are some useful general lessons regarding the timing and types of project inspections, including the following:

Conduct an inspection before a critical or expensive process to make sure the inputs are good before spending a large amount of money or time on them.

Process stages in which one worker hands off work to another worker are good times for both the workers to conduct inspections.

Milestones identified in the project charter provide good inspection points.

As practiced in software development, think of an inspection in terms of units (individual components), integration (how components work together), and the system (how the deliverable performs).

Quality Control Terms

Many terms with specific meanings are used in project quality control. Exhibit 12.14 shows pairs of terms that are sometimes confused, and the differences between each pair are described in the following paragraphs. While few projects repeat processes enough times to formally use statistical quality control, the concepts are still quite useful in making good decisions.

Exhibit 12.14

Pairs of Project Quality Control Terms

TERM: SOMETIMES CONFUSED WITH:

Prevention Inspection

Sample Population

Attribute Variable

Precision Accuracy

Tolerance Control limit

Capable In-control

Special cause Common cause

Preventive action Corrective action

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/4

Prevention versus Inspection Prevention is keeping errors out of a process, while inspection is trying to find errors after they occur to correct these errors before they reach the customer. Preventing a problem in the first place is preferred over trying to use an inspection to find it. Prevention is a cheaper alternative. Inspection does not guarantee that a problem is detected. Inspection should be practiced, but every effort should be made to prevent problems from happening in the first place.

Sample versus Population Sample and population are the factors considered for determining the scope of inspection. A population is all of the possible items in a set, such as all the students in a class. It is often costly, difficult, or even impossible to inspect an entire population. Instead, a sample or subset is inspected. Three students, picked randomly, would be a sample. The key is to use a big enough sample to be representative of the population, but a small enough sample that it is cost and time effective.

Attribute versus Variable Quality is measured either as an attribute or a variable. An attribute is determined with a yes-or-no test, while a variable is something that can be measured. Either one may be chosen. For example, if one of the goals of a project was to teach all the people in a client’s company, an attribute for each employee might be, “Did that person pass the test?” A variable might be, “How many questions did each employee score correctly?” Attributes are usually quicker (and cheaper) to observe, but may not yield as much detailed information. Project managers make a trade-off between more information and more cost when they decide if they will count or measure.

Precision versus Accuracy A process is precise when the outputs are consistently very similar, such as shooting three shots at a target that all land in a cluster near each other. A process is accurate when, on the average, it produces what the customer wants. Ideally, a process is both precise and accurate.

Tolerance versus Control Limit A tolerance limit is what the customer will accept and is sometimes called the voice of the customer. This could be if the customer wants a 1-inch bolt, perhaps they are willing to accept bolts ranging from a lower tolerance limit of 0.99 inches to an upper tolerance limit of 1.01 inches. A control limit reflects what the process can consistently deliver when things are behaving normally and is sometimes called the voice of the process. The upper and lower control limits are often statistically calculated to be three standard deviations above or below the process average.

Capable versus In Control A process is determined to be in control when the outputs are all within the control limits. A process is considered capable when control limits

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 4/4

are within the tolerance limits so that customers can remain satisfied with project performance even when the performance is outside its tolerance. Project managers try to ensure that their processes are both in control and capable of consistently delivering acceptable quality.

Special versus Common Cause Special causes are statistically unlikely events that usually mean something is different from normal. Common causes are normal or random variations that are considered part of operating the system at its current capability. Special causes are identified by individual points outside the control limits or by unusual patterns within the limits. Common causes need systematic change for improvement—perhaps new methods or better training or tools that would allow workers to more consistently produce excellent quality. Special causes, on the other hand, require specific interventions that include identifying the root causes and making changes so those same root causes do not happen again.

Preventive versus Corrective Action Preventive action is a proactive approach of making a change because a problem may occur otherwise. Corrective action is a reactive approach of making a change to fix a problem that has occurred.

Agile

Agile creates and measures quality in small batch sizes and as small

chunks of work. This is often different in larger integrated systems where the components are dependent on other components to demonstrate they are of quality.

There is not as much focus on the quality process in agile projects because agile projects tend to allow more variability for the sake of speed to market. The concept of Minimum Viable Product (MVP) has emerged in the agile community to indicate the least amount of value that could be perceived by the customer. This does not mean that MVP delivered is not of the appropriate quality.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/2

Chapter 12: Project Quality Planning and Project Kickoff: 12-6 Cost of Quality Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-6 Cost of Quality Even with good inspectors, some mistakes will reach customers if poor quality exists in project processes. Cost of quality (sum of the cost of conformance of quality and cost of nonconformance of quality.) is a sum of the cost of conformance of quality and cost of nonconformance of quality. Quality decisions should be based on costs associated with all the factors listed in Exhibit 12.15.

Exhibit 12.15

Costs of Quality

COST OF CONFORMANCE COST OF NONCONFORMANCE

Planning

Training

Process control and validation

Product design validation

Test and evaluation

Quality audits

Maintenance and calibration

Inspection

Field testing

Scrap

Rework and repair

Additional material

Inventory

Warranty repairs and service

Compliant handling

Liability judgments

Product recalls

Field service

Expediting

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/2

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-7 Develop Project Management Plan Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-7 Develop Project Management Plan Chapters 5, 6, 7, 8, 9, 10, and 11 have all dealt with aspects of project planning. On small and simple projects, the various portions of this planning may already be combined to a large extent. On larger, more complex projects, specific methods are often used to plan the various project aspects separately, such as cost, schedule, resources, communications, risk, and quality. If they have not been planned together, they need to be compiled into a unified project management plan. Conflicts need to be resolved. A configuration management system needs to be selected or developed. The project manager should apply a sanity test to all project plans. There is often a formal project kickoff of some sort, and after everything is agreed, the scope, schedule, budget, and so forth are baselined, and the baseline becomes part of the project management plan.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-7a Resolve Conflicts Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-7a Resolve Conflicts

Sometimes, when all parts of the plan come together, it becomes obvious that the overall plan is impractical. If this occurs, the key stakeholders may need to determine their priorities and trade-offs.

What do they really most want and need from the project?

Are all of the quality standards truly mandatory, or can one of them be relaxed a bit?

Is the imposed deadline really critical, or, considering the impact it poses for costs and risks, can it be relaxed a bit?

Is the budget a true maximum, or can it be adjusted to secure the desired features?

These questions and others like them have probably been asked all along, but now they take on added urgency because once the project plan is approved, it may be more difficult to make these changes.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-7b Establish Configuration Management Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-7b Establish Configuration Management

Project planning can be hard work. Once the plan is in place, it still takes a lot of hard work to control the project. One last part of planning is to create a configuration management system to aid project control. A configuration management system (Process for identifying and uniquely naming items that need to be controlled, activity of managing the project deliverables and documentation, recording and reporting all changes, and verifying the correctness of all deliverables and components of them.) has four parts:

1. Process for identifying and uniquely naming items that need to be controlled

2. Activity of managing the project deliverables and documentation

3. Recording and reporting all changes

4. Verifying the correctness of all deliverables and components of them

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/2

Chapter 12: Project Quality Planning and Project Kickoff: 12-7c Apply Sanity Tests to All Project Plans Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-7c Apply Sanity Tests to All Project Plans

A common saying is appropriate to consider here: “can’t see the forest for the trees.” This means that sometimes a person is so concerned with details that they forget the big picture. During the initial stage of a project (initiating), the team creates the primary deliverable, a project charter. The charter is a high-level view of a project, so seeing the big picture is easy. During the more detailed planning stage, however, the team looks in great detail at scope, schedule, resources, cost, communications, risks, and quality. Now they need to step back a bit and ask if all these elements work well together. The project manager and core team should apply a sanity test to their project plans by asking one another questions to ensure that the comprehensive project plan makes sense. Some of these questions could be as follows:

Does the critical path look reasonable?

Do the milestones look achievable?

Are some resources overallocated?

Does everyone understand what they are supposed to do?

Do we really understand our customers?

Are the customers’ desires likely to change?

How well do we understand the standards we will be judged against?

Are the methods for completing our work really sensible?

Are we confident we can gather and analyze the data we need to control the plan?

Agile

On agile projects, the overall plan for the project (called the release plan)

is only at a high level, while the detailed plans for each iteration are baselined right before each iteration starts. The idea is to allow as much flexibility as possible, up until the last responsible minute to respond as quickly as possible to the changing needs of the customer.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/2

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/2

Chapter 12: Project Quality Planning and Project Kickoff: 12-8 Kickoff Project Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-8 Kickoff Project Project kickoff meetings are conducted for many reasons. First, everyone should express their legitimate needs and desires and should strive to understand the desires of all the other stakeholders. If the leader, charged with accomplishing the project, does not have the full authority to direct all the project work activities, she needs to use her influence to get everyone excited about the project, to feel pride in their participation, to feel they share in the risks and rewards the project offers, and to be motivated to self-manage as much as possible. Many people may have helped with some parts of the project planning. This is their chance to see how all the parts fit together. Since many projects fail because of “touchpoints” where one person hands off work to another, it is critical for all parties to understand these potential trouble spots. Kickoff meetings are also helpful in convincing all the project stakeholders that the project leaders (sponsor, project manager, and core team) will be good stewards of the customer’s and the parent organization’s assets. Answering any remaining questions and overcoming lingering concerns helps to accomplish this. Finally, all interested parties (outside customers, top management, functional managers, frontline workers, and any others) should be eager to commit to the project and get on with the work!

Monkey Business Images/ Shutterstock.com

http://shutterstock.com/

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/2

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-8a Preconditions to Meeting Success Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-8a Preconditions to Meeting Success

Several preconditions must be met for project kickoff meetings to be successful:

The sponsor and project manager need to set clear direction during the planning.

The core team needs to commit to the project first—it is hard for them to convince others if they do not believe in it themselves.

Everyone should contribute to setting up an atmosphere of trust and relationship building.

Project leaders need to practice active listening to uncover potential problems.

As many people as possible should be included in parts of the planning to enhance chances that they will buy in to the resulting project plan.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/3

Chapter 12: Project Quality Planning and Project Kickoff: 12-8b Meeting Activities Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-8b Meeting Activities

The formality of a kickoff meeting can vary considerably depending on the size and type of project. Typical activities that might be included in the kickoff meeting are the following:

The sponsor and project manager describing the importance of the project

The customer(s) describing their acceptance standards, sense of urgency, and budget concerns

The project manager outlining the project goals

The project manager and the core team describing work expectations

The project manager unfolding the project plan and its current status (if work has commenced)

The core team explaining the communications, risk, and quality plans

Everyone asking questions and making suggestions

The project manager authorizing appropriate changes to the project plan

Everyone concurring with the overall plan and to his or her individual action items

On small, simple projects, presenting the charter and signing can take the place of a kickoff meeting. However, on many projects, the team needs to perform much more detailed planning after the charter is signed. Project kickoff meetings are vital for communications and commitment on these projects. Exhibit 12.16 is an example of how the information systems and technology division of a major healthcare company kicks off a project.

Exhibit 12.16

IS&T Project Launch Assessment Agenda

Purpose: The Project Manager is to illustrate to an executive audience the chartered IS&T project’s readiness to successfully launch. Upon conclusion of the Project Manager’s presentation, the executive audience will determine and document the actions required for the project to launch.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/3

Prerequisite: The Project Manager is required to complete the Project Deliverable Review and receive documented approval from the Project Deliverable Review Board in order to proceed to the Project Launch Assessment.

Standard Participants

Core Group (CG) (CIO and IS&T Director) PMO Manager

Project Manager

Functional Manager PMO Consult

Quality Consult

Security Consult (Optional)

Test Coordinator

Sponsor

Required Documents: The Project Manager is required to present the PLA materials online. If a paper copy is needed, it should be printed double-sided.

Project Charter PMO Risk Forms

Project Financial Worksheet

Master Test Plan

Progress Report—PDR

Project Launch Assessment Agenda: The Project Manager is required to present all of the listed deliverables in the provided order, focusing on specifically the identified components and content specified.

1. Project Charter—Discuss Business Need, Purpose, Logical Scope: In-Scope, Out-of-Scope, and Assumptions.

2. Master Test Plan—Discuss Sections 1.3—Test Levels, Objectives, and Deliverables; 3—Test Timeline and Key Events; and 5—Define System Characteristics, Relative Importance, and Subsystems.

3. Privacy and Security—Discuss the Security and HIPAA Template for PMO Projects.

4. Risk Forms—Discuss all populated and scored forms created to date.

5. Project Financial Worksheet—Discuss populated spreadsheet.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/3

6. Progress Report (PDR)—Speak to the current status of all actions provided for each deliverable.

Source: Nancy D’Quila, PMP.

Agile

In scaled agile models, there is a large meeting every planning cycle that

behaves much like a kickoff meeting.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-9 Baseline and Communicate Project Management Plan Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-9 Baseline and Communicate Project Management Plan Once the project plan is complete and accepted by the stakeholders, the plan is baselined. A baseline is the approved plan. Many project plans are developed iteratively as more information comes to light. A project plan is considered to be in draft form until enough information is available for the key stakeholders to commit to all of the details and baseline the plan. At that point, it becomes official, and any changes in the future need to be formally approved and documented.

This is a time of great joy because this marks the transition between planning and executing the project. In reality, on many projects, some activities that are on the critical path or nearly critical paths are started before the official project kickoff. Planning also continues in the form of replanning to adjust to changing circumstances. However, the majority of planning is done, and the majority of executing is just starting.

The project management plan needs to be communicated in accordance with the communications plan requirements. Hopefully, many of the key stakeholders are able to attend the kickoff meeting. Regardless of who is present, proper communication needs to be sent to all stakeholders.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-10 Using MS Project for Project Baselines Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-10 Using MS Project for Project Baselines MS Project can be used as a tool to automate and communicate many facets of a project. A key job of the project manager is monitoring and controlling the project. MS Project can assist the project manager in this effort by creating a project baseline to measure against as the project is executed. Before a baseline is created with MS Project, the project manager needs to verify that the following items have been incorporated in the planning (you’ll probably note some of these are glaringly omitted in our running Suburban Park Homes tutorial):

Quality assurance and quality control activities are included.

Risk response plan activities (or duration compensation) are included.

Performance posting activities are included.

All “hard” date constraints are incorporated.

A realistic start date has been chosen.

Organizational holidays and resource vacations are entered.

Resource allocations are realistic and overloads are addressed.

Management and contingency reserves are in the schedule.

Time and cost trade-offs are applied to the schedule.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-10a Baseline the Project Plan Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-10a Baseline the Project Plan

Once the project plan has been completed as above and agreed on by the key stakeholders, it is important to “lock in” the plan, or baseline it. Baselining is important so the project manager can track and measure how well actual project performance matches the original plan (the baseline). Tracking and measuring these variances is one way the project manager monitors and controls the project.

Up to this point, the project manager has inputted start, finish, and duration data into MS Project, along with resources, their costs, and assignments. These values, together with project quality and scope targets, are what the stakeholders agreed to, approved, and expect as key measures of project success. Collectively, these values and targets, along with the risk and communications plans, form the project management plan.

However, once work begins on the project (execution), the actual value of the inputs will begin to vary from the planned value for most if not all of these inputs (unless the project is executed exactly to plan, which is unlikely). When the baseline is created, MS Project makes a project plan snapshot of all planned input values (i.e., duration, start, stop, resources). With this snapshot, MS Project begins to track the variance between baseline and actual values as the project is executed. The project manager can use MS Project to compare the baseline with actual schedule, work, and cost variance values and display these graphically and in tables. This comparison can be used to know where the project is doing well, and where it may need help. Baseline variance can also help predict future impacts to time and cost targets. With these bits of information, project managers can take action to get the project back on track where needed, and reduce or eliminate undesirable future impacts to the project.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-10b Create the First Time Baseline Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-10b Create the First Time Baseline

Once key stakeholders agree to the project plan, the baseline is created by:

1. Click the Project Tab>>Schedule Group>>click Set Baseline>>click Set Baseline…

2. The defaults should be accepted as shown in Exhibit 12.17, click OK

Exhibit 12.17

Set First Time Baseline

Source: Microsoft product screenshots reprinted with permission from Microsoft Corporation.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/2

Chapter 12: Project Quality Planning and Project Kickoff: 12-10c Subsequent Baselines Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-10c Subsequent Baselines

For any number of reasons, it may not be useful to continue to manage to the present baseline. Reasons to change the baseline might include changes to the project scope, project delay, or unavailability of planned resources (among a host of other reasons). If a change is approved, the changed tasks must be re-baselined, as well as the WBS parents of the new or changed tasks (Step 3 below):

Select the changed or added activities, milestones, and WBS elements

Click the Project Tab>>Schedule Group>>click Set Baseline>>click Set Baseline…

Ensure the original baseline is selected in the drop-down menu under “Set baseline”

Click Selected tasks>>check To all summary tasks

Click OK

Instead of re-baselining as above, you may wish to create an entirely new baseline. MS Project supports up to 11 baselines. Some project managers like to save a baseline for each iteration of planning to compare different values, while others like creating a new baseline as each phase or milestone of a project is reached. Steps for creating additional baselines match those of creating the original baseline, only the drop-down menu under “Set baseline” needs to be changed to Baseline 1 (or Baseline 2, 3, 4, etc., whichever number of baseline the project happens to be on).

Chapter 12: Project Quality Planning and Project Kickoff: 12-10c Subsequent Baselines Book Title: Contemporary Project Management

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/2

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/3

Chapter 12: Project Quality Planning and Project Kickoff: 12-10d Viewing Baselines and Variances Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-10d Viewing Baselines and Variances

The Gantt Chart view can be formatted to show “baseline bars,” which provide a graphical view of differences between the planned and actual schedule of each task. To display baseline bars in the Gantt view:

1. Click the View Tab>>Task Views>>Gantt Chart

2. Click the Format Tab>>Bar Styles Group>>Baseline>>click the Baseline you want to view

A good way to view the difference between a task’s baseline value versus its actual value is side by side. This is easily accomplished in MS Project using the Variance table:

1. Click the View Tab>>Task Views>>click Other Views>>Task Sheet

2. In the Data Group>>Tables>>Variance

The variance table appears and shows you several columns as in Exhibit 12.18. Once the project has entered the execution phase, many of your start and finish dates will likely be different from what was originally planned (baselined). The variance table shows you the Start and Finish dates (the actual dates you executed on) and the baselined Start and Finish dates (the dates you planned to execute on). It also shows you the Start and Finish variance (the difference between the planned and the actual date).

Exhibit 12.18

Project Task Variances

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/3

As you can see in Exhibit 12.18, a date change in the project has been made to the task “Architect sign-off.” The original plan was for this task to start on Monday 12/4/17 (the Baseline Start). However, the actual start was on Wednesday 12/6/17 as seen in the Start column. This change shows up in the Start and Finish Variance columns as a two-day variance. If you go back to the Gantt view (View Tab>>Task Views>>Gantt Chart), you will notice that the baseline bars have been revealed more prominently as the task bars have shifted to the right.

As other project tasks shift, variances will ripple down through the project and give the project manager an idea of how the schedule will shift on the project. This is just another tool the project manager can use to examine critical path activities and plan to crash or make other adjustments to the schedule as necessary.

Agile

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 3/3

Agile embraces the idea of building quality into the product at the smallest batch size.

There is not a separate step for quality.

The saying that helps us remember this is: aim small miss small.

There is little planning for quality, other than the team owns quality, and the Condition of Acceptance for each story is the definition acceptable to the customer.

Architectural runway is an aspect of quality in more agile environments and this speaks to how the infrastructure where the software will run needs to prepared. When this is done as a critical path activity, the product quality is higher.

While agile has been predominately used in software and product development environments, much of what agile does with regard to quality could work in other areas as well.

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/1

Chapter 12: Project Quality Planning and Project Kickoff: 12-11 PMP/CAPM Study Ideas Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

12-11 PMP/CAPM Study Ideas You are likely to see a few elements from this chapter on either a CAPM or PMP test. One of the paramount things to remember is the difference between quality assurance (forward- looking/preventative) and quality control (inspection) and how a quality policy or plan can integrate the two.

Understand how to follow an improvement model such as PDCA or DMAIC and know the difference between common causes and special causes of variation. Be familiar with the contributions of some of the thought leaders in the field of quality—especially Deming and Juran. Finally, know what Six Sigma means and why it is relevant and be prepared to use its standard deviation formula to determine whether a process is in control or out of control. We will delve into more specific quality tools in Chapter 14.

javascript://

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 1/2

Chapter 12: Project Quality Planning and Project Kickoff Chapter Review Book Title: Contemporary Project Management Printed By: Washburn Kelly ([email protected]) © 2019 Cengage Learning, Cengage Learning

Chapter Review

Summary

Deming, Juran, and many other people have contributed to the modern approaches to quality. The Malcolm Baldrige Award, ISO certification, and Six Sigma each present a framework with many good points. The contemporary approach to project quality draws upon all of these sources.

The first concept in contemporary project quality management is stakeholder satisfaction. It is critical to understand project stakeholders, prioritize their needs, manage toward those needs, keep the relationships strong, and always strive to ensure that the customer is capable of using the project deliverables. The second concept is process management. This includes understanding both continual and breakthrough forms of improvement, seeking the root cause of problems, and using an appropriate model such as DMAIC to guide improvement efforts. The third concept is fact-based management. This entails understanding variation, making good decisions regarding what to measure, capturing and analyzing data correctly, and using the information in an open and honest decision-making manner. The final concept is empowered performance. Project managers want to have capable and willing workers throughout their project and should treat each person as an individual, ensure people accept responsibility, and strive to get more done through collaboration.

When project managers perform quality management planning, the first thing they need to do is either adopt the quality policy of their parent organization or supplement it. The policy should broadly guide their efforts. The quality plan should include the quality baseline defining performance expectations. It should also include instructions for how the quality assurance and quality control will be handled.

Many quality tools have been developed over the years, and quite a few of them work well on projects. Many of these tools can be used in additional project management activities.

Once the quality management plan and all of the other subsidiary plans have been developed, it is time to iron out any inconsistencies among the various plans. The overall project management plan needs to make sense. Quality, cost, schedule, human resources, risk, and communications may have been planned somewhat independently on a large project, and now is the time to make sure they all work well together.

The project core team usually asks themselves a number of questions concerning the practicality of the overall plan and then holds a kickoff meeting with all of the project stakeholders. Hopefully, the outcome of the meeting is commitment and excitement all

8/13/2020 Print Preview

https://ng.cengage.com/static/nb/ui/evo/index.html?deploymentId=5799612321531776791938283915&eISBN=9781337616324&id=889376802&nbId=… 2/2

around. Now, the project officially moves into execution. While some of the project activities may already be under way (or even complete), the approval of the project plan signals the change from primarily planning to primarily execution. Ongoing planning and replanning still occur, but managing the performance of project activities and communicating with various stakeholders consume much of the project manager’s time from this point forward.

11-0 Project Risk Planning
11-0a Chapter Introduction
11-1 Plan Risk Management
11-1a Roles and Responsibilities
11-1b Categories and Definitions
11-2 Identify Risks
11-2a Information Gathering
11-2b Reviews
11-2c Understanding Relationships
11-2d Risk Register
11-3 Risk Analysis
11-3a Perform Qualitative Risk Analysis
11-3b Perform Quantitative Risk Analysis
11-3c Risk Register Updates
11-4 Plan Risk Responses
11-4a Strategies for Responding to Risks
11-4b Risk Register Updates
11-5 PMP and CAPM Study Ideas
11-6 Summary
12-0 Project Quality Planning and Project Kickoff
12-0a Chapter Introduction
12-1 Development of Contemporary Quality Concepts
12-1a Quality Gurus
12-1b Total Quality Management and Malcolm Baldrige
12-1c ISO 9001 - 2008
12-1d Lean Six Sigma
12-2 Core Project Quality Concepts
12-2a Stakeholder Satisfaction
12-2b Process Management
12-2c Fact-Based Management
12-2d Fact-Based Project Management Example
12-2e Empowered Performance
12-2f Summary of Core Concepts
12-3 Plan Quality Management
12-3a Quality Policy
12-3b Quality Management Plan Contents
12-3c Quality Baseline
12-3d Process Improvement Plan
12-4 Manage Quality
12-5 Control Quality
12-6 Cost of Quality
12-7 Develop Project Management Plan
12-7a Resolve Conflicts
12-7b Establish Configuration Management
12-7c Apply Sanity Tests to All Project Plans
12-8 Kickoff Project
12-8a Preconditions to Meeting Success
12-8b Meeting Activities
12-9 Baseline and Communicate Project Management Plan
12-10 Using MS Project for Project Baselines
12-10a Baseline the Project Plan
12-10b Create the First Time Baseline
12-10c Subsequent Baselines
12-10d Viewing Baselines and Variances
12-11 PMP and CAPM Study Ideas
12-11a Summary