Instructional design/WBT risks/Step 1: Identify Potential Project Risks
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
Brainstorming Session
[edit | edit source]As you learned in the previous section, the first step in the risk planning process is to identify all potential project risks. Risk identification takes place in the first part of the risk planning meeting via a brainstorming session. As Andrew Stellman and Jennifer Greene explain in Applied Software Project Management, “Brainstorming should be reminiscent of microwave popcorn: a few ideas should ‘pop’ at first, followed by a large number being fired rapidly, slowing down to a final few ‘pops.’” Once the ideas stop “popping,” you will know it’s time to move on to the next step in the risk planning process. During the brainstorming session, someone from the development team should record all of the risks mentioned in the first column of the risk plan. Keep in mind that the goal of the first step is to uncover as many potential risks as possible, therefore, the recorder should document the risks in the order they were shared and not try to prioritize them.
Risks Should Focus on Events
[edit | edit source]Good risks are specific and focused on events. During the brainstorming session, team members may tend to focus on project objectives such as “the final delivery might be delayed” when they need to focus on events that could impact the project objectives. As the Project Manager, make it clear at the start of the brainstorming session that risks should be event-based and as specific as possible.
If team members suggest risks like “the final delivery might be delayed”, ask clarifying questions such as “What could cause the final delivery to be delayed?” until you uncover a specific risk. If the project risks aren’t specific and event-based, it will be difficult (if not impossible) to prioritize them in step 2 and develop effective mitigation strategies in step 3.
Brainstorming Aids
[edit | edit source]If your development team has little experience in risk identification, here are two things you can do to facilitate the brainstorming process.
Revisit Past Projects
[edit | edit source]Similar projects have similar risks. Before the brainstorming session, review relevant documents from past WBT projects such as risk plans and lessons learned. If possible, speak to the Project Manager and ask him/her about the major lessons learned from that specific project. Be prepared to share what you uncover during the brainstorming session. You may be able to reuse many of these risks and they could help your team think of new risks that wouldn’t have been uncovered otherwise.
Consider Different Risk Categories
[edit | edit source]During the brainstorming session, it can be useful to consider potential risks in terms of categories. This encourages everyone involved in risk identification to keep an open mind and to consider a wide range of risks. For WBT projects, you may want to use the following categories to identify risks:
- Technical - Risks in this category relate to technical requirements, technology and tools, usability, performance and reliability, and overall quality issues.
- External - This would include risks related to subcontractors, the customer, the weather, etc.
- Organizational - This would include risks within your own organization such as resource allocation, funding issues, and prioritization.
- Project Management - This would include risks related to project estimating, planning, controlling, and communicating.
Risk Examples
[edit | edit source]The following table presents examples of specific, event-based risks for each of the four risk categories.
| Technical | External | Organizational | Project Management |
|---|---|---|---|
| Disruption of Internet services prevents team from working. | Voice talent gets sick and has to miss recording sessions. | Director of Training Development Group is promoted. | The client requests content changes after the storyboard review. |
| Multimedia Developer's hard drive crashes. | Snow storm prevents participants from attending course pilot. | Key resources are asked to work on a large proposal. | Client does not like the course “look and feel”. |
| Target audience finds the course's user interface confusing. | Course SME is replaced and new SME makes drastic changes to the content. | Senior Instructional Designer is also managing the project. | Development team underestimates the time needed for quality assurance testing. |
| Final WBT course is slow to load in client's LMS. | Subcontractor misses video production deadline. | Multimedia Developer is assigned to three different projects. | Client is extremely busy and does not respond to emails, phone calls, and meeting requests in a timely manner. |
Here are some examples of risks that should be more specific or more focused on events.
| Technical | External | Organizational | Project Management |
|---|---|---|---|
| The client rejects the final product. | The course pilot is canceled. | The Multimedia Developer doesn’t complete work on time. | The client rejects the final product. |
Notice that in the second table, “the client rejects the final product” is so vague that it could be either a Technical or Project Management risk. For example, the client may reject the final product because it doesn’t meet key technical requirements (Technical) or because it was delivered three months late (Project Management). The only way to uncover the actual risk is to ask, "What would cause the client to reject the final product?"
Click Next to continue.
| Instructional Design: Homepage | < Back | Next > |