Page 211 -

11 - PROJECT RISK MANAGEMENT

11.4 Perform Quantitative Risk Analysis

The inputs, tools and techniques, and outputs for performing quantitative risk analysis in Section 11.4 of the
®
PMBOK Guide are applicable to performing quantitative risk analysis for software projects.
Quantitative techniques are often used on major software projects, such as competitive software acquisitions or
enterprise initiatives. The time and expertise required for extensive quantitative risk analysis may not be justified
for simpler projects.

Quantitative analysis may be used to prioritize (a) unmitigated risks in the product backlog, and (b) risk avoidance
and risk mitigation activities. A software project technical risk has a cost impact, and a risk mitigation or risk transfer
option has a quantifiable cost, such as the cost of procuring software in comparison to the labor cost of building
the software—these can be translated into monetary units. Similarly, human resource and business risks can be
estimated in monetary terms. Of course, not all risks have avoidance or mitigation steps that can be scheduled into
a software project. Some risks may have to be accepted (e.g., the project is delayed while waiting for a procured
component), but those risks that can be proactively addressed can be prioritized in the adaptive project’s backlog.

Quantitative risk analysis has several practical limitations. It is not possible to estimate the probability and 11
impact of all potential problems (risks). For example, consider the risk of developing software that makes it easy
for hackers to access private user data. There is no cost until after the project is ended when the software is being
used in the operational environment. At that time, a security breach could result in fines, legal fees, and remediation
costs to the users for credit monitoring, litigation costs, and loss of future business. The expenses are potentially
large and serious, but not easily quantified at the time of risk analysis during software development.

For software projects, risk identification and risk analysis attempt to focus on the most probable and highest-
impact risks rather than the cumulative impact of a succession of minor risks. Also, the impact of some risks may
be hard to quantify as far as direct costs to the project or organization. The precision of the monetary value may not
be great, but the point of quantitative risk analysis for software projects is usually to take action based on relative
scorings rather than precise numbers. The goal is to reach consensus with the software project stakeholders on
justifiable numbers to use as a basis for prioritization, not to report costs on a balance sheet.
The objectivity and relevance of a quantitative risk analysis ultimately depends on qualitative judgment, the
availability of an experience base, and the objectivity of the experts estimating the best, most likely and worst-
case points.

11.4.1 Perform Quantitative Risk Analysis: Inputs

The inputs in Section 11.4.1 of the PMBOK Guide for performing quantitative risk analysis are applicable to
®
performing quantitative risk analysis for software projects.

11.4.1.1 Risk Management Plan

See Section 11.4.1.1 of the PMBOK Guide.
®

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