Page 155 -

8 - PROJECT QUALITY MANAGEMENT

8.1.1.3 Risk Register

See Section 8.1.1.3 of the PMBOK Guide.
®

8.1.1.4 Requirements Documentation

See Section 8.1.1.4 of the PMBOK Guide.
®

8.1.1.5 Enterprise Environmental Factors

See Section 8.1.1.5 of the PMBOK Guide.
®

8.1.1.6 Organizational Process Assets

See Section 8.1.1.6 of the PMBOK Guide.
®

8.1.2 Plan Quality Management: Tools and Techniques

®
The tools and techniques for planning quality management in Section 8.1.2 of the PMBOK Guide are applicable
for software projects. In addition to the tools and techniques listed below, the following considerations also apply
to tools and techniques for planning software project quality management.

Planning for software quality management includes confirming user needs and quality requirements, performing
cost-benefit and cost-of-quality analyses, developing a testing strategy, and selecting a defect management and
quality control approach. Some comments follow:
• Planning for software quality. The customer and users may not have experience in defining their
quality expectations as testable requirements; therefore, the project team needs to be adept in eliciting
the needed information. This often requires ongoing validation from the users that the software will meet
their needs, using techniques such as prototypes, mock-ups, and other simulations.
• Cost-benefit analysis (CBA). For most software projects, there are trade-offs among the various levels
of product quality, the amount of functionality delivered, and the time and effort required to deliver a
quality product. An example of CBA is comparing the cost of testing and rework for different levels of
defect removal. Determining an acceptable level of released defects may involve comparative benchmark
evaluation of the relevant quality attributes in the major competitors’ products. While it is natural for the
project team to want to correct all problems detected, a software project manager typically does not
plan for a significantly higher amount of defect correction than is warranted by user expectations. For
example, depending on the context of the user and user environment, there may be no need to correct a
defect that would be difficult to correct and that will rarely be encountered and for which there is a user
work-around.

146 ©2013 Project Management Institute. Software Extension to the PMBOK Guide Fifth Edition
®