Page 154 -

8 - PROJECT QUALITY MANAGEMENT

manager is responsible for ensuring that all stakeholders understand failure to meet users’ quality expectations will
result in project and product failure. In addition to the end users and their managers, other stakeholders are those
who will affect or be affected by the software product, either while it is under development or during operation
after it is delivered. For example, the stakeholders of an enterprise resource planning (ERP) system include IT
operations staff who are responsible for sustaining the ERP system; their concerns will include the interoperability,
performance, robustness, and documentation of the software. In addition to users and those responsible for
product sustainment, members of the project team and external SQA and SQC are also product stakeholders (see
Section 13 of this Software Extension for stakeholder management considerations). A stakeholder register provides
an input for planning software quality management.
8
Quality requirements are an element of the overall product requirements; they are (or should be) established
when the functional requirements are established. In companies that produce software products for commercial
sale, the quality requirements are usually included in the market requirements document. IT projects may simply
use a features/backlog list. When applicable, the project manager needs to make sure that the quality requirements
are included. Quality requirements for contracted software (i.e., bespoke software) are typically included as an
element of the statement of work.

Customers and users may not be able to precisely state performance requirements and other nonfunctional quality
requirements. A software project manager may need to engage product managers, business analysts, requirements
engineers, and other appropriate stakeholders in the elicitation of nonfunctional requirements to determine which
quality attributes are most important to the customer and users. Requirements for software product quality may also
include regulatory requirements (e.g., for life-critical systems). In contracting, quality requirements may be imposed
on component providers and suppliers of custom-built or customized software components.

Inputs for planning the management of software process quality typically include quality analyses from past projects or
from previous increments of the current product. Inputs for planning software quality management can be associated with
quality analyses performed at the story, feature, iteration, or release level (e.g., to provide a basis for determining whether
code reviews, testing, and other types of evaluations were executed as anticipated and whether they were successful);
defect find/fix rates can be examined (to determine whether the numbers are rising or falling); time spent on fixing
defects can be examined (to determine whether they are adversely impacting planned feature development and whether
reviews and testing are yielding the expected results); and previous lists of known problems and deferred defects can be
investigated by severity and by feature or module (to determine whether there are error-prone modules in the software).

The following inputs from Section 8.1.1 of the PMBOK Guide are also applicable inputs for planning software
®
project quality management.

8.1.1.1 Project Management Plan

See Section 8.1.1.1 of the PMBOK Guide.
®

8.1.1.2 Stakeholder Register

See Section 8.1.1.2 of the PMBOK Guide.
®

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