Page 218 -
P. 218

11 - PROJECT RISK MANAGEMENT






                   11.6 Control Risks


                                                                                                         ®
                      The inputs, tools and techniques, and outputs for controlling risks in Section 11.6 of the PMBOK  Guide are
                   applicable to controlling risks for software projects with the following additions and extensions.

                      Risk monitoring and control for software projects includes tracking identified risks, monitoring residual risks,
                   executing risk treatment plans, and evaluating their effectiveness. On small software projects, monitoring and
                   controlling risks are part of the project manager’s duties. On large programs, another individual, often a quality
                   assurance or planning specialist, is designated as the risk manager and is delegated the responsibility for recording
                   new risks in the risk register and, in consultation with the project manager, ensures that risk mitigations are being
                   implemented and completed by agreed-upon completion dates.



                   11.6.1 Control Risks: Inputs


                      The software project manager (or risk manager) typically schedules regular reviews of the impacts and
                   probabilities of identified risks until those risks are closed out. Risk managers also capture experience data and
                   lessons learned for use in future phases and other projects.

                      Organizations vary in their tolerance of risk. The risk threshold is the point at which the probability of a risk
                   becomes large enough that it can no longer be accepted and needs further treatment. To determine when the risk
                   threshold is reached, software projects use indicators such as technical performance measures (TPM) or more
                   selectively, key performance indicators (KPI), which show how successfully a risk is being managed. For example,
                   when the churn in requirements exceeds a defined percentage, or the number of defects per thousand lines of
                   code (KLOC) discovered during testing passes a defined level, or the cost or schedule performance index (CPI or
                   SPI) exceeds a prespecified limit, a risk threshold has been reached. This condition is called a risk trigger for the
                   risk manager to initiate a contingency plan for risk treatment.

                      The inputs for controlling risks in Section 11.6.1 of the PMBOK  Guide are applicable to controlling risks for
                                                                            ®
                   software projects, with the following addition to 11.6.1.4.


                   11.6.1.1 Project Management Plan


                      See Section 11.6.1.1 of the PMBOK  Guide.
                                                    ®

                   11.6.1.2 Risk Register

                      See Section 11.6.1.2 of the PMBOK  Guide.
                                                    ®

                   11.6.1.3 Work Performance Data

                      See Section 11.6.1.3 of the PMBOK  Guide.
                                                    ®





          210      ©2013 Project Management Institute. Software Extension to the PMBOK  Guide Fifth Edition
                                                                   ®
   213   214   215   216   217   218   219   220   221   222   223