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
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
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
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
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
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
The following table presents examples of specific, event-based risks for each of the four risk categories.

Here are some examples of risks that should be more specific or more focused on events.

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.