Page 150 -

8 - PROJECT QUALITY MANAGEMENT

Peter Drucker: “Quality of a software product or service is not what the developers put in. It is what the customer
gets out and is willing to pay for” [24]. For example, software used to determine the whereabouts of one’s friends
may not need the same qualities of timeliness, accuracy, and precision as software used to guide interplanetary
trajectories. Quality concerns receive increased emphasis for software that has an impact on the health, safety, and
welfare of the general public, and for protection of software and data related to personal or business proprietary
information.

Quality requirements may be unstated initially or they may be vague and ambiguous. As discussed in Section 5
of this Software Extension, software engineers and IT business analysts elicit needs from customers, the software
users, and other stakeholders. IEEE Standard 830 [19] provides an extensive list of the types of requirements that 8
should be considered but are sometimes overlooked. Whether known initially or whether they emerge during a
software project, the software product should provide an acceptable level of quality for users and other stakeholders.

Quality attributes of software include, but are not limited to safety, security, reliability, availability, performance,
ease of use, and ease of modification. Section 1.9 of this Software Extension lists quality attributes that are important
for software users (e.g., efficiency, safety, security, reliability, availability) and quality attributes that are important to
software developers and maintainers (e.g., maintainability is important to those who provide sustainment services).
The ISO/IEC 25000 series of standards [25] provides extensive lists of software quality attributes that are aligned
with different stakeholder needs.

For reasons of objectivity in evaluating quality, the PMBOK Guide recommends independent quality audits.
®
Independence of SQA and SQC can be obtained by establishing a different line of reporting for external SQA and
SQC. Internal SQA is accomplished by individual introspection and by retrospective meetings of team members.
For internal SQC, software team members other than the ones who produced a software component perform peer
reviews and tests.

Mature organizations and teams foster collaboration between external SQA-SQC and the software development
team to avoid the adversarial relationship that sometimes occurs. For small projects and organizations, SQA
and SQC personnel may be members of the software development team, provided a degree of independence is
maintained (i.e., someone is designated to be responsible for SQA and no one performs final tests of their own code).
While larger organizations may mandate an organizational separation of external SQA and SQC personnel from
development activities (i.e., to permit SQA and SQC personnel to audit, investigate, and recommend changes based
on issues that arise or newly identified opportunities), collaborative exploration of quality issues is easily achieved
within cross-functional product teams. On the other hand, when external SQA and SQC personnel are assigned
from independent functional groups, and are not included in cross-functional teams, collaborative exploration of
quality issues may be lost and SQA and SQC personnel may become adversaries to software developers.

The user role in determining whether software has acceptable quality may be played by different persons,
depending on the project’s context. In a commercial software product company, the user may be represented
by the product manager or documented in one or more fictional persona that provides the knowledge, needs,
and tasks of a typical user. In an IT enterprise project, the user may be an authorized subject matter expert in
the business processes the software will serve. For a software project conducted under contract, the accepting
authority of the acquiring organization may represent the user. It is important for software project managers to

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