OpenUP/OpenUP_PT/library/openup_basic/guidances/concepts/risk_management.xmi

<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-HhGIkAPjHSIxnPzI3cyDnQ" name="new_concept,_VNxL4ACsEdu8m4dIntu6jA" guid="-HhGIkAPjHSIxnPzI3cyDnQ" changeDate="2006-10-31T11:44:13.295-0800">
  <mainDescription>&lt;h3&gt;
    Introduction
&lt;/h3&gt;
&lt;p&gt;
    Every project contains some measure of uncertainty. The role of &lt;strong&gt;Risk Management&lt;/strong&gt; is to deal with this
    uncertainty to try to understand its&amp;nbsp;potential influence on the project. Project risks may be seen as threats or
    opportunities. The former means the risk should be mitigated (see risk management strategies below) where the latter
    means that&amp;nbsp;taking a&amp;nbsp;calculated risk may bring, for example, competitive advantage for a product or
    organization [&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;&gt;SEI99&lt;/a&gt;].
&lt;/p&gt;
&lt;p&gt;
    Identify risks as soon as the project starts and continue identifying and managing risks throughout the project. A
    common mistake is to identify risks only at the beginning of the project and then only track the status of these
    initial risks. The risk list should be revisited weekly, or as a minimum once per iteration, to add any newly
    discovered risk.
&lt;/p&gt;
&lt;h3&gt;
    Risks Prioritization
&lt;/h3&gt;
&lt;p&gt;
    A good approach for prioritizing risks is to have an attribute called risk magnitude, a combination of the risk
    probability and the risk impact. Each iteration provides a chance&amp;nbsp;for better understanding of stakeholder needs,
    the team capabilities, the technology at hand, and so on. Capture, quantify&amp;nbsp;and prioritize risks as they arise.
    High magnitude risks are&amp;nbsp;attacked first, thus&amp;nbsp;improving the chances of project success and minimizing
    uncertainty. See &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup_basic/guidances/templates/risk_list,_MIUO0C8FEduzydamRseoUw.html&quot; guid=&quot;_MIUO0C8FEduzydamRseoUw&quot;&gt;Template: Risk List&lt;/a&gt;&amp;nbsp;for more information.
&lt;/p&gt;
&lt;h3&gt;
    Risk Management Strategies
&lt;/h3&gt;
&lt;p&gt;
    Once you have chosen a set of risks to focus on, choose a mitigation strategy, as described below. Then, identify and
    assign tasks to apply the strategy to the given risk. Follow up regularly on risk-mitigation actions. Try another
    strategy if your chosen strategy does not reduce the magnitude of a risk.
&lt;/p&gt;
&lt;p&gt;
    Common mitigation strategies are:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        Risk avoidance: reorganize the project so that it cannot be affected by that risk. 
        &lt;ul&gt;
            &lt;li&gt;
                For example: you need to use a new framework. A risk avoidance strategy could be to drop this new framework
                and using another one that is already understood by the team.&lt;br /&gt;
            &lt;/li&gt;
        &lt;/ul&gt;
    &lt;/li&gt;
    &lt;li&gt;
        Risk transfer: reorganize the project so that someone or something else bears the risk. 
        &lt;ul&gt;
            &lt;li&gt;
                For example: the application you are developing needs to communicate with a legacy system. A risk transfer
                strategy&amp;nbsp;would make the legacy support team responsible of providing the APIs to access the legacy
                system.&lt;br /&gt;
            &lt;/li&gt;
        &lt;/ul&gt;
    &lt;/li&gt;
    &lt;li&gt;
        Risk mitigation: define a mitigation plan to&amp;nbsp;reduce the probability or the impact of the risk. 
        &lt;ul&gt;
            &lt;li&gt;
                For example: you need to use a new middleware. A risk mitigation strategy could be to build a prototype
                using this new middleware to validate that&amp;nbsp;it will provide the features you need for your
                application.&lt;br /&gt;
            &lt;/li&gt;
        &lt;/ul&gt;
    &lt;/li&gt;
    &lt;li&gt;
        Risk acceptance: decide to live with the risk, and define a contingency plan.
    &lt;/li&gt;
    &lt;li style=&quot;LIST-STYLE-TYPE: none&quot;&gt;
        &lt;ul&gt;
            &lt;li&gt;
                For example: your integrator is the only one who knows how to integrate the different components of your
                application. A contingency plan could be to identify a resource on another project that you could bring on
                if your integrator is sick, leaves the company, etc.
            &lt;/li&gt;
        &lt;/ul&gt;
    &lt;/li&gt;
&lt;/ul&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>