| <?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><h1>
 |
| What is a Risk?
 |
| </h1>
 |
| <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="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#PMI"
 |
| guid="_JlTPUM6aEdyuBO4ZIzcyig">PMI</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="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SEI99"
 |
| guid="_JlTPUM6aEdyuBO4ZIzcyig">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="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#SEI99"
 |
| guid="_JlTPUM6aEdyuBO4ZIzcyig">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>
 |
| <h1>
 |
| Risk Attributes
 |
| </h1>
 |
| <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>
 |
| <h1>
 |
| Risk Response Strategies
 |
| </h1>
 |
| <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> |
