<?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.5.0" xmi:id="_u6enMMM1EdmSIPI87WLu3g"
    name="risk,_0bsLgMlgEdmt3adZL5Dmdw" guid="_u6enMMM1EdmSIPI87WLu3g" changeDate="2008-09-30T12:48:15.064-0700"
    version="7.2.0">
  <mainDescription>&lt;h1>&#xD;
    What is a Risk?&#xD;
&lt;/h1>&#xD;
&lt;p>&#xD;
    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;&#xD;
    href=&quot;./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#PMI&quot;&#xD;
    guid=&quot;_JlTPUM6aEdyuBO4ZIzcyig&quot;>PMI&lt;/a>]. Project risks may be seen as threats or opportunities. The latter means that&#xD;
    taking a calculated risk may bring, for example, competitive advantage for a product or organization. If there are&#xD;
    benefits associated with an opportunity, then you can take certain degrees of risk for a project to be successful [&lt;a&#xD;
    class=&quot;elementLinkWithUserText&quot;&#xD;
    href=&quot;./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SEI99&quot;&#xD;
    guid=&quot;_JlTPUM6aEdyuBO4ZIzcyig&quot;>SEI99&lt;/a>].&#xD;
&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. Examples&#xD;
    of potential sources of risk in software development are listed below (see [&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
    href=&quot;./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SEI99&quot;&#xD;
    guid=&quot;_JlTPUM6aEdyuBO4ZIzcyig&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;h1>&#xD;
    Risk Attributes&#xD;
&lt;/h1>&#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 attributes&#xD;
    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 becomes a&#xD;
        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; in place&#xD;
        to ensure that potential areas of risk are not overlooked. One way of doing this is to divide risks into categories&#xD;
        (such as technical, project management, organizational, and external), to ensure that all aspects of the project&#xD;
        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 values&#xD;
        (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 the project be? This is not the&#xD;
        actual &lt;b>description&lt;/b> of the impact, but the &lt;b>level&lt;/b> of impact. As the risk probability, it is usually&#xD;
        represented as a scale. This attribute is also sometimes called the &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 &lt;b>Risk&#xD;
        Probability&lt;/b> and &lt;b>Risk Impact&lt;/b> attributes are often combined in a single &lt;b>Risk&lt;/b> &lt;b>Magnitude&lt;/b>&#xD;
        indicator represented as a scale similar to the combined attributes.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h1>&#xD;
    Risk Response Strategies&#xD;
&lt;/h1>&#xD;
&lt;p>&#xD;
    The risk response should be in line with the significance of the risk. The strategies for handling risk cover two main&#xD;
    types: negative risks and positive risks (or opportunities). Common response strategies for negative risks or threats&#xD;
    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 top of&#xD;
        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 gives another&#xD;
        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 is the reverse of&#xD;
        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 (this is the reverse&#xD;
        of mitigate)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Share&lt;/b>: Allocate the ownership of the opportunity to a third party who is best able to capture the&#xD;
        opportunity for the 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 risk, and&#xD;
    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 one&#xD;
        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 be to&#xD;
        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>