<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-GB">
	<id>http://13.50.150.85/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=MartinKruck</id>
	<title>DTU ProjectLab - User contributions [en-gb]</title>
	<link rel="self" type="application/atom+xml" href="http://13.50.150.85/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=MartinKruck"/>
	<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php/Special:Contributions/MartinKruck"/>
	<updated>2026-07-14T17:27:01Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.43.3</generator>
	<entry>
		<id>http://13.50.150.85/index.php?title=Talk:Risk_management_strategy&amp;diff=6400</id>
		<title>Talk:Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Talk:Risk_management_strategy&amp;diff=6400"/>
		<updated>2014-12-01T19:17:45Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Review from Username111 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Review from Username111 ==&lt;br /&gt;
&lt;br /&gt;
First of all, it doesn&#039;t look like the article is complete yet. Therefore, I will only give a review based on the abstract, structure and the risk processing chapter (doesn&#039;t seem complete either but I&#039;ll use what is produced so far)  which is currently produced (November 25th 15:00). However, the topic seems interesting and very relevant for any project manager (or student within project management). It seems clear that the article is under in-depth method description category, due to each of the proposed chapters will have method descriptions.  &lt;br /&gt;
&lt;br /&gt;
I like the proposed structure of the article. I believe that it will create a good flow with a clear red thread. &lt;br /&gt;
&lt;br /&gt;
These are my specific questions and suggestions: &lt;br /&gt;
&lt;br /&gt;
* Maybe you could add a general example to each of the chapters. This could further strengthen the arguments of using the methods. E.g. you could give an example of an identified risk in &amp;quot;risk identification&amp;quot;, analyze this specific risk in &amp;quot;risk analysis&amp;quot;, assess the risk in &amp;quot;risk assessment&amp;quot;, and finally propose mitigation action for the risk in &amp;quot;risk processing&amp;quot;. This would give the reader a clear understanding of how to use the proposed methods in each of the chapters.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; GREAT IDEA! I have included that in the article.  &lt;br /&gt;
* There seems to be a lack of proper referencing. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Should be fixed now.&lt;br /&gt;
** In the first sentence you reference to (Machiavelli, 1514), but there is no bibliography were I can find the actual article/journal/book.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Added&lt;br /&gt;
** In the second paragraph in the abstract there is a lot of interesting statements of risk management.  I guess most of them are not something you have created out of your own thoughts, and therefore they need referencing to the correct sources. E.g. the definition of risk: &amp;quot;&#039;&#039;A risk can be defined as the product of the probability of the risk and the impact of the risk&#039;&#039;&amp;quot; needs referencing. Maybe some of the statements are common sense for a project manager, but I would still suggest using some references to academic resources in order to improve the quality of the article. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Saying a risk is a product of probability and impact is just the short(and more accurate) way of saying: &amp;quot;A risk is when something might go wrong&amp;quot;. However finding were this was first used is too time consuming and of little consequence for the credibility of the article. I will therefor not try to find a reference, but thank you for the tip.&lt;br /&gt;
** Your dice example needs need a reference as well, unless you came up with it yourself of course. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; I am actually a habitual wargamer (warhammer 40000) where determining probability related to dice rolls is a major advantage. This is of my own creation.&lt;br /&gt;
* In the second paragraph you give two examples; when a problem is likely to happen but no impact, and when a problem is unlikely to happen and high impact. Maybe you could add a few more examples, in order to introduce scenarios were risk mitigation action is required.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Example added.&lt;br /&gt;
* You talk about &amp;quot;injuries&amp;quot; in relation to the impact of a given risk. I consider an injury something that can occur to an person. E.g. Bendtner sustained an injury after scoring his 6th goal. I would propose to use: consequence, damage, etc., since it often will be the impact in the project/company, not the person.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; injuries replaced with impacts&lt;br /&gt;
* This sentence is very hard to read: &amp;quot;&#039;&#039;If there is no certain way to determine a risk’s impact or probability or multiple risks are compared without having similar impact type (e.g. comparing human casualties against monetary loss) a qualitative approach can be used, where the risk is rated from e.g. 1-5.&#039;&#039;&amp;quot;. Please consider revising, in order to make it more understandable. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Sentence removed.   &lt;br /&gt;
* Since you already mention there are several other apppm wikis about risk management, you could use these as potential references, instead of just saying they might be similar.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Sentence removed.&lt;br /&gt;
* The risk processing chapter:  It seems like the chapter is not completely done. I would suggest to begin this chapter with describing the different methods/strategies (accept, mitigate, transfer, avoid, improve), and then follow by when you would use these different methods/strategies. Ideally you could give an example in the end of a risk that has been mitigated using one of the methods/strategies. Remember proper referencing for this chapter as well.  &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; The current layout was kept, but your idea was considered and actually implemented at first. However due to the flow of the article, I reverted back to the first layout, since I felt it gave a better flow.&lt;br /&gt;
&lt;br /&gt;
Other than these few comments, good job. Just fill in the chapters and make sure to use proper referencing, and the article will be great :)&lt;br /&gt;
&lt;br /&gt;
Good luck!&lt;br /&gt;
&lt;br /&gt;
== Review from Xyz ==&lt;br /&gt;
&lt;br /&gt;
You have chosen a very exiting topic and is a very good first outcast, but obviously it&#039;s not complete.&lt;br /&gt;
* The spelling, grammar and punctuation looks fine to me. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Thank you ;)&lt;br /&gt;
* The article is generally easy to understand, but some of the sentences are bit long and hard to follow. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Sorry about that. I&#039;ll try to cut down on my sentences.&lt;br /&gt;
* There are so fare no figures. It would be easier to understand the main points, if there were a few figures. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Figures added.&lt;br /&gt;
* I find the topic very interesting and relevant, and i think any person within project management would to.&lt;br /&gt;
* To me it seams like article belongs to the method description category.&lt;br /&gt;
* I think there will be a nice flow through out the article, when it is finished. &lt;br /&gt;
* It would be nice to finish the article with a short summery/conclusion.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Added.&lt;br /&gt;
* It might be a good idea to have some more solid references.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Added.&lt;br /&gt;
&lt;br /&gt;
-Good luck.&lt;br /&gt;
&lt;br /&gt;
== Picture ==&lt;br /&gt;
&lt;br /&gt;
The picture you use seems to be taken as snapshot from the ISO 31000.. that is copyrighted.. you can use the one which I have uploaded.. check files.&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6376</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6376"/>
		<updated>2014-12-01T19:06:11Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve arranges a meeting with the three friend, to discuss possible risks. The group comes up with a lot of possible risks, by telling Steve about their business model and answering his &amp;quot;.. but what if..&amp;quot;-questions. Some of these are listed below:&lt;br /&gt;
&lt;br /&gt;
1. Bicycles are unusable due to wear, damage or theft. This would induce a serious impact on the business since they only have three bicycles and relies on mobility.&lt;br /&gt;
&lt;br /&gt;
2. The remaining suppliers does not sign a contract. Products will either not be available, leading to poorer service or more expensive deals will have to be struck to ensure the right products.&lt;br /&gt;
&lt;br /&gt;
3. Traffic accidents leading to sick days. Since the business revolves around bicycling in a busy city.&lt;br /&gt;
&lt;br /&gt;
4. Suppliers cannot meet demand. The decision to use high quality good, means that changes to increase supply quantities takes a long time to realize.&lt;br /&gt;
&lt;br /&gt;
5. Sickness or injuries. The business relies on that Adam, John and Fred are able to bike in any weather. Should any one of them be unable to work due to sickness or injuries the business will lose a third of it earnings.&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Following the example, Steve talks to the three friends about how likely they feel each risk is and what impact it could have.&lt;br /&gt;
All this, Steve puts into a matrix.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || The guys think that this might happen to some times during a season. || The bikes are easily replaced or repaired, but this is a bit expensive.&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || The guys believe that all contracts are sign before start-up, this is not likely. || This could prove to be a moderate set back.&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || The friends believe that this is not likely to happen, since they are all experienced cyclists || This will have a serious impact.&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || Adam, John and Fred does not think is likely to happen || However, should the business be out of stock it could take weeks to resupply, which will be a great loss of money.&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || It is believed that this is very likely to happen, since non of them are used to biking or being outside for 8 hours. || Serious illnesses and traffic accidents aside, this will only have a small impact since it is most likely to only infer a single sick day or two.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Steve determines the risk levels:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || 4 || 2&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || 1 || 3&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || 2 || 4&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || 1 || 5&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || 5 || 2&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
With the risk levels determined, Steve makes a risk assesment:&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk assesment&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || &amp;lt;math&amp;gt;4*2=8&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || &amp;lt;math&amp;gt;1*3=3&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || &amp;lt;math&amp;gt;2*4=8&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || &amp;lt;math&amp;gt;1*5=5&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || &amp;lt;math&amp;gt;5*2=10&amp;lt;/math&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Put into the probability-impact matrix:&lt;br /&gt;
[[File:LC-matrix ex1.png|300px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The prioritize list of risks is therefore:&lt;br /&gt;
* 5 - Sickness or injury&lt;br /&gt;
* 3 - Accidents&lt;br /&gt;
* 1 - Lack of bikes&lt;br /&gt;
* 4 - Lacking supplies&lt;br /&gt;
* 2 - Missing suppliers&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve then talks for the guys about how to process each risk&lt;br /&gt;
&lt;br /&gt;
* 5 - Sickness or injury: Should be transferred. The transfer could be hiring part-time workers or having a temp at hand.&lt;br /&gt;
* 3 - Accidents: Should be both mitigated and transferred. The transfer lies in have an insurance, but the consequences of an accident could be lessened by wearing protective gear.&lt;br /&gt;
* 1 - Lack of bikes: Should be mitigated. This could be done by have a spare bike ready in case of emergencies, having spare parts for minor repairs and training in repairing the bicycles.&lt;br /&gt;
* 4 - Lacking supplies: Should be transferred. Steve suggests that the guys makes a deal with a store, that runs the same wares and make a trade agreement. This way the business is not responsible for the keeping a ready supply.&lt;br /&gt;
* 2 - Missing suppliers: Should be accepted. Finding another supplier will only be a problem is the business also lacks supplies.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
After the meeting, Steve tells the other guys to remember to check up on each of the identified risks at least once a month, using a check-list. They also agrees to have a meeting in June to reevaluate the risks and find new risks.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6374</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6374"/>
		<updated>2014-12-01T19:05:33Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk Monitoring */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve arranges a meeting with the three friend, to discuss possible risks. The group comes up with a lot of possible risks, by telling Steve about their business model and answering his &amp;quot;.. but what if..&amp;quot;-questions. Some of these are listed below:&lt;br /&gt;
&lt;br /&gt;
1. Bicycles are unusable due to wear, damage or theft. This would induce a serious impact on the business since they only have three bicycles and relies on mobility.&lt;br /&gt;
&lt;br /&gt;
2. The remaining suppliers does not sign a contract. Products will either not be available, leading to poorer service or more expensive deals will have to be struck to ensure the right products.&lt;br /&gt;
&lt;br /&gt;
3. Traffic accidents leading to sick days. Since the business revolves around bicycling in a busy city.&lt;br /&gt;
&lt;br /&gt;
4. Suppliers cannot meet demand. The decision to use high quality good, means that changes to increase supply quantities takes a long time to realize.&lt;br /&gt;
&lt;br /&gt;
5. Sickness or injuries. The business relies on that Adam, John and Fred are able to bike in any weather. Should any one of them be unable to work due to sickness or injuries the business will lose a third of it earnings.&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Following the example, Steve talks to the three friends about how likely they feel each risk is and what impact it could have.&lt;br /&gt;
All this, Steve puts into a matrix.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || The guys think that this might happen to some times during a season. || The bikes are easily replaced or repaired, but this is a bit expensive.&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || The guys believe that all contracts are sign before start-up, this is not likely. || This could prove to be a moderate set back.&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || The friends believe that this is not likely to happen, since they are all experienced cyclists || This will have a serious impact.&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || Adam, John and Fred does not think is likely to happen || However, should the business be out of stock it could take weeks to resupply, which will be a great loss of money.&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || It is believed that this is very likely to happen, since non of them are used to biking or being outside for 8 hours. || Serious illnesses and traffic accidents aside, this will only have a small impact since it is most likely to only infer a single sick day or two.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Steve determines the risk levels:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || 4 || 2&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || 1 || 3&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || 2 || 4&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || 1 || 5&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || 5 || 2&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
With the risk levels determined, Steve makes a risk assesment:&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk assesment&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || &amp;lt;math&amp;gt;4*2=8&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || &amp;lt;math&amp;gt;1*3=3&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || &amp;lt;math&amp;gt;2*4=8&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || &amp;lt;math&amp;gt;1*5=5&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || &amp;lt;math&amp;gt;5*2=10&amp;lt;/math&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Put into the probability-impact matrix:&lt;br /&gt;
[[File:LC-matrix ex1.png|300px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The prioritize list of risks is therefore:&lt;br /&gt;
* 5 - Sickness or injury&lt;br /&gt;
* 3 - Accidents&lt;br /&gt;
* 1 - Lack of bikes&lt;br /&gt;
* 4 - Lacking supplies&lt;br /&gt;
* 2 - Missing suppliers&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve then talks for the guys about how to process each risk&lt;br /&gt;
&lt;br /&gt;
* 5 - Sickness or injury: Should be transferred. The transfer could be hiring part-time workers or having a temp at hand.&lt;br /&gt;
* 3 - Accidents: Should be both mitigated and transferred. The transfer lies in have an insurance, but the consequences of an accident could be lessened by wearing protective gear.&lt;br /&gt;
* 1 - Lack of bikes: Should be mitigated. This could be done by have a spare bike ready in case of emergencies, having spare parts for minor repairs and training in repairing the bicycles.&lt;br /&gt;
* 4 - Lacking supplies: Should be transferred. Steve suggests that the guys makes a deal with a store, that runs the same wares and make a trade agreement. This way the business is not responsible for the keeping a ready supply.&lt;br /&gt;
* 2 - Missing suppliers: Should be accepted. Finding another supplier will only be a problem is the business also lacks supplies.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
After the meeting, Steve tells the other guys to remember to check up on each of the identified risks at least once a month. They also agrees to have a meeting in June to reevaluate the risks and find new risks.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6362</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6362"/>
		<updated>2014-12-01T19:02:30Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk process responses */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve arranges a meeting with the three friend, to discuss possible risks. The group comes up with a lot of possible risks, by telling Steve about their business model and answering his &amp;quot;.. but what if..&amp;quot;-questions. Some of these are listed below:&lt;br /&gt;
&lt;br /&gt;
1. Bicycles are unusable due to wear, damage or theft. This would induce a serious impact on the business since they only have three bicycles and relies on mobility.&lt;br /&gt;
&lt;br /&gt;
2. The remaining suppliers does not sign a contract. Products will either not be available, leading to poorer service or more expensive deals will have to be struck to ensure the right products.&lt;br /&gt;
&lt;br /&gt;
3. Traffic accidents leading to sick days. Since the business revolves around bicycling in a busy city.&lt;br /&gt;
&lt;br /&gt;
4. Suppliers cannot meet demand. The decision to use high quality good, means that changes to increase supply quantities takes a long time to realize.&lt;br /&gt;
&lt;br /&gt;
5. Sickness or injuries. The business relies on that Adam, John and Fred are able to bike in any weather. Should any one of them be unable to work due to sickness or injuries the business will lose a third of it earnings.&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Following the example, Steve talks to the three friends about how likely they feel each risk is and what impact it could have.&lt;br /&gt;
All this, Steve puts into a matrix.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || The guys think that this might happen to some times during a season. || The bikes are easily replaced or repaired, but this is a bit expensive.&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || The guys believe that all contracts are sign before start-up, this is not likely. || This could prove to be a moderate set back.&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || The friends believe that this is not likely to happen, since they are all experienced cyclists || This will have a serious impact.&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || Adam, John and Fred does not think is likely to happen || However, should the business be out of stock it could take weeks to resupply, which will be a great loss of money.&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || It is believed that this is very likely to happen, since non of them are used to biking or being outside for 8 hours. || Serious illnesses and traffic accidents aside, this will only have a small impact since it is most likely to only infer a single sick day or two.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Steve determines the risk levels:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || 4 || 2&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || 1 || 3&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || 2 || 4&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || 1 || 5&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || 5 || 2&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
With the risk levels determined, Steve makes a risk assesment:&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk assesment&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || &amp;lt;math&amp;gt;4*2=8&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || &amp;lt;math&amp;gt;1*3=3&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || &amp;lt;math&amp;gt;2*4=8&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || &amp;lt;math&amp;gt;1*5=5&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || &amp;lt;math&amp;gt;5*2=10&amp;lt;/math&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Put into the probability-impact matrix:&lt;br /&gt;
[[File:LC-matrix ex1.png|300px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The prioritize list of risks is therefore:&lt;br /&gt;
* 5 - Sickness or injury&lt;br /&gt;
* 3 - Accidents&lt;br /&gt;
* 1 - Lack of bikes&lt;br /&gt;
* 4 - Lacking supplies&lt;br /&gt;
* 2 - Missing suppliers&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve then talks for the guys about how to process each risk&lt;br /&gt;
&lt;br /&gt;
* 5 - Sickness or injury: Should be transferred. The transfer could be hiring part-time workers or having a temp at hand.&lt;br /&gt;
* 3 - Accidents: Should be both mitigated and transferred. The transfer lies in have an insurance, but the consequences of an accident could be lessened by wearing protective gear.&lt;br /&gt;
* 1 - Lack of bikes: Should be mitigated. This could be done by have a spare bike ready in case of emergencies, having spare parts for minor repairs and training in repairing the bicycles.&lt;br /&gt;
* 4 - Lacking supplies: Should be transferred. Steve suggests that the guys makes a deal with a store, that runs the same wares and make a trade agreement. This way the business is not responsible for the keeping a ready supply.&lt;br /&gt;
* 2 - Missing suppliers: Should be accepted. Finding another supplier will only be a problem is the business also lacks supplies.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6316</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6316"/>
		<updated>2014-12-01T18:46:50Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve arranges a meeting with the three friend, to discuss possible risks. The group comes up with a lot of possible risks, by telling Steve about their business model and answering his &amp;quot;.. but what if..&amp;quot;-questions. Some of these are listed below:&lt;br /&gt;
&lt;br /&gt;
1. Bicycles are unusable due to wear, damage or theft. This would induce a serious impact on the business since they only have three bicycles and relies on mobility.&lt;br /&gt;
&lt;br /&gt;
2. The remaining suppliers does not sign a contract. Products will either not be available, leading to poorer service or more expensive deals will have to be struck to ensure the right products.&lt;br /&gt;
&lt;br /&gt;
3. Traffic accidents leading to sick days. Since the business revolves around bicycling in a busy city.&lt;br /&gt;
&lt;br /&gt;
4. Suppliers cannot meet demand. The decision to use high quality good, means that changes to increase supply quantities takes a long time to realize.&lt;br /&gt;
&lt;br /&gt;
5. Sickness or injuries. The business relies on that Adam, John and Fred are able to bike in any weather. Should any one of them be unable to work due to sickness or injuries the business will lose a third of it earnings.&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Following the example, Steve talks to the three friends about how likely they feel each risk is and what impact it could have.&lt;br /&gt;
All this, Steve puts into a matrix.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || The guys think that this might happen to some times during a season. || The bikes are easily replaced or repaired, but this is a bit expensive.&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || The guys believe that all contracts are sign before start-up, this is not likely. || This could prove to be a moderate set back.&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || The friends believe that this is not likely to happen, since they are all experienced cyclists || This will have a serious impact.&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || Adam, John and Fred does not think is likely to happen || However, should the business be out of stock it could take weeks to resupply, which will be a great loss of money.&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || It is believed that this is very likely to happen, since non of them are used to biking or being outside for 8 hours. || Serious illnesses and traffic accidents aside, this will only have a small impact since it is most likely to only infer a single sick day or two.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Steve determines the risk levels:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || 4 || 2&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || 1 || 3&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || 2 || 4&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || 1 || 5&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || 5 || 2&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
With the risk levels determined, Steve makes a risk assesment:&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk assesment&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || &amp;lt;math&amp;gt;4*2=8&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || &amp;lt;math&amp;gt;1*3=3&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || &amp;lt;math&amp;gt;2*4=8&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || &amp;lt;math&amp;gt;1*5=5&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || &amp;lt;math&amp;gt;5*2=10&amp;lt;/math&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Put into the probability-impact matrix:&lt;br /&gt;
[[File:LC-matrix ex1.png|300px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The prioritize list of risks is therefore:&lt;br /&gt;
* 5 - Sickness or injury&lt;br /&gt;
* 3 - Accidents&lt;br /&gt;
* 1 - Lack of bikes&lt;br /&gt;
* 4 - Lacking supplies&lt;br /&gt;
* 2 - Missing suppliers&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6308</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6308"/>
		<updated>2014-12-01T18:42:47Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk assessment */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve arranges a meeting with the three friend, to discuss possible risks. The group comes up with a lot of possible risks, by telling Steve about their business model and answering his &amp;quot;.. but what if..&amp;quot;-questions. Some of these are listed below:&lt;br /&gt;
&lt;br /&gt;
1. Bicycles are unusable due to wear, damage or theft. This would induce a serious impact on the business since they only have three bicycles and relies on mobility.&lt;br /&gt;
&lt;br /&gt;
2. The remaining suppliers does not sign a contract. Products will either not be available, leading to poorer service or more expensive deals will have to be struck to ensure the right products.&lt;br /&gt;
&lt;br /&gt;
3. Traffic accidents leading to sick days. Since the business revolves around bicycling in a busy city.&lt;br /&gt;
&lt;br /&gt;
4. Suppliers cannot meet demand. The decision to use high quality good, means that changes to increase supply quantities takes a long time to realize.&lt;br /&gt;
&lt;br /&gt;
5. Sickness or injuries. The business relies on that Adam, John and Fred are able to bike in any weather. Should any one of them be unable to work due to sickness or injuries the business will lose a third of it earnings.&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Following the example, Steve talks to the three friends about how likely they feel each risk is and what impact it could have.&lt;br /&gt;
All this, Steve puts into a matrix.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || The guys think that this might happen to some times during a season. || The bikes are easily replaced or repaired, but this is a bit expensive.&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || The guys believe that all contracts are sign before start-up, this is not likely. || This could prove to be a moderate set back.&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || The friends believe that this is not likely to happen, since they are all experienced cyclists || This will have a serious impact.&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || Adam, John and Fred does not think is likely to happen || However, should the business be out of stock it could take weeks to resupply, which will be a great loss of money.&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || It is believed that this is very likely to happen, since non of them are used to biking or being outside for 8 hours. || Serious illnesses and traffic accidents aside, this will only have a small impact since it is most likely to only infer a single sick day or two.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Steve determines the risk levels:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || 4 || 2&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || 1 || 3&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || 2 || 4&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || 1 || 5&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || 5 || 2&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
With the risk levels determined, Steve makes a risk assesment:&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk assesment&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || &amp;lt;math&amp;gt;4*2=8&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || &amp;lt;math&amp;gt;1*2=3&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || &amp;lt;math&amp;gt;2*4=9&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || &amp;lt;math&amp;gt;1*5=5&amp;lt;/math&amp;gt;&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || &amp;lt;math&amp;gt;5*2=10&amp;lt;/math&amp;gt;&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Put into the probability-impact matrix:&lt;br /&gt;
[[File:LC-matrix ex1.png|300px]]&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=File:LC-matrix_ex1.png&amp;diff=6303</id>
		<title>File:LC-matrix ex1.png</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=File:LC-matrix_ex1.png&amp;diff=6303"/>
		<updated>2014-12-01T18:40:58Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6290</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6290"/>
		<updated>2014-12-01T18:34:18Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve arranges a meeting with the three friend, to discuss possible risks. The group comes up with a lot of possible risks, by telling Steve about their business model and answering his &amp;quot;.. but what if..&amp;quot;-questions. Some of these are listed below:&lt;br /&gt;
&lt;br /&gt;
1. Bicycles are unusable due to wear, damage or theft. This would induce a serious impact on the business since they only have three bicycles and relies on mobility.&lt;br /&gt;
&lt;br /&gt;
2. The remaining suppliers does not sign a contract. Products will either not be available, leading to poorer service or more expensive deals will have to be struck to ensure the right products.&lt;br /&gt;
&lt;br /&gt;
3. Traffic accidents leading to sick days. Since the business revolves around bicycling in a busy city.&lt;br /&gt;
&lt;br /&gt;
4. Suppliers cannot meet demand. The decision to use high quality good, means that changes to increase supply quantities takes a long time to realize.&lt;br /&gt;
&lt;br /&gt;
5. Sickness or injuries. The business relies on that Adam, John and Fred are able to bike in any weather. Should any one of them be unable to work due to sickness or injuries the business will lose a third of it earnings.&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Following the example, Steve talks to the three friends about how likely they feel each risk is and what impact it could have.&lt;br /&gt;
All this, Steve puts into a matrix.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || The guys think that this might happen to some times during a season. || The bikes are easily replaced or repaired, but this is a bit expensive.&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || The guys believe that all contracts are sign before start-up, this is not likely. || This could prove to be a moderate set back.&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || The friends believe that this is not likely to happen, since they are all experienced cyclists || This will have a serious impact.&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || Adam, John and Fred does not think is likely to happen || However, should the business be out of stock it could take weeks to resupply, which will be a great loss of money.&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || It is believed that this is very likely to happen, since non of them are used to biking or being outside for 8 hours. || Serious illnesses and traffic accidents aside, this will only have a small impact since it is most likely to only infer a single sick day or two.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Steve determines the risk levels:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || 4 || 2&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || 1 || 3&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || 2 || 4&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || 1 || 5&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || 5 || 2&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6277</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6277"/>
		<updated>2014-12-01T18:25:25Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk analysis */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve arranges a meeting with the three friend, to discuss possible risks. The group comes up with a lot of possible risks, by telling Steve about their business model and answering his &amp;quot;.. but what if..&amp;quot;-questions. Some of these are listed below:&lt;br /&gt;
&lt;br /&gt;
1. Bicycles are unusable due to wear, damage or theft. This would induce a serious impact on the business since they only have three bicycles and relies on mobility.&lt;br /&gt;
&lt;br /&gt;
2. The remaining suppliers does not sign a contract. Products will either not be available, leading to poorer service or more expensive deals will have to be struck to ensure the right products.&lt;br /&gt;
&lt;br /&gt;
3. Traffic accidents leading to sick days. Since the business revolves around bicycling in a busy city.&lt;br /&gt;
&lt;br /&gt;
4. Suppliers cannot meet demand. The decision to use high quality good, means that changes to increase supply quantities takes a long time to realize.&lt;br /&gt;
&lt;br /&gt;
5. Sickness or injuries. The business relies on that Adam, John and Fred are able to bike in any weather. Should any one of them be unable to work due to sickness or injuries the business will lose a third of it earnings.&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Following the example, Steve talks to the three friends about how likely they feel each risk is and what impact it could have.&lt;br /&gt;
All this, Steve puts into a matrix.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || The guys think that this might happen to one of them once during a season. || This will reduce their income by a third per incapacitated bike per day, which is dangerous to the project.&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || The guys believe that all contracts are sign before start-up, this is not likely. || This could prove to be a moderate set back.&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || The friends believe that this is likely to happen || This would also infer a moderate impact.&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || Adam, John and Fred does not think is likely to happen || However, should the business be out of stock it could take weeks to resupply, which will be a great loss of money.&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || It is believed that this is very likely to happen, since non of them are used to biking or being outside for 8 hours. || Serious illnesses and traffic accidents aside, this will only have a small impact since it is most likely to only infer a single sick day or two.&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Steve determines the risk levels:&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Risk number&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 - Lack of bikes || 2 || 4&lt;br /&gt;
|-&lt;br /&gt;
| 2 - Missing suppliers || 1 || 3&lt;br /&gt;
|-&lt;br /&gt;
| 3 - Accidents || 3 || 3&lt;br /&gt;
|-&lt;br /&gt;
| 4 - Lacking supplies || 1 || 5&lt;br /&gt;
|-&lt;br /&gt;
| 5 - Sickness or injury || 5 || 2&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6245</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6245"/>
		<updated>2014-12-01T18:11:45Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve arranges a meeting with the three friend, to discuss possible risks. The group comes up with a lot of possible risks, by telling Steve about their business model and answering his &amp;quot;.. but what if..&amp;quot;-questions. Some of these are listed below:&lt;br /&gt;
&lt;br /&gt;
1. Bicycles are unusable due to wear, damage or theft. This would induce a serious impact on the business since they only have three bicycles and relies on mobility.&lt;br /&gt;
&lt;br /&gt;
2. The remaining suppliers does not sign a contract. Products will either not be available, leading to poorer service or more expensive deals will have to be struck to ensure the right products.&lt;br /&gt;
&lt;br /&gt;
3. Traffic accidents leading to sick days. Since the business revolves around bicycling in a busy city.&lt;br /&gt;
&lt;br /&gt;
4. Suppliers cannot meet demand. The decision to use high quality good, means that changes to increase supply quantities takes a long time to realize.&lt;br /&gt;
&lt;br /&gt;
5. Sickness or injuries. The business relies on that Adam, John and Fred are able to bike in any weather. Should any one of them be unable to work due to sickness or injuries the business will lose a third of it earnings.&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6230</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6230"/>
		<updated>2014-12-01T18:03:18Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve arranges a meeting with the three friend, to discuss possible risks. The group comes up with a lot of possible risks, by telling Steve about their business model and answering his &amp;quot;.. but what if..&amp;quot;-questions. Some of these are listed below:&lt;br /&gt;
&lt;br /&gt;
1. Bicycles are unusable due to wear, damage or theft. This would induce a serious impact on the business since they only have three bicycles and relies on mobility.&lt;br /&gt;
&lt;br /&gt;
2. The remaining suppliers does not sign a contract. Products will either not be available, leading to poorer service or more expensive deals will have to be struck to ensure the right products.&lt;br /&gt;
&lt;br /&gt;
3. Traffic accidents. Since the business revolves around bicycling in a busy city.&lt;br /&gt;
&lt;br /&gt;
4. Suppliers cannot meet demand. The decision to use high quality good, means that changes to increase supply quantities takes a long time to realize.&lt;br /&gt;
&lt;br /&gt;
5. Sickness or injuries. The business relies on that Adam, John and Fred are able to bike in any weather. Should any one of them be unable to work due to sickness or injuries the business will lose a third of it earnings.&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6225</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=6225"/>
		<updated>2014-12-01T17:59:04Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
Steve arranges a meeting with the three friend, to discuss possible risks. The group comes up with a lot of possible risks, by telling Steve about their business model and answering his &amp;quot;.. but what if..&amp;quot;-questions. Some of these are listed below:&lt;br /&gt;
&lt;br /&gt;
* Bicycles are unusable due to wear, damage or theft. This would induce a serious impact on the business since they only have three bicycles and relies on mobility.&lt;br /&gt;
&lt;br /&gt;
* The remaining suppliers does not sign a contract. Products will either not be available, leading to poorer service or more expensive deals will have to be struck to ensure the right products.&lt;br /&gt;
&lt;br /&gt;
* Traffic accidents. Since the business revolves around bicycling in a busy city.&lt;br /&gt;
&lt;br /&gt;
* Suppliers cannot meet demand. The decision to use high quality good, means that changes to increase supply quantities takes a long time to realize.&lt;br /&gt;
&lt;br /&gt;
* Sickness or injuries. The business relies on that Adam, John and Fred are able to bike in any weather. Should any one of them be unable to work due to sickness or injuries the business will lose a third of it earnings.&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=5988</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=5988"/>
		<updated>2014-12-01T15:36:31Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To get a better understanding of the different methods provided in this article, an example has been constructed to show how these are used.&lt;br /&gt;
The background for the examples are:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Example&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Three friends; Adam, John and Fred, wants to start a business together. Their goal is to sell high-quality fruit, pastry and beverage from specially made bicycles in the downtown area.&lt;br /&gt;
They already have contacts with some suppliers and have already purchased the bikes and other equipment for their trade.&lt;br /&gt;
During the winter, Fred&#039;s cousin, Steve, took a course in risk management and has now offered to help the three friends with their business.&lt;br /&gt;
This happens in the start of February and the business will launch medio April.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=5871</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=5871"/>
		<updated>2014-12-01T13:52:53Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk identification */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4813</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4813"/>
		<updated>2014-11-28T23:41:12Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
Put mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4812</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4812"/>
		<updated>2014-11-28T23:40:32Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have  little or no impact on the project there is little reason in prioritizing the mitigation of the problem. For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. Should a problem be moderately likely and serious, then the problem is a risk and should be handled. &lt;br /&gt;
The impact of a risk is however more severe than the probability. For instance are smaller impacts, which happen often, easier to accept than heavier impacts, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Talk:Risk_management_strategy&amp;diff=4811</id>
		<title>Talk:Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Talk:Risk_management_strategy&amp;diff=4811"/>
		<updated>2014-11-28T23:40:06Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Review from Xyz */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Review from Username111 ==&lt;br /&gt;
&lt;br /&gt;
First of all, it doesn&#039;t look like the article is complete yet. Therefore, I will only give a review based on the abstract, structure and the risk processing chapter (doesn&#039;t seem complete either but I&#039;ll use what is produced so far)  which is currently produced (November 25th 15:00). However, the topic seems interesting and very relevant for any project manager (or student within project management). It seems clear that the article is under in-depth method description category, due to each of the proposed chapters will have method descriptions.  &lt;br /&gt;
&lt;br /&gt;
I like the proposed structure of the article. I believe that it will create a good flow with a clear red thread. &lt;br /&gt;
&lt;br /&gt;
These are my specific questions and suggestions: &lt;br /&gt;
&lt;br /&gt;
* Maybe you could add a general example to each of the chapters. This could further strengthen the arguments of using the methods. E.g. you could give an example of an identified risk in &amp;quot;risk identification&amp;quot;, analyze this specific risk in &amp;quot;risk analysis&amp;quot;, assess the risk in &amp;quot;risk assessment&amp;quot;, and finally propose mitigation action for the risk in &amp;quot;risk processing&amp;quot;. This would give the reader a clear understanding of how to use the proposed methods in each of the chapters.  &lt;br /&gt;
* There seems to be a lack of proper referencing. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Should be fixed now.&lt;br /&gt;
** In the first sentence you reference to (Machiavelli, 1514), but there is no bibliography were I can find the actual article/journal/book.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Added&lt;br /&gt;
** In the second paragraph in the abstract there is a lot of interesting statements of risk management.  I guess most of them are not something you have created out of your own thoughts, and therefore they need referencing to the correct sources. E.g. the definition of risk: &amp;quot;&#039;&#039;A risk can be defined as the product of the probability of the risk and the impact of the risk&#039;&#039;&amp;quot; needs referencing. Maybe some of the statements are common sense for a project manager, but I would still suggest using some references to academic resources in order to improve the quality of the article. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Saying a risk is a product of probability and impact is just the short(and more accurate) way of saying: &amp;quot;A risk is when something might go wrong&amp;quot;. However finding were this was first used is too time consuming and of little consequence for the credibility of the article. I will therefor not try to find a reference, but thank you for the tip.&lt;br /&gt;
** Your dice example needs need a reference as well, unless you came up with it yourself of course. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; I am actually a habitual wargamer (warhammer 40000) where determining probability related to dice rolls is a major advantage. This is of my own creation.&lt;br /&gt;
* In the second paragraph you give two examples; when a problem is likely to happen but no impact, and when a problem is unlikely to happen and high impact. Maybe you could add a few more examples, in order to introduce scenarios were risk mitigation action is required.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Example added.&lt;br /&gt;
* You talk about &amp;quot;injuries&amp;quot; in relation to the impact of a given risk. I consider an injury something that can occur to an person. E.g. Bendtner sustained an injury after scoring his 6th goal. I would propose to use: consequence, damage, etc., since it often will be the impact in the project/company, not the person.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; injuries replaced with impacts&lt;br /&gt;
* This sentence is very hard to read: &amp;quot;&#039;&#039;If there is no certain way to determine a risk’s impact or probability or multiple risks are compared without having similar impact type (e.g. comparing human casualties against monetary loss) a qualitative approach can be used, where the risk is rated from e.g. 1-5.&#039;&#039;&amp;quot;. Please consider revising, in order to make it more understandable. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Sentence removed.   &lt;br /&gt;
* Since you already mention there are several other apppm wikis about risk management, you could use these as potential references, instead of just saying they might be similar.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Sentence removed.&lt;br /&gt;
* The risk processing chapter:  It seems like the chapter is not completely done. I would suggest to begin this chapter with describing the different methods/strategies (accept, mitigate, transfer, avoid, improve), and then follow by when you would use these different methods/strategies. Ideally you could give an example in the end of a risk that has been mitigated using one of the methods/strategies. Remember proper referencing for this chapter as well.  &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; The current layout was kept, but your idea was considered and actually implemented at first. However due to the flow of the article, I reverted back to the first layout, since I felt it gave a better flow.&lt;br /&gt;
&lt;br /&gt;
Other than these few comments, good job. Just fill in the chapters and make sure to use proper referencing, and the article will be great :)&lt;br /&gt;
&lt;br /&gt;
Good luck!&lt;br /&gt;
&lt;br /&gt;
== Review from Xyz ==&lt;br /&gt;
&lt;br /&gt;
You have chosen a very exiting topic and is a very good first outcast, but obviously it&#039;s not complete.&lt;br /&gt;
* The spelling, grammar and punctuation looks fine to me. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Thank you ;)&lt;br /&gt;
* The article is generally easy to understand, but some of the sentences are bit long and hard to follow. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Sorry about that. I&#039;ll try to cut down on my sentences.&lt;br /&gt;
* There are so fare no figures. It would be easier to understand the main points, if there were a few figures. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Figures added.&lt;br /&gt;
* I find the topic very interesting and relevant, and i think any person within project management would to.&lt;br /&gt;
* To me it seams like article belongs to the method description category.&lt;br /&gt;
* I think there will be a nice flow through out the article, when it is finished. &lt;br /&gt;
* It would be nice to finish the article with a short summery/conclusion.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Added.&lt;br /&gt;
* It might be a good idea to have some more solid references.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Added.&lt;br /&gt;
&lt;br /&gt;
-Good luck.&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Talk:Risk_management_strategy&amp;diff=4810</id>
		<title>Talk:Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Talk:Risk_management_strategy&amp;diff=4810"/>
		<updated>2014-11-28T23:29:56Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Review from Username111 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Review from Username111 ==&lt;br /&gt;
&lt;br /&gt;
First of all, it doesn&#039;t look like the article is complete yet. Therefore, I will only give a review based on the abstract, structure and the risk processing chapter (doesn&#039;t seem complete either but I&#039;ll use what is produced so far)  which is currently produced (November 25th 15:00). However, the topic seems interesting and very relevant for any project manager (or student within project management). It seems clear that the article is under in-depth method description category, due to each of the proposed chapters will have method descriptions.  &lt;br /&gt;
&lt;br /&gt;
I like the proposed structure of the article. I believe that it will create a good flow with a clear red thread. &lt;br /&gt;
&lt;br /&gt;
These are my specific questions and suggestions: &lt;br /&gt;
&lt;br /&gt;
* Maybe you could add a general example to each of the chapters. This could further strengthen the arguments of using the methods. E.g. you could give an example of an identified risk in &amp;quot;risk identification&amp;quot;, analyze this specific risk in &amp;quot;risk analysis&amp;quot;, assess the risk in &amp;quot;risk assessment&amp;quot;, and finally propose mitigation action for the risk in &amp;quot;risk processing&amp;quot;. This would give the reader a clear understanding of how to use the proposed methods in each of the chapters.  &lt;br /&gt;
* There seems to be a lack of proper referencing. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Should be fixed now.&lt;br /&gt;
** In the first sentence you reference to (Machiavelli, 1514), but there is no bibliography were I can find the actual article/journal/book.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Added&lt;br /&gt;
** In the second paragraph in the abstract there is a lot of interesting statements of risk management.  I guess most of them are not something you have created out of your own thoughts, and therefore they need referencing to the correct sources. E.g. the definition of risk: &amp;quot;&#039;&#039;A risk can be defined as the product of the probability of the risk and the impact of the risk&#039;&#039;&amp;quot; needs referencing. Maybe some of the statements are common sense for a project manager, but I would still suggest using some references to academic resources in order to improve the quality of the article. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Saying a risk is a product of probability and impact is just the short(and more accurate) way of saying: &amp;quot;A risk is when something might go wrong&amp;quot;. However finding were this was first used is too time consuming and of little consequence for the credibility of the article. I will therefor not try to find a reference, but thank you for the tip.&lt;br /&gt;
** Your dice example needs need a reference as well, unless you came up with it yourself of course. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; I am actually a habitual wargamer (warhammer 40000) where determining probability related to dice rolls is a major advantage. This is of my own creation.&lt;br /&gt;
* In the second paragraph you give two examples; when a problem is likely to happen but no impact, and when a problem is unlikely to happen and high impact. Maybe you could add a few more examples, in order to introduce scenarios were risk mitigation action is required.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Example added.&lt;br /&gt;
* You talk about &amp;quot;injuries&amp;quot; in relation to the impact of a given risk. I consider an injury something that can occur to an person. E.g. Bendtner sustained an injury after scoring his 6th goal. I would propose to use: consequence, damage, etc., since it often will be the impact in the project/company, not the person.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; injuries replaced with impacts&lt;br /&gt;
* This sentence is very hard to read: &amp;quot;&#039;&#039;If there is no certain way to determine a risk’s impact or probability or multiple risks are compared without having similar impact type (e.g. comparing human casualties against monetary loss) a qualitative approach can be used, where the risk is rated from e.g. 1-5.&#039;&#039;&amp;quot;. Please consider revising, in order to make it more understandable. &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Sentence removed.   &lt;br /&gt;
* Since you already mention there are several other apppm wikis about risk management, you could use these as potential references, instead of just saying they might be similar.&lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; Sentence removed.&lt;br /&gt;
* The risk processing chapter:  It seems like the chapter is not completely done. I would suggest to begin this chapter with describing the different methods/strategies (accept, mitigate, transfer, avoid, improve), and then follow by when you would use these different methods/strategies. Ideally you could give an example in the end of a risk that has been mitigated using one of the methods/strategies. Remember proper referencing for this chapter as well.  &lt;br /&gt;
&#039;&#039;&#039;(MartinKruck reply)&#039;&#039;&#039; The current layout was kept, but your idea was considered and actually implemented at first. However due to the flow of the article, I reverted back to the first layout, since I felt it gave a better flow.&lt;br /&gt;
&lt;br /&gt;
Other than these few comments, good job. Just fill in the chapters and make sure to use proper referencing, and the article will be great :)&lt;br /&gt;
&lt;br /&gt;
Good luck!&lt;br /&gt;
&lt;br /&gt;
== Review from Xyz ==&lt;br /&gt;
&lt;br /&gt;
You have chosen a very exiting topic and is a very good first outcast, but obviously it&#039;s not complete.&lt;br /&gt;
* The spelling, grammar and punctuation looks fine to me. &lt;br /&gt;
* The article is generally easy to understand, but some of the sentences are bit long and hard to follow. &lt;br /&gt;
* There are so fare no figures. It would be easier to understand the main points, if there were a few figures. &lt;br /&gt;
* I find the topic very interesting and relevant, and i think any person within project management would to.&lt;br /&gt;
* To me it seams like article belongs to the method description category.&lt;br /&gt;
* I think there will be a nice flow through out the article, when it is finished. &lt;br /&gt;
* It would be nice to finish the article with a short summery/conclusion.&lt;br /&gt;
* It might be a good idea to have some more solid references.&lt;br /&gt;
&lt;br /&gt;
-Good luck.&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4809</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4809"/>
		<updated>2014-11-28T23:08:45Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[File:ISO 31000-2009 risk management strategy.JPG|thumb|300px|Risk management strategy as defined be ISO 31000:2009&amp;lt;ref&amp;gt;[ISO 31000:2009]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=File:ISO_31000-2009_risk_management_strategy.JPG&amp;diff=4808</id>
		<title>File:ISO 31000-2009 risk management strategy.JPG</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=File:ISO_31000-2009_risk_management_strategy.JPG&amp;diff=4808"/>
		<updated>2014-11-28T23:06:25Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: Risk management strategy as defined by ISO 31000:2009&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Risk management strategy as defined by ISO 31000:2009&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4807</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4807"/>
		<updated>2014-11-28T23:03:59Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Probability rating */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. &lt;br /&gt;
&lt;br /&gt;
Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4806</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4806"/>
		<updated>2014-11-28T23:02:52Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk process responses */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Research/nurtur the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4805</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4805"/>
		<updated>2014-11-28T23:01:57Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Conclusion */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For  a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
Risk management is an important tool to use, if a successful project is to be achieved.&lt;br /&gt;
Risk management should be implemented as early as possible in the process as possible, but does also require recurring follow-ups to ascertain:&lt;br /&gt;
*The analysed levels of each risk relates to the current state.&lt;br /&gt;
*The effectiveness of the risk response is adequate.&lt;br /&gt;
*Newly arisen risks are handled.&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4804</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4804"/>
		<updated>2014-11-28T22:52:14Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk Monitoring */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For  a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
With the risk processing is done, the first iteration can be considered concluded.&lt;br /&gt;
It is however important to keep monitoring the identified risks and be mindful of need risks which may arise during a project.&lt;br /&gt;
When ever a new risk arises it should be sent through the same analysis as the previously determined risks.&lt;br /&gt;
&lt;br /&gt;
This will decrease the likelihood of negative impacts on the project, thus encourage a more successful project.&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4803</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4803"/>
		<updated>2014-11-28T22:46:40Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk process responses */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For  a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4802</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4802"/>
		<updated>2014-11-28T22:46:18Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk processing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
===Risk processing using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
===Risk processing without using the probability-impact matrix===&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
===Risk process responses===&lt;br /&gt;
&lt;br /&gt;
Below is a list of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For  a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4801</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4801"/>
		<updated>2014-11-28T22:44:48Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk processing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. &lt;br /&gt;
&lt;br /&gt;
However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Below is a list of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For  a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4800</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4800"/>
		<updated>2014-11-28T22:44:32Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk processing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
&lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Below is a list of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For  a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4799</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4799"/>
		<updated>2014-11-28T22:44:14Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk processing */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do about them.&lt;br /&gt;
This depends on the previously made risk assessment. &lt;br /&gt;
Any risks in the red area of the matrix should be &#039;&#039;&#039;avoided&#039;&#039;&#039;.&lt;br /&gt;
Any risk in the the yellow area should be either &#039;&#039;&#039;mitigated, transferred or researched/nurtured&#039;&#039;&#039; depending on the malignancy and probability of the risk.&lt;br /&gt;
Any risk in the green area should most likely be &#039;&#039;&#039;accepted&#039;&#039;&#039;. However some of the green risks could be yellow, depending on their uncertainty level.&lt;br /&gt;
&lt;br /&gt;
If the probability-Impact matrix was not used the following method can be used to determine a risk response:&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Below is a list of responses and possible solutions to use depending on the probability and impact of the risk. &lt;br /&gt;
The list is only a framework. For  a defined risk, the actual solution can be found within these frames.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accept the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4725</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4725"/>
		<updated>2014-11-28T15:20:15Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* The risk matrix */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039; trade-off between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4723</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4723"/>
		<updated>2014-11-28T15:19:56Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk assessment */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039;s tradeoff between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4722</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4722"/>
		<updated>2014-11-28T15:19:35Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk assessment */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
=== The risk matrix ===&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
Considerations should be taken when using the matrix, since it has its limitations&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;:&lt;br /&gt;
*The matrix does not consider interactions between two or more risks.&lt;br /&gt;
*The matrix does not map uncertainties.&lt;br /&gt;
*The matrix&#039;s tradeoff between likelihood and consequences is fixed and might not suit all projects.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4707</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4707"/>
		<updated>2014-11-28T14:50:37Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk assessment */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of two risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4705</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4705"/>
		<updated>2014-11-28T14:49:21Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk assessment */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of to risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4703</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4703"/>
		<updated>2014-11-28T14:48:40Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk assessment */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix for risk assessment&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
With the identified risks analysed it is possible to assess them and find the most serious risk.&lt;br /&gt;
To get an overview it can be helpful to multiply the impact of the risk with its associated probability. &lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*Probability&amp;lt;/math&amp;gt;&lt;br /&gt;
If the rating system proposed earlier is used, the risks will be arranged from 1 to 25, with severity increasing with the product.&lt;br /&gt;
This is the most basic form of risk assessment.&lt;br /&gt;
&lt;br /&gt;
When dealing with risks it is normal to prefer several smaller risks rather than one serious risk. This means that the impact of a risk is a little heavier than the probability, which should be taken into account when doing a risk assessment.&lt;br /&gt;
To help classifying the risks a matrix has been produced to the right.&lt;br /&gt;
Each risk can be plotted into this matrix, where the color code tells the severity of the risk, with red being the most dangerous risks and green the most harmless.&lt;br /&gt;
&lt;br /&gt;
Prioritization of the risk should then be carried out within each color-set using the previously defined method to determine the risk&#039;s severity. Should two risks have the same severity, the risk with the highest impact rating will be prioritized before the other. When the impact of to risks are the same, they will receive the same level of prioritization.&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4527</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4527"/>
		<updated>2014-11-28T00:29:18Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Uncertainty rating */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk, the risk can be assessed. However it would be wise to consider the uncertainty of the analysis. This can be done by using the table below&amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
If a &amp;quot;Yes&amp;quot; is the answer to any of the above mentioned questions, then the risk faces certain uncertainties. These uncertainties should be rated in a manner fitting to group doing the risk analysis.&lt;br /&gt;
An example might be:&lt;br /&gt;
*The risk&#039;s uncertainty is marked Red if two or more questions have gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Yellow if one question has gotten a &amp;quot;Yes&amp;quot;.&lt;br /&gt;
*The risk&#039;s uncertainty is marked Green&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4523</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4523"/>
		<updated>2014-11-28T00:16:51Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4522</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4522"/>
		<updated>2014-11-28T00:16:17Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Impact rating */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defense &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones with no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize success. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize success || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4521</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4521"/>
		<updated>2014-11-28T00:15:08Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk analysis */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
===Probability rating===&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Note that a probability of 0% is not possible, since that would mean that the event &#039;&#039;&#039;will not&#039;&#039;&#039; happen. Likewise is a probability of 100% neither possible, since that would mean that the event &#039;&#039;&#039;will&#039;&#039;&#039; happen.&lt;br /&gt;
&lt;br /&gt;
===Impact rating===&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
The difference between impact rating and probability rating is that, the impact rating tries to embrace consequences regarding human health, expenses and delays and compare these different subjects. Therefore is a standardized method of determining level of impact useful.&lt;br /&gt;
Like probability the rating can be based on experience, common sense or actual numbers.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
===Uncertainty rating===&lt;br /&gt;
When the probability and impact is determined for a risk&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4520</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4520"/>
		<updated>2014-11-28T00:01:10Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Definition of Risk */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definitions ==&lt;br /&gt;
&lt;br /&gt;
===Risk===&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
But mathematically:&lt;br /&gt;
&amp;lt;math&amp;gt;Risk=Impact*probability&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Probability===&lt;br /&gt;
The probability of a risk is the estimated likelihood of a certain event happening.&lt;br /&gt;
&lt;br /&gt;
===Impact===&lt;br /&gt;
The impact is the consequences a risk may have on a project. The impact can include: Personal injury, monetary loss, delays, ect.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4519</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4519"/>
		<updated>2014-11-27T23:56:33Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk analysis */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definition of Risk ==&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis. This analysis determines each risk&#039;s probability and impact.&lt;br /&gt;
&lt;br /&gt;
I can be very tricky to determine the exact probability of a given risk and knowing the probability might increase the complexity of the following risk assessment.&lt;br /&gt;
A standardized way to rate probability is by using the table below. Whether the rating is based on experience, common sense or actual facts does not matter at this step.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
Like determining the level of probability of a risk, the level of impact is equally as tricky to determine. There for a rating scale has been presented below.&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4517</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4517"/>
		<updated>2014-11-27T23:42:33Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definition of Risk ==&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4515</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4515"/>
		<updated>2014-11-27T23:34:11Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definition of Risk ==&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis.&lt;br /&gt;
&lt;br /&gt;
Remember ref&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
== Risk Monitoring ==&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4514</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4514"/>
		<updated>2014-11-27T23:32:59Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definition of Risk ==&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis.&lt;br /&gt;
&lt;br /&gt;
Remember ref&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4513</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4513"/>
		<updated>2014-11-27T23:30:44Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Identification methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To help understanding the risk management processes a example has been made to illustrate each chapters subject.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definition of Risk ==&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;/ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis.&lt;br /&gt;
&lt;br /&gt;
Remember ref&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4512</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4512"/>
		<updated>2014-11-27T23:30:19Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To help understanding the risk management processes a example has been made to illustrate each chapters subject.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definition of Risk ==&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;ref/&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis.&lt;br /&gt;
&lt;br /&gt;
Remember ref&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:LC-matrix.png|thumb|300px|The probability-impact matrix&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt;]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4511</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4511"/>
		<updated>2014-11-27T23:25:47Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk assessment */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To help understanding the risk management processes a example has been made to illustrate each chapters subject.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definition of Risk ==&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;ref/&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis.&lt;br /&gt;
&lt;br /&gt;
Remember ref&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:LC-matrix.png||300px|thumb|left|The probability-impact matrix ]]&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4509</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4509"/>
		<updated>2014-11-27T23:20:35Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Risk assessment */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To help understanding the risk management processes a example has been made to illustrate each chapters subject.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definition of Risk ==&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;ref/&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis.&lt;br /&gt;
&lt;br /&gt;
Remember ref&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:LC-matrix.png]]&lt;br /&gt;
&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4508</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4508"/>
		<updated>2014-11-27T23:19:40Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Identification methods */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To help understanding the risk management processes a example has been made to illustrate each chapters subject.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definition of Risk ==&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;ref/&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;/ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis.&lt;br /&gt;
&lt;br /&gt;
Remember ref&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
	<entry>
		<id>http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4507</id>
		<title>Risk management strategy</title>
		<link rel="alternate" type="text/html" href="http://13.50.150.85/index.php?title=Risk_management_strategy&amp;diff=4507"/>
		<updated>2014-11-27T23:19:15Z</updated>

		<summary type="html">&lt;p&gt;MartinKruck: /* Definition of Risk */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;“When trouble is sensed well in advance in can be easily remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable. As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after time… it becomes easy to diagnose but difficult to cure.” (Machiavelli, 1514) &amp;lt;ref&amp;gt;[Niccolo Machiavelli “The Prince”]&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
When dealing with a project, uncertainties are to be expected, whether the project is influenced by external or internal factors. If an unexpected event turns out to be harmful to the project it is in general terms considered to be a risk.  &lt;br /&gt;
A risk can be defined as the product of the probability of the risk and the impact of the risk. Should a problem be very likely to happen, but have a little or no impact on the project there is little reason in prioritizing the mitigation of the problem. &lt;br /&gt;
For a problem having a high impact, but very low probability the need to mitigate this problem is likewise not a priority. The impact of a risk is however more severe than the probability. For instance are smaller injuries, which happen often, easier to accept than heavier injuries, which happen more seldom. &lt;br /&gt;
The probability of a problem should however not be neglected. A common way to illustrated this is by playing a small game:&lt;br /&gt;
&lt;br /&gt;
In the construction business many factors must by in order for the project to move forward. Six people are given a dice and a problem. Whenever a person rolls a 1 a problem has occurred which delays the project. Thus the probability of a problem happening is 1/6. The probability of no problem happening is:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;math&amp;gt;5/6*5/6*5/6*5/6*5/6*5/6=(5/6)^6=0,33&amp;lt;/math&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This means that only a third of the time, the project will progress.&lt;br /&gt;
&lt;br /&gt;
A useful risk management strategy comprises of the following steps:&lt;br /&gt;
*&#039;&#039;&#039;Identify&#039;&#039;&#039; - Potential risks are identified.&lt;br /&gt;
*&#039;&#039;&#039;Analyze&#039;&#039;&#039; - Identified risks are rated, related to probability and impact.&lt;br /&gt;
*&#039;&#039;&#039;Assess&#039;&#039;&#039; - Analyzed risks are ranked and compared to each other to determine which risk to handle first.&lt;br /&gt;
*&#039;&#039;&#039;Process&#039;&#039;&#039; - Solutions are found to counter effect the risks.&lt;br /&gt;
*&#039;&#039;&#039;Monitor&#039;&#039;&#039; - During the project lifetime, identified risks are monitored and new, potential risks are identified.&lt;br /&gt;
&lt;br /&gt;
This article will examine ways to do a successful risk management.&lt;br /&gt;
&lt;br /&gt;
To help understanding the risk management processes a example has been made to illustrate each chapters subject.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Definition of Risk ==&lt;br /&gt;
PMBOK defines a risk as:&lt;br /&gt;
&amp;quot;An uncertain event or condition that, if it occurs has a positive or negative impact on one or more project objectives such as scope, schedule, cost and quality&amp;quot; &amp;lt;ref&amp;gt;[&amp;quot;A Guide to the Project Management Body of Knowledge ( PMBOK® Guide )—Fifth Edition&amp;quot;]&amp;lt;/ref&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
== Risk identification ==&lt;br /&gt;
&lt;br /&gt;
During the risk identification, a project is scrutinized for potential risks. During the scrutinisation experience is a good asset when determining the potential risks, but other methods do however exists.&lt;br /&gt;
Risk identification is the simplest of the risk management steps, since it only requires the project group to think of possible threads and opportunities. Risk identification is however the most important step and should be repeated iterativly during the project lifetime to ensure the safety of the project.&lt;br /&gt;
&lt;br /&gt;
=== Identification methods ===&lt;br /&gt;
&lt;br /&gt;
Instead of relying on experience and common sense, when determining the possible risks, taxonomy-facilitated brainstorming &amp;lt;ref&amp;gt;[NASA &amp;quot;NASA Risk management handbook&amp;quot;]&amp;lt;ref&amp;gt; could be used.&lt;br /&gt;
Brainstorming techniques includes:&lt;br /&gt;
* Check-lists&lt;br /&gt;
* [[What-if analysis]]&lt;br /&gt;
* [[Failure mode and effect analysis]] (FMEA)&lt;br /&gt;
* [[Hazard and operability studies]] (HAZOP)&lt;br /&gt;
These exercises should help the brainstorming and thought processes to identify risks.&lt;br /&gt;
&lt;br /&gt;
Another method&amp;lt;ref&amp;gt;[Department of Defence &amp;quot;Risk management guide for DOD acquisition]&amp;lt;ref&amp;gt; is to ask &amp;quot;What could go wrong?&amp;quot;, and answer it when relating to the following subjects:&lt;br /&gt;
* Current and proposed staffing, design, process, resources, suppliers, dependencies, operational employment, ect.&lt;br /&gt;
* Monitoring test results&lt;br /&gt;
* Reviewing shortfalls against expectations&lt;br /&gt;
* Analyzing negative trends&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk analysis ==&lt;br /&gt;
&lt;br /&gt;
With the risks identified it is now possible to do a risk analysis.&lt;br /&gt;
&lt;br /&gt;
Remember ref&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Uncertainty factor&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Associated question to be answered&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| Uniqueness || Is this risk issue unique or new compared to risks that have occurred in other  projects?&lt;br /&gt;
|-&lt;br /&gt;
| Cross-cutting Character || Does this risk issue affect a large number of functions, hardware elements, software elements, or procedures and/or have the potential to cross organizational lines?&lt;br /&gt;
|-&lt;br /&gt;
| Complexity || Does this risk issue involve complex interactions between or among hardware elements, software elements, organizations, and/or individuals?&lt;br /&gt;
|-&lt;br /&gt;
| Propagation Potential || Could this risk issue lead to a propagation of events that could result in more severe consequences than the immediate events caused by the risk?&lt;br /&gt;
|-&lt;br /&gt;
| Detectability || Is there anything that inhibits the ability to detect the full extent of the risk and track its progress?&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Likelihood&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Probability&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Not likely || ~10%&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Low likelyhood || ~30%&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Likely || ~50%&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Highly likely || ~70%&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Near certainty || ~90%&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
{| class=&amp;quot;wikitable collapsible&amp;quot;&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Impact level&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Technical performance&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Schedule&lt;br /&gt;
! style=&amp;quot;background:#d0e5f5&amp;quot; | Cost&lt;br /&gt;
|-valign=&amp;quot;top&amp;quot; &lt;br /&gt;
| 1 || Minimal or no consequence to performance || Minimal or no impact || Minimal or no impact&lt;br /&gt;
|-&lt;br /&gt;
| 2 || Minor reduction in performance or supportability  || Able to meet key dates || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;1% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 3 || Moderate reduction in performance or supportability with limited impact in objectives.|| Minor schedule slip. Able to meet key milestones woth no schedule float. || Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;5% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 4 || Significant degradation in performance or major shortfall in supportability. May jeopardize succes. || Critical path affected ||Budget or unit production cost increases. &#039;&#039;&#039;&amp;lt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
| 5 || Severe degradation in performance. Will jeopardize succes || Cannot meet key milestones ||Exceeds threshold &#039;&#039;&#039;&amp;gt;10% of budget&#039;&#039;&#039;&lt;br /&gt;
|-&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Risk assessment ==&lt;br /&gt;
Methods to assess identified risks.&lt;br /&gt;
== Risk processing ==&lt;br /&gt;
Methods for mitigating an identified risk&lt;br /&gt;
&lt;br /&gt;
When the risks have been determined and assessed, it will be natural to determine what to do. Below is a list of responses and possible solutions to use depending on the probability and impact of the risk.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Accepting the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Whether the risk is harmful or not, if the probability is low there is no need for doing anything to mitigate it. The occurrence of the event opposed to price of mitigating it will mostly be always turn out to too expensive.&lt;br /&gt;
Should a benign risk with a high impact and high probability be determined for a project, then this too should also be accepted, since it is very likely to happen.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Mitigating the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Malignant risks with low impact, but a frequent occurrence should be mitigated. This is done by making contingency plans, investing in safety equipment and other actions which can lower the probability and/or impact.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Transfer the risk&#039;&#039;&#039;&lt;br /&gt;
For malignant risks, with a low probability, but high impact, the most reasonably course would be to transfer the risk to someone else. This can be done by outsourcing the risky parts or by buying insurance in case the risk happens.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Avoid the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Should a risk be harmfully serious and very likely too happen, no insurance company will help. These occurrences should be avoided at all cost. This can be done in numerous ways depending on the risk. The safest way to avoid the risk is to change the part of the project which is in danger. If this is not possible, then the project should either be canceled or delayed until the risk no longer is probability or impact has lessened.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Researching/nurturing the risk&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
In the rare cases where a benign risk will have a major impact on a project, but not likely to happen, the risk should be further researched, leading to ways to improve the likelihood. It goes without saying that the cost of implementation should not be larger than the potential gains. If the research proved fruitful the risk should be nurtured to a more probable level.&lt;br /&gt;
&lt;br /&gt;
Harmful risk - responses:&lt;br /&gt;
&lt;br /&gt;
* Avoid: For high probability, high impact&lt;br /&gt;
* Transfer: For low probability, high impact&lt;br /&gt;
* Mitigate: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
Useful risk – responses:&lt;br /&gt;
&lt;br /&gt;
* Accept: For high probability, high impact&lt;br /&gt;
* Research: For low probability, high impact&lt;br /&gt;
* Accept: For high probability, low impact&lt;br /&gt;
* Accept: For low probability, low impact&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Example: ===&lt;br /&gt;
&amp;lt;div class=&amp;quot;mw-collapsible&amp;quot;&amp;gt;&lt;br /&gt;
Hidden text&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Conclusion ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= References =&lt;br /&gt;
&amp;lt;References/&amp;gt;&lt;/div&gt;</summary>
		<author><name>MartinKruck</name></author>
	</entry>
</feed>