Instructional design/WBT risks/Step 3: Make a Mitigation Plan

Instructional Design: Homepage > Identifying WBT Risks >  Risky Business >  Step 1: Identify >  Your Turn - Risk Identification >  Step 2: Prioritize >  Your Turn - Risk Prioritization > Step 3: Mitigate >  Your Turn - Risk Mitigation >  The Risk Plan >  Lesson Conclusion

Risk Mitigation
The third and final step in the Risk Planning process is risk mitigation. You now have a list of project risks that have been prioritized based on their probability and impact. You and your development team will devote the remainder of the risk planning meeting to identifying ways to mitigate these risks. As the Project Manager, you will lead this discussion, beginning with the highest-priority risk in your risk plan. Generally, you will identify several different mitigation strategies for high-priority risks and as you move down the list to low-priority items, you’ll find that you need fewer strategies. Your lowest-priority risk may not need any mitigation strategies. Take another look at the sample risk plan that was presented at the start of this lesson to see how this works.

Risk plan for project – Sexual Harassment Awareness WBT Course

Assessment team members – John, Julie, Simone, and Nathan

Risk Mitigation Strategies
To mitigate a risk, the development team may decide to alter the project plan, add additional tasks, or plan for risks.

Alter the Project Plan
You may decide to adjust the project schedule to mitigate a risk. You can either have a task begin earlier in the course development process or you can increase the amount of time allocated for a specific task. For example, in the sample risk plan, the development team mitigated the second risk by scheduling the recording sessions early in the development process.

Add Additional Tasks
Risks can also be mitigated by adding additional tasks to the project schedule. This will increase the project’s total level of effort, but it may be worth it for particularly risky tasks. For example, the third risk in the sample risk plan can be avoided by having the client approve a course prototype before development begins. In this case, a slight increase in the initial level of effort may prevent a whole lot of rework later on.

Plan for Risks
Finally, for risks that have a high impact but don’t require specific changes to the project schedule, you should still document how the team will respond if the risk occurs. In the sample risk plan, there are no Actions listed for disruption of Internet services because it’s a very low-priority risk for the development team. However, if the team changed its mind and wanted to develop a mitigation strategy, there wouldn’t be any practical changes that could be made to the schedule. Instead, the development team could add an Action like “If this occurs, the team will wait 30 minutes to see if Internet services resume. After 30 minutes, team members will go home and work remotely for the rest of the day.” Having a plan in place will prevent team members from panicking or wasting time wondering what they should do.

Click Next to continue.