Task I.3 Assess the technology/business risk
I.3.1 Identify technology/business risks associated with concept scope.
Intent: The intent of this task is to perform a formal risk assessment on the technology and/or business issues described in Task I.1 and planned in Task I.2. Specific risks are identified. In addition, the "cultural risks" associated with technology or business change may also be specified during this task.
Mechanics: Use technology/business risk checklists as well as risks suggested by the requester, the developer, and potential customers.
Application of Formal Methods: risk identification checklists
Application of CASE Tools: t.b.d
Do's & Don'ts
Do: List as many risks as possible. During this task, it's useful to have a pessimistic outlook.
Don't: Discard any risk, regardless of how far-fetched it might seem. [Later, low priority risks will be discarded].
Helpful Hints
1. Use technology risk checklists.
2. An important category of risk for some projects is the system specification, including the target machine on which the software is to be delivered, the hardware interfaces and operating environment for the application, communication protocols, and the support environment.
Deliverables: Categorized list of risks
I.3.2 Estimate the probability of occurrence for each risk.
Intent: The intent of this task is to estimate the probability of occurrence of each of the generic and technology-specific risks identified in Task I.3.1.
Mechanics: Risk probability is determined from past experience. All interested constituencies are polled to estimate the probability for each risk.
Application of Formal Methods: see Risk Analysis references
Application of CASE Tools: t.b.d.
Do's & Don'ts
Do: Express probability using either a quantitative estimate (e.g., 70% probable) or if there is less certainty, a quantitative scale (e.g., high, medium, low).
Don't: Discard any risk, even if it's probability is quite low. {Later, low priority risks will be discarded].
Helpful Hints
Deliverables: Categorized list of risks with probabilities attached
I.3.3 Estimate the project impact of each risk, should it occur.
Intent: The intent of this task is to estimate the impact on project effort, schedule and budget that will result if one or more generic or technology-specific risks should occur.
Mechanics: Risk impact is determined from past experience. All interested constituencies are polled to estimate the impact for each risk.
Application of Formal Methods: see Risk Analysis references
Application of CASE Tools: t.b.d.
Do's & Don'ts
Do: Express impact in terms of project planning parameters, i.e., impact on schedule, impact on effort required to complete the project, impact on project budget.
Don't: Discard any risk, even if it's impact is quite low. {Later, low priority risks will be discarded].
Helpful Hints
1. See Risk Analysis references
2. Ideally, impact should be quantitative and expressed in terms of time, effort, or dollars. Alternatively, an impact scale (e.g., 1 to 5) can be used to indicate relative severity of impact).
Deliverables: Categorized list of risks with probabilities and impacts attached
I.3.4 Develop a list of prioritized technology/business risks.
Intent: The intent of this task is to sort the list created in Task 1.3.1- I.3.3 by impact and by probability.
Mechanics: Sort the list, define a "priority cut-off," and discard those risks that fall below it.
Application of Formal Methods: see Risk Analysis references
Application of CASE Tools: t.b.d.
Do's & Don'ts
Do: Establish a risk cut-off level for project impact and probability. The cut-off level is the point at which the probability and/or impact is too low to warrant serious concern.
Don't: Disregard "gut feel." Even if a particular risk falls below the cut-off, it may be judicious to leave it on the list.
Helpful Hints
You have limited resources. It will not be possible to develop mitigation, monitoring and management (see Task 1.3.5) strategies for all risks. You must define the priority cut-off high enough to accommodate existing management resources, yet low enough to avoid catastrophic problems. When in doubt, consider a few of the risks that might be termed 'borderline.'
Deliverables: completed Risk Table
I.3.5 Define an RM3 and update project plan to reflect risks.
Intent: The intent of this task is to create a risk mitigation, monitoring and management (RM3) plan that is appropriate in size and detail to the project category. A risk mitigation, monitoring and management plan should identify the way in which the developer will monitor each of the risks noted in Task I.3.4 and how the risk will be handled if it should occur. In essence, the RM3 is a contingency plan. In addition, project estimates noted in Task I.2 may be updated to reflect risks.
Mechanics: Concrete steps for avoiding, monitoring and managing each risk are indicated.
Application of Formal Methods: see Risk Analysis references
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Does the plan for mitigating risks address pragmatic methods for avoidance?
2. Are the factors that are monitored readily available to the project manager? Have bounds been placed on the monitoring activity?
3. Does the management plan provide solid contingency planning should the risk occur?
4. Is there a plan for revisiting the risk table and adjusting probability and impact as the project progresses?
5. Is there a plan for updating the RM3 plan on a regular basis?
Do's & Don'ts
Do: Be as specific as possible in indicating how risks will be monitored and what (specifically) will be done should one or more risks occur. Be prepared!
Don't: Think that it's necessary to write a voluminous document to satisfy the intent of this task. For casual or semi-formal projects (and for many quick reaction projects), the RM3 Plan may be the minutes of a brief meeting that considers risk.
Helpful Hints
Deliverables: Risk Mitigation. Monitoring and Management Plan, usually defined as part of the Software Project Plan
Use Browser "back" arrow or return to APM Process Design Language Description
