Understanding Risk Management

Document Sample
Understanding Risk Management Powered By Docstoc
					              Risk Management

                                           Understanding Risk Management
                                                                                                                           Software Technology Support Center

                The U.S. Air Force’s Software Technology Support Center offers an updated and condensed version of the “Guidelines for
                Successful Acquisition and Management of Software-Intensive Systems” (GSAM) on its Web site <www.stsc.hill.af.mil/
                resources/tech_docs>. This article is taken from Chapter 5 “Risk Management” of the GSAM (Version 4.0). We are
                pleased that all editions have been so well received and that many individuals and programs have worked hard to implement
                the principles contained therein. The latest edition provides a usable desk reference that gives a brief but effective overview of
                important software acquisition and development topics, provides checklists for rapid self-inspection, and provides pointers to
                additional information on the topics covered.

R    isk is a product of the uncertainty of
     future events and is a part of all
activity. It is a fact of life. We tend to stay
                                                              ty of the event actually occurring by the
                                                              potential negative impact to the cost,
                                                              schedule, or performance of the project:
                                                                                                              digms, certain characteristics are univer-
                                                                                                              sally required for the program to be suc-
                                                                                                              cessful [2]:
away from situations that involve high                                                                        • The risk management process is
risk to things we hold dear. When we can-                        Risk Severity = Probability of                    planned and structured.
not avoid risk, we look for ways to reduce                      Occurrence x Potential Negative               • The risk process is integrated with the
it or its impact upon our lives. Yet even                                   Impact                                 acquisition process.
with careful planning and preparation,                                                                        • Developers, users, procurers, and all
risks cannot be completely eliminated                         Thus, risks where probability of occur-              other stakeholders work together
because they cannot all be identified                         rence is high and potential impact is very           closely to implement the risk process.
beforehand. Even so, risk is essential to                     low, or vice versa, are not considered as       • Risk management is an ongoing
progress.                                                     serious as risks where both probability of           process with continual monitoring
    The opportunity to succeed also car-                      occurrence and potential impact are                  and reassessment.
ries the opportunity to fail. It is necessary                 medium to high.                                 • A set of success criteria is defined for
to learn to balance the possible negative                         Project managers recognize and                   all cost, schedule, and performance
consequences of risk with the potential                       accept the fact that risk is inherent in any         elements of the project.
benefits of its associated opportunity [1].                   project. They also recognize that there         • Metrics are defined and used to mon-
Risk may be defined as the possibility to                     are two ways of dealing with risk. One,              itor effectiveness of risk management
suffer damage or loss. The possibility is                     risk management, is proactive and care-              strategies.
characterized by three factors [1]:                           fully analyzes future project events and        • An effective test and evaluation pro-
1. The probability or likelihood that loss                    past projects to identify potential risks.           gram is planned and followed.
    or damage will occur.                                     Once risks are identified, they are dealt       • All aspects of the risk management
2. The expected time of occurrence.                           with by taking measures to reduce their              program are formally documented.
3. The magnitude of the negative                              probability or to reduce their impact. The      • Communication and feedback are an
    impact that can result from its occur-                    alternative to risk management is crisis             integral part of all risk management
    rence.                                                    management. It is a reactive and                     activities.
    The seriousness of a risk can be                          resource-intensive process, with available           While your risk management
determined by multiplying the probabili-                      options constrained or restricted by            approach should be tailored to your pro-
                                                              events [1].                                     ject needs, it should incorporate these
Figure 1: Software Engineering Institute’s Risk                   Effective risk management requires          fundamental characteristics. The process
Management Paradigm [3]                                       establishing and following a rigorous           is iterative and should have all the com-
                                                              process. It involves the entire project         ponents shown in Figure 2. Note that
                                                              team, as well as requiring help from out-       while planning appears as the first step,
                                                              side experts in critical risk areas (e.g.,      there is a feedback loop from the moni-
                        ol                                    technology, manufacturing, logistics,           toring activity that allows planning and
                  ntr                 Id
             Co                            en
                                                tif           etc.). Because risks will be found in all       the other activities to be redone or con-
                                                   y          areas of the project and will often be          trolled by actual results, providing contin-
                                                              interrelated, risk management should            ual updates to the risk management strat-
                                                              include hardware, software, integration         egy. In essence, the process is a standard
                                                              issues, and the human element [2].              approach to problem solving:
                                                                                                              1. Plan or define the problem-solving

                                                              Process Description                                  process.

                                                              Various paradigms are used by different         2. Define the problem.
                                                              organizations to coordinate their risk          3. Work out solutions for those prob-

                                                              management activities. A commonly used               lems.
                        Plan                                  approach is shown in Figure 1. While
                                                                                           [3]                4. Track the progress and success of the
                                                              there are variations in the different para-          solutions.

4 CROSSTALK The Journal of     Defense Software Engineering                                                                                          February 2005
             Planning                      Assessment               Handling         Monitoring
                                                                          Identification Analysis

                                                                                                                                  Understanding Risk Management

The following sections expand upon the                                             Risk Documentation
risk management approach.                           Planning                        Assessment                            Handling                   Monitoring

                                                                              Identification Analysis

Risk planning includes developing and

documenting a structured, proactive, and
comprehensive strategy to deal with risk.
Key to this activity is establishing meth-                                             Risk Documentation
ods and procedures to do the following:
1. Establish an organization to take part       Figure 2: Risk Management Process Example
   in the risk management process.
2. Identify and analyze risks.                   Condition                         End users submit requirements changes even though we are in the design
3. Develop risk-handling plans.                  Consequence
                                                                                   phase and the requirements have been baselined.
                                                                                   Changes could extend system design cycle and reduce available coding time.
4. Monitor or track risk areas.                  Probability and Impact            80%. $2 million.
5. Assign resources to deal with risks.          Mitigation Actions                Who, what, and when?
   A generic sample risk management
plan can be found in Appendix B of the          Table 1: Risk Statement Example
“Risk Management Guide for DoD                  relationship to other risk areas [2].            determine a level of risk severity. In addi-
Acquisition” [4].                                                               defined, and tion to an overall even though risk in the
                                                     Once risks have been End users submit requirements changes method of we arerating,design
                                                                                 and conse- the model also baselined.
                                                probability of occurrence phase and the requirements have beengives good examples of
                                                quences assigned, the risk can be rated as probability levels and types and levels of
                                                   Consequence                  Changes could extend system design cycle and reduce available coding time.
Risk assessment involves two primary
                                                   Probability and Impact       80%. $2 million.
                                                    its severity. This                           consequences. The ratings given in the
                                                to Mitigation Actions facilitates prioritizing when?
activities: risk identification and risk                                        Who, what, and
                                                risks and deciding what level of resources assessment guide matrix are suggested
analysis. Risk identification is actually       to devote to each risk. Figure 3 depicts an minimum ratings. It may be necessary to
begun early in the planning phase and           assessment model using risk probability adjust the moderate and high thresholds
continues throughout the life of the pro-       and consequence levels in a matrix to to better coincide with the type of project.
ject. The following methods are often
used to identify possible risks [1]:            Figure 3: Defense Acquisition University Assessment Model [4]
• Brainstorming.
• Evaluations or inputs from project

• Periodic reviews of project data.                   Level      Likelihood Risk Will Happen

• Questionnaires based on taxonomy,                      a       Minimal/Remote

     the classification of product areas and             b       Small/Unlikely
     disciplines.                                        c       Probable/Likely
• Interviews based on taxonomy.                          d       Large/Highly Likely
• Analysis of the Work Breakdown
                                                         e       Significant/Near Certainty

• Analysis of historical data.
     When identifying a risk it is essential
to do so in a clear and concise statement.                                                                                       RISK IMPACT RATING
It should include three components [1]:                                        ASSESSMENT GUIDE
1. Condition: A sentence or phrase                                                                                              HIGH: Significant impact on cost,

     briefly describing the situation or cir-
                                                                             e                                                  schedule, and performance. Significant
                                                                                                                                action required. High priority

     cumstance that may have caused con-                                     d                                                  management attention required.

     cern, anxiety, or uncertainty.                                          c                                                  MODERATE: Some impact.
2. Consequence: A sentence describing
                                                                                                                                Special action may be required.
                                                                             b                                                  Additional management attention
     the key negative outcomes that may                                      a                                                  may be needed.

     result from the condition.                                                    1   2   3     4    5                         LOW: Minimum impact. Normal
3. Context: Additional information
                                                                                                                                oversight needed to ensure risk
                                                                                                                                remains low.
     about the risk to ensure others can
     understand its nature, especially after
     the passage of time.                                                                            CONSEQUENCE
Table 1 is an example of a risk statement                                                                                               Impact on Other Teams
                                                   Level      Technical Performance                       Schedule             Cost

     The other half of assessment is risk            1       Minimal or No Impact             Minimal or No Impact            Minimal
                                                                                                                              or None
analysis. This is the process of examining                   Acceptable With Some             Additional Resources Required
each risk to refine the risk description,            2       Reduction in Margin              – Able to Meet Need Dates        < 5%                Some

isolate the cause, quantify the probability          3
                                                             Acceptable With Significant      Minor Slip in Key Milestone –
                                                                                                                              5% - 7%
of occurrence, and determine the nature                      Reduction in Margin              Not Able to meet Need Dates                        Moderate

and impact of possible effects. The result           4
                                                             Acceptable – No
                                                             Remaining Margin
                                                                                              Minor Slip in Key Milestone or
                                                                                              Critical Path Impacted         7% - 10%              Major
of this process is a list of risks rated and                                                  Cannot Achieve Key Team of
prioritized according to their probability           5       Unacceptable
                                                                                              Major Project Milestone         > 10%           Unacceptable

of occurrence, severity of impact, and

February 2005                                        Figure 3: Defense Acquisition University Assessment Model [4]                               www.stsc.hill.af.mil   5
Risk Management       3: Defense Acquisition University Assessment Model [4]
                                                                                              K Are all project positions appropriately
    Identify                  Evaluate                      Select   Implement   Mitigation
                                                                                                staffed with qualified, motivated per-
Figure 4: Risk Handling Process                                                               K Are the developers trained and expe-
                                                                                                rienced in their respective develop-
                                              • Project metrics to be used for risk             ment disciplines (i.e., systems engi-
Risk handling is the process that identi-        management.
                                                                                                neering, software engineering, lan-
fies, evaluates, selects, and implements • Identified risks and their descriptions.
            Figure 4: Risk Handling Process                                                     guage, platform, tools, etc.)?
options for mitigating risks, as shown in • The probability, severity of impact,              K Are developers experienced or famil-
Figure 4. Two approaches are used in             and prioritization of all known risks.         iar with the technology and the devel-
handling risk. The first is to employ • Description of risk handling options                    opment environment?
options that reduce the risk itself. This        selected for implementation.                 K Are key personnel stable and likely to
usually involves a change in current con- • Project performance assessment                      remain in their positions throughout
ditions to lessen the probability of occur-      results, including deviations from the         the project?
rence. The second approach, often                baseline plans.                              K Is project funding stable and secure?
employed where risk probability is high, • Records of all changes to the above                K Are all costs associated with the pro-
is to use options that reduce the negative       documentation, including newly iden-           ject known?
impact to the project if the risk condition      tified risks, plan changes, etc.             K Are development tools and equip-
should occur. Improving jet engine main-                                                        ment used for the project state-of-
tenance and inspection procedures to Risk Management Checklist                                  the-art, dependable, and available in
reduce the risk of in-flight engine failure This checklist is provided to assist you in         sufficient quantity, and are the devel-
is an example of the first approach. risk management. If you answer no to                       opers familiar with the development
Providing a parachute for the pilot, to any of these questions, you should exam-                tools?
reduce loss if the risk condition should ine the situation carefully for the possibil-        K Are the schedule estimates free of
occur, is an example of the second ity of greater risks to the project. This is                 unknowns?
approach.                                     only a cursory checklist for such an            K Is the schedule realistic to support an
                                              important subject. Please see [5, 6] for          acceptable level of risk?
                                              more detailed checklists.                       K Is the project free of special environ-
Risk monitoring is the process of contin- K Do you have a comprehensive,
                                                                                                mental constraints or requirements?
ually tracking risks and the effectiveness       planned, and documented approach             K Is your testing approach feasible and
of risk handling options to ensure risk          to risk management?                            appropriate for the components and
conditions do not get out of control. K Are all major areas/disciplines repre-                  system?
This is done by knowing the baseline risk        sented on your risk management               K Have acceptance criteria been estab-
management plans, understanding the              team?                                          lished for all requirements and agreed
risks and risk handling options, establish- K Is the project manager experienced                to by all stakeholders?
ing meaningful metrics, and evaluating           with similar projects?                       K Will there be sufficient equipment to
project performance against the estab- K Do the stakeholders support disci-                     do adequate integration and testing?
lished metrics, plans, and expected results      plined development methods that              K Has sufficient time been scheduled
throughout the acquisition process.              incorporate adequate planning,                 for system integration and testing?
Continual monitoring also enables new            requirements analysis, design, and           K Can software be tested without com-
risks to be identified if they become            testing?                                       plex testing or special test equipment?
apparent over time. Monitoring further K Is the project manager dedicated to                  K Is a single group in one location
reveals the interrelationships between           this project, and not dividing his or          developing the system?
various risks [2].                               her time among other efforts?                K Are subcontractors reliable and
     The monitoring process provides K Are you implementing a proven                            proven?
feedback into all other activities to            development methodology?                     K Is all project work being done by
improve the ongoing, iterative risk man- K Are requirements well defined, under-                groups over which you have control?
agement process for the current and              standable, and stable?                       K Are development and support teams
future projects.                              K Do you have an effective require-               all collocated at one site?
                                                 ments change process in place, and do        K Is the project team accustomed to
                                                 you use it?                                    working on an effort of this size (nei-
Risk documentation is absolutely essen- K Does your project plan call for track-
                                                                                                ther bigger nor smaller)?
tial for the current, as well as future, pro-    ing/tracing requirements through all
jects. It consists of recording, maintain-       phases of the project?
ing, and reporting risk management K Are you implementing proven tech-
                                                                                              Project managers recognize and accept
plans, assessments, and handling infor-          nology?                                      the fact that risk is inherent in any pro-
mation. It also includes recording the K Are suppliers stable, and do you have                ject. The most successful project man-
results of risk management activities,           multiple sources for hardware and            agers choose to deal proactively with risk.
providing a knowledge base for better            equipment?                                   They carefully analyze future project
risk management in later stages of the K Are all procurement items needed for                 events and past projects to identify
project and in other projects [2].               your development effort short lead-          potential risks. Once risks are identified,
Documentation should include – as a              time items (no long-lead items)?             managers take steps to reduce their prob-
minimum – the following information:          K Are all external and internal interfaces      ability or reduce the impact associated
• Risk management plans.                         for the system well defined?                 with them by establishing and following a

6 CROSSTALK The Journal of   Defense Software Engineering                                                                      February 2005
                                                                                                             Understanding Risk Management

rigorous process, which involves the
entire project team as well as outside                 About the Author
experts. Risk management should include
hardware, software, integration issues,         The Software Technology Support
and the human element. A risk manage-           Center (STSC) produced the “Guide-               Get Your Free Subscription
ment process includes planning, assess-         lines for Successful Acquisition and
ment, handling, monitoring, and docu-           Management of Software-Intensive                   Fill out and send us this form.
mentation. Risk is a product of the             Systems.” Visit the STSC Web site at
uncertainty of future events and is a part      <www.stsc.hill.af.mil/resources/tech_                   OO-ALC/MASE
of all activity. Learning to balance its pos-   docs> to access all 17 chapters of this                  6022 Fir Ave
sible negative consequences with its            document. The STSC is dedicated to                        Bldg 1238
potential benefits is the key to successful
                                                helping the Air Force and other U.S.               Hill AFB, UT 84056-5820
risk management.N
                                                government organizations improve their          Fax: (801) 777-8069 DSN: 777-8069
                                                capability to buy and build software bet-     Phone: (801) 775-5555 DSN: 775-5555
                                                ter. The STSC provides hands-on assis-
1. Software Technology Support Center.
   “Life Cycle Software Project Manage-         tance in adopting effective technologies
                                                                                              Or request online at www.stsc.hill.af.mil

   ment.” Project Initiation. Hill Air          for software-intensive systems. The
   Force Base, UT, 9 Oct. 2001.                 STSC helps organizations identify, evalu-
2. Department of Defense. “Risk Man-            ate, and adopt technologies that improve
   agement Guide for DoD Acqui-                 software product quality, production         RANK/GRADE:___________________________
   sition.” Washington, D.C.: DoD Feb.          efficiency, and predictability. Technology
   2001: Chap. 2 <www.dsmc.dsm.mil/             is used in its broadest sense to include                     _________________________
   pubs/gdbks/risk_manag ement.                 processes, methods, techniques, and
                                                tools that enhance human capability. The                   __________________________
3. Higuera, Ron, and Yacov Haimes.
   “Software Risk Management.” Pitts-           STSC offers consulting services for soft-
   burgh, PA: Software Engineering              ware process improvement, software                    ________________________________
   Institute, 28 June 1996 <www.sei.            technology adoption, and software tech-
   cmu.edu/publications/documents/              nology evaluation, including the                        ________________________________
   96.reports/96.tr.012.html>.                  Capability Maturity Model® Integration,
4. Department of Defense. “Risk Man-            software acquisition, project manage-                   ______________________________
   agement Guide for DoD Acqui-                 ment, risk management, cost and sched-
   sition.” Washington, D.C.: DoD, Feb.         ule estimation, configuration manage-               _____________     _________________
   2001: Appendix B <www.dsmc.dsm.              ment, software measurement, and more.
   htm>.                                                                                                   ___________________________
5. Arizona State University. “Question
                                                    Software Technology

   List for Software Risk Identification                                                                 ______________________________
                                                    Support Center

   in the Classroom.” <www.eas.asu.
                                                    6022 Fir AVE BLDG 1238
                                                    Hill AFB, UT 84056-5820
6. Department of Energy. Risk Assess-               Phone: (801) 586-0154
   ment Questionnaire. <http://cio.                 DSN: 586-0154
                                                                                             CHECK BOX(ES)   TO REQUEST BACK ISSUES:
   doe.gov/sqse/pm_risk.htm>.                       E-mail: stsc.consulting@hill.af.mil
                                                                                             SEPT2003        DEFECT MANAGEMENT
                                                                                             OCT2003         INFORMATION SHARING
                                                                                             NOV2003         DEV. OF REAL-TIME SW
                                                                                             DEC2003         MANAGEMENT BASICS
                                                                                             MAR2004         SW PROCESS IMPROVEMENT
                                                                                             APR2004         ACQUISITION
                                                                                             MAY2004         TECH.: PROTECTING AMER.
                                                                                             JUN2004         ASSESSMENT AND CERT.
                                                                                             JULY2004        TOP 5 PROJECTS
                                                                                             AUG 2004        SYSTEMS APPROACH
                                                                                             SEPT2004        SOFTWARE EDGE
                                                                                             OCT2004         PROJECT MANAGEMENT
                                                                                             NOV2004         SOFTWARE TOOLBOX
                                                                                             DEC2004         REUSE
                                                                                             JAN2005         OPEN SOURCE SW
                                                                                             To Request Back Issues on Topics Not
                                                                                             Listed Above, Please Contact Karen
                                                                                             Rasmussen at <stsc.customerservice@

February 2005                                                                                                           www.stsc.hill.af.mil   7