| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>openup&#92;guidances&#92;concepts&#92;&#92;risk.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: risk.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_0bsLgMlgEdmt3adZL5Dmdw CRC: 3644095103 -->Risk<!-- END:presentationName,_0bsLgMlgEdmt3adZL5Dmdw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_0bsLgMlgEdmt3adZL5Dmdw CRC: 1459999167 -->A risk is whatever may stand in the way of success, and is currently unknown or uncertain. Usually, a risk is qualified by the probability of its occurrence and the impact in the project, if it occurs.<!-- END:briefDescription,_0bsLgMlgEdmt3adZL5Dmdw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,_u6enMMM1EdmSIPI87WLu3g CRC: 1466811396 --><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><!-- END:mainDescription,_u6enMMM1EdmSIPI87WLu3g --> |
| </body> |
| </html> |
