<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="_u6enMMM1EdmSIPI87WLu3g"
    name="risk,_0bsLgMlgEdmt3adZL5Dmdw" guid="_u6enMMM1EdmSIPI87WLu3g" changeDate="2007-06-25T11:29:48.405-0700"
    version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    What is a Risk?&#xD;
&lt;/h3>&#xD;
&lt;p>A risk is an uncertain event or condition that, if it occurs, will have a negative or positive effect on one or more&#xD;
project objectives [&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#PMI04&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>PMI04&lt;/a>]. Project risks may be seen as threats or opportunities. The latter means&#xD;
that taking a calculated risk may bring, for example, competitive advantage for a product or organization. &#xD;
If there are benefits associated with an opportunity, then you can take certain degrees of risk for a project to&#xD;
be successful [&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#SEI99&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>SEI99&lt;/a>].&lt;/p> &#xD;
&lt;p>&#xD;
    In everyday life a risk is an exposure to loss or injury: A factor, thing, element, or course involving uncertain&#xD;
    danger. Similarly, in software development a risk is something that can compromise the success of a project.&#xD;
    Examples of potential sources of risk in software development are listed below (see [&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#SEI99&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>SEI99&lt;/a>] for more details):&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Requirements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Design&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Development process&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Work environment&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Resources&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Contract&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Project interdependencies&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        And so on&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Risk Attributes&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    You can record as much information as you like or need about your risks. You will find a list of common risk&#xD;
    attributes following.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Risk Description:&lt;/b> A description of the risk detailing the impact for the project if this risk&#xD;
        becomes a problem (that is, it becomes a reality).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Risk Category&lt;/b>: Risk identification is usually more easily done when there is a &quot;mental framework&quot;&#xD;
        in place to ensure that potential areas of risk are not overlooked. One way of doing this is to divide risks into&#xD;
        categories (such as technical, project management, organizational, and external), to ensure that all aspects of the&#xD;
        project which are prone to risk are covered.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Risk Type:&lt;/b> Used to classify the risk as:&#xD;
    &lt;/li>&#xD;
    &lt;li style=&quot;LIST-STYLE-TYPE: none&quot;>&#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                &lt;b>Direct risk&lt;/b>: A risk that the project has a large degree of control over&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                &lt;b>Indirect risk&lt;/b>: A risk with little or no project control&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Risk Probability:&lt;/b> How likely the risk event will happen. This is usually represented as a scale of&#xD;
        values (for example: High, Medium, Low). Probability is one of the most difficult quantities to judge accurately.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Risk Impact&lt;/b> (level): If this risk becomes a problem, what will the impact on&#xD;
        the project be? This is not the actual &lt;b>description&lt;/b> of the impact, but the &lt;b>level&lt;/b> of impact. As the risk&#xD;
        probability, it is usually represented as a scale. This attribute is also sometimes called the&#xD;
        &lt;b>severity&lt;/b> of the risk.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Risk Magnitude&lt;/b>: To be able to rank and define which risks need to be mitigate first, the&#xD;
        &lt;b>Risk Probability &lt;/b> and &lt;b>Risk Impact&lt;/b> attributes are often combined in a&#xD;
        single &lt;b>Risk&lt;/b> &lt;b>Magnitude&lt;/b> indicator represented as a scale similar to the&#xD;
        combined attributes.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Risk Response Strategies&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The risk response should be in line with the significance of the risk. The strategies for handling risk cover two&#xD;
    main types: negative risks and positive risks (or opportunities). Common response strategies for negative risks or&#xD;
    threats include:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Avoid&lt;/b>: Reorganize the project so that it cannot be affected by that risk (for example, removing work)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Mitigate&lt;/b>: Define actions to reduce the probability or the impact of the risk, removing it from the&#xD;
        top of the list&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Transfer&lt;/b>: Reorganize the project so that someone or something else bears the risk. It simply&#xD;
        gives another party responsibility for its management. It doesn't eliminate the risk.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Common response strategies for positive risks or opportunities include:&#xD;
&lt;/p>&#xD;
&lt;ul class=&quot;noindent&quot;>&#xD;
    &lt;li>&#xD;
        &lt;b>Exploit&lt;/b>: Add work or reorganize the project to make sure that the opportunity occurs (it&#xD;
        is the reverse of avoid)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Enhance&lt;/b>: Define actions to increase the probability or the positive impact of the risk&#xD;
        (this is the reverse of mitigate)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Share&lt;/b>: Allocate&#xD;
        the ownership of the opportunity to a third party who is best able to capture the opportunity for the&#xD;
        benefit of the project.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Another response strategy for both threats or opportunities is to &lt;b>Accept&lt;/b>: Decide to live with the&#xD;
    risk, and define a contingency plan.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Some scenarios for software development may help to make these concepts more clear:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        You need to use a new framework. A risk avoidance strategy could be to drop this new framework and use another&#xD;
        one that is already understood by the team.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The application you are developing needs to communicate with a legacy system. A risk transfer strategy would&#xD;
        be to have the legacy support team be responsible for providing the APIs to access the legacy system.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        You need to use new middleware. A risk mitigation strategy could be to build a prototype using this new middleware&#xD;
        to validate that it will provide the features you need for your application.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Your integrator is the only one who knows how to integrate the different components of your application. A&#xD;
        contingency plan could be to identify a resource on another project that you could bring on if your integrator is&#xD;
        sick, leaves the company, and so on.&#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>