U.8.1 Define technology and project risks.
Intent: The intent of this task is to review technology and project risks defined during the scoping phase of the project.
Mechanics: The project team (and customer) should meet to develop a list of risks for the project. Initially, no risks are rejected, no matter how remote.
Application of formal methods: Risk analysis is a formal procedure and is described in many of the risk analysis resources presented at this site.
Application of CASE Tools: t.b.d.
SQA Checklist: none
Do's & Don'ts
Do: Encourage participation by all team members.
Don't Discount any risk, not matter how remote.
Don't Specify a risk with a 100% likelihood of occurrence. It isn't a risk, it's a project constraint.
Helpful Hints
The best way to approach risk definition is to answer the question: "What can go wrong during this project?".
Deliverables: List of risks
U.8.2 Identify project risks associated with scope.
Intent: The intent of this task is to perform a formal risk assessment for the project. Both generic and technology specific risks are identified. In addition, the "cultural risks" associated with technology change may also be specified during this task.
Mechanics: Use risk checklists as well as risks suggested by the customer, the developer, and potential users.
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 risk checklists.
2. An important category of risk is the set of risks associated with reengineering legacy systems. Key areas of concern are interoperability and integration risks.
Deliverables: Categorized list of risks
U.8.3 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.
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 Assessment 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
In determining probability, use a percentage scale defined in 10% increments. A high probability risk is greater than 80% probable. A low probability risk is less than 30% probable. Information developed in Tasks U.8.1 through U.8.4 can be placed in a risk table.
Deliverables: Categorized list of risks with probabilities attached
U.8.4 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 Assessment 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 Assessment 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
U.8.5 Develop a list of prioritized technology risks.
Intent: The intent of this task is to sort the list created in Task U.8.2 through U.8.4 by probability, then by impact.
Mechanics: Sort the list, define a "priority cut-off," and discard those risks that fall below it.
Application of Formal Methods: see Risk Assessment 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
Worrying about every conceivable risk will result in a diluted approach to risk management. Develop the risk cut-off and focus on the risks that fall above the line.
Deliverables: Adjusted list of risks with probabilities and impacts attached
U.8.6 Indicate a plan for technology risk mitigation, monitoring and management (i.e., a contingency plan) and update project planning information to reflect risks.
U.8.7 Review risks with customer.
Risk analysis is a formal procedure and is described in many of the risk analysis resources presented at this site.
U.8.8 Revise project plan, if required.
Intent: The intent of these tasks is to create a risk mitigation, monitoring and management plan (RM3P) that is appropriate in size and detail to the project category. A RM3P should identify the way in which the developer will avoid risks, monitor each of the factors that will cause a risk to become real, and define how the risk will be handled if it should occur. In addition, risks are reviewed with the customer and the Project Plan developed in Task U.1 may be updated to reflect risks.
Mechanics: Concrete steps for mitigating and monitoring each risk are indicated and contingency planning is specified. The risks and contingency plan are presented to the customer for review and comment. If required, the project plan is modified to reflect all risks.
Application of Formal Methods: see risk analysis resources
Application of CASE Tools: t.b.d.
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!
Do: Present risks to both management and the customer. Insist that a "go-no-go" decision be made, given the potential impact of the risks.
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 RM3P may be the minutes of a brief meeting that considers risk.
Deliverables:
1. Risk Mitigation, Monitoring and Management Plan
2. Customer comments on risk
3. Revised Software Project Plan, if required.
Use Browser "back" arrow or return to APM Process Design Language Description
