| <?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_basic\guidances\concepts\risk_management.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_management.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_VNxL4ACsEdu8m4dIntu6jA CRC: 2898038623 -->Risk Management<!-- END:presentationName,_VNxL4ACsEdu8m4dIntu6jA --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_VNxL4ACsEdu8m4dIntu6jA CRC: 1944800072 -->This is a fundamental practice that project managers should consider in their projects. Identifying and minimizing risks early in the project lifecycle is key factor for project success.<!-- END:briefDescription,_VNxL4ACsEdu8m4dIntu6jA --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-HhGIkAPjHSIxnPzI3cyDnQ CRC: 1504106051 --><h3> |
| Introduction |
| </h3> |
| <p> |
| Every project contains some measure of uncertainty. The role of <strong>Risk Management</strong> is to deal with this |
| uncertainty to try to understand its 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 taking a calculated risk may bring, for example, competitive advantage for a product or |
| organization [<a class="elementLinkWithUserText" href="./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" guid="_9ToeIB83Edqsvps02rpOOg">SEI99</a>]. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3> |
| Risks Prioritization |
| </h3> |
| <p> |
| 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 for better understanding of stakeholder needs, |
| the team capabilities, the technology at hand, and so on. Capture, quantify and prioritize risks as they arise. |
| High magnitude risks are attacked first, thus improving the chances of project success and minimizing |
| uncertainty. See <a class="elementLinkWithType" href="./../../../openup_basic/guidances/templates/risk_list,_MIUO0C8FEduzydamRseoUw.html" guid="_MIUO0C8FEduzydamRseoUw">Template: Risk List</a> for more information. |
| </p> |
| <h3> |
| Risk Management Strategies |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| Common mitigation strategies are: |
| </p> |
| <ul> |
| <li> |
| Risk avoidance: reorganize the project so that it cannot be affected by that risk. |
| <ul> |
| <li> |
| 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.<br /> |
| </li> |
| </ul> |
| </li> |
| <li> |
| Risk transfer: reorganize the project so that someone or something else bears the risk. |
| <ul> |
| <li> |
| For example: the application you are developing needs to communicate with a legacy system. A risk transfer |
| strategy would make the legacy support team responsible of providing the APIs to access the legacy |
| system.<br /> |
| </li> |
| </ul> |
| </li> |
| <li> |
| Risk mitigation: define a mitigation plan to reduce the probability or the impact of the risk. |
| <ul> |
| <li> |
| 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 it will provide the features you need for your |
| application.<br /> |
| </li> |
| </ul> |
| </li> |
| <li> |
| Risk acceptance: decide to live with the risk, and define a contingency plan. |
| </li> |
| <li style="LIST-STYLE-TYPE: none"> |
| <ul> |
| <li> |
| 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. |
| </li> |
| </ul> |
| </li> |
| </ul><!-- END:mainDescription,-HhGIkAPjHSIxnPzI3cyDnQ --> |
| </body> |
| </html> |