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