A SIMPLE PROCEDURE FOR RISK MANAGEMENT
This simple procedure is intended for a project developing a software product, possibly including specialized hardware. The procedure is intended for use during the start of the project in order to identify serious risks and prepare for them.
After this procedure has been run through, risks should be monitored as part of the follow-up of project progress.
1 Identify risks
Exercise with Post-It notes: Everyone write down their candidate risks. Consider technical risks, project risks, risks with partners, and business risks.
Thereafter, combine the risks which are the same. Use a checklist to ensure that you have thought of everything. Filter away everything that can be taken care of immediately. Put those items in a special action list, and assign a responsible for each.
2. Evaluate the probabilities
For each risk, discuss and agree about a probability between 0 and 1. Thereafter, compare the probabilities for all risks, and check that they are reasonable in relation to each other.
3. Judge the consequences
For each risk, discuss and agree about an ranking of its consequences. Use a value between 1 and 5, where 5 is the most serious consequence. Then, compare the values for all risks, and modify if needed. If the consequence of risk A is twice as serious as that of risk B, its ranking shall be double.
4. Order the risks
Give each risk a total ranking by multiplying the risk with the consequence. List the risks in descending total ranking. Verify that this ranking is reasonable. Ask: "Is really risk A ten times as bad as risk B?"
Delete the least seious risks. "We'll take care of those if they happen." Discuss and agree about where to draw the line between such risks and the others.
6. Risk management
For each remaining risk, discuss and agree about either
1. how to avoid the risk, or
2. what to do if it actually occurs.
Document the result.
1. Requirements not available in time
2. Misunderstood requirements
3. Hardware not available for production
4. Hardware not available for software development
5. Third party components of too low quality
6. Development tools not available in time
7. Quality problems with development tools
1. Too low estimate of the need for calendar time
2. Too low estimate of work amount
3. Insufficient staffing
4. Loss of staff
5. Lacking competences
6. Many errors found during final testing
1. Partner late with development work
2. Problems with outsourcing of production
3. Delay in finalizing contract
1. A competitor releases a similar product
2. The production cost shows up too high
3. The market window disappears
4. The business idea fails