|
‘The chance of exposure to the adverse consequences of future events.’
|
|
Government intervention
|
|
|
Cuts in resources, including staff
|
|
|
Reduction in financial support
|
|
|
Increased competition from rivals
|
|
|
Social developments
|
|
Analyse what you already know - views, trends or constraints
|
|
|
Use prompts and checklists from aids to build initial list of risks. (Check textbooks, Application development documents, company standards, Google)
|
|
|
Review Barry Boehm’s Top Ten Risks
|
|
|
Methods of gathering risk info
|
|
|
-
|
Interviewing experts or stakeholders
|
|
-
|
Brainstorming workshops w/stakeholders
|
|
-
|
Searching past project documentation
|
|
Law of diminishing returns, do not assume that all generic risks will be relevant
|
|
|
Dismiss risks not project specific
|
|
|
Recognise root cause of the problem
|
|
|
Based on seemingly precise values
|
|
|
Probability is represented between 0-1 or %
|
|
|
Impact = $ loss should risk happen
|
|
|
Probability x impact = risk exposure $$$
|
|
|
Risk exposure value (REV) can be compared against insurance premium
|
|
|
REV helps assess effectiveness of risk reduction action
|
|
|
Risk reduction leverage (RRL) = (RE (before) – RE(after)) / cost of risk reduction
|
|
|
If RRL > 1.0 the action is worth while
|
|
|
Problems with quantitative risk assessment
|
|
|
-
|
Without lots of data IDing probability is often guesswork
|
|
-
|
Amount of damage usually guesswork
|
|
-
|
Amount guessed might be less than actuality & risk fund may be exhausted
|
|
New risks ID'd any time, & secondary risks result from actions to reduce initial risks.
|
|
|
Monitoring is part of project control cycle
|
|
|
Monitoring = mixture of regular reviews and reviews after events, e.g. end of a stage.
|
|
|
Need a project risk plan to doc planning & facilitate monitoring & control process. Use a risk register/log, & list all the risks
|
|
For each risk in register, an individual risk record will be created
|
|
|
Risk record shows prob & impacts before and after mitigating action is taken
|
|
|
Risk plan
|
|
|
Plans of actions documented
|
|
|
Not always 1:1 between risk and plan
|
|
|
Risk owner manages risk plan & monitoring
|
|
|
If risk changes during process, revise plans
|
|
Reduction in the value delivered
|
|
|
Project failure
|
|
|
Higher development costs
|
|
|
Delayed project completion
|
|
|
Reduced scope
|
|
|
Reduced performance
|
|
|
Completed system fails to deliver capability = original business case not realised
|
|
1. Personnel shortfalls – capability/skill mismatches
|
|
|
2. Unrealistic schedules and budgets
|
|
|
3. Developing wrong functions & properties
|
|
|
4. Developing the wrong user interface
|
|
|
5. Gold-plating – development of unneeded functionality
|
|
|
6. Continuous stream of changes
|
|
|
7. Shortfalls in external components
|
|
|
8. Shortfalls in externally performed tasks
|
|
|
9. Real-time performance shortfalls
|
|
|
10. Straining capabilities – current technologies / expertise not developed to satisfy req's and project becomes a research project
|
|
Because qualitative is mostly guesswork modern practice = qualitative approach
|
|
|
Approaches = interviewing stakeholders, experts and brainstorming
|
|
|
Qualitative descriptions of probability:
|
|
|
Extremely Likely, Very High, High, Medium, Low, Very Low, Improbable
|
|
|
Quantitative values expressed within a range, e.g. 20–50% probability. Then map to categories of probability and impact
|
|
|
Risk assessment similar to effort estimation, often done together
|
|
|
Prioritising risks
|
|
|
-
|
Ensure effort used where needed most
|
|
-
|
Use a probability impact grid (PIG)
|
|
-
|
On the PIG #'s uniquely identify each risk
|
|
Benefits should outweigh benefits of inaction – use the calc of risk reduction leverage
|
|
|
Decisions
|
|
|
-
|
How many actions to approve
|
|
-
|
In relation to which risks
|
|
-
|
Focus first on the show-stoppers – that prevent completion of the project.
|
|
With quant approach, sum up risk exposure figures for an overall project risk exposure. Then plan actions to reduce risk to level acceptable. Alternatively address highest priority risks.
|
|
|
staff changes
|
|
|
lack of policies to guide decision making
|
|
|
increased scope of changes
|
|
|
lack of developer experience
|
|
|
sabotage
|
|
ID risks
|
|
|
Plan to deal with them
|
|
|
-
|
Contingency
|
|
Execute project
|
|
|
Monitor and control
|
|
|
Cyclic process throughout project
|
|
|
Evaluate and then prioritise the risk
|
|
|
Evaluation criteria
|
|
|
-
|
Probability risk will occur
|
|
-
|
Impact that the risk could have
|
|
Risk exposure, magnitude of the risk
|
|
|
Risks may impact time, cost or quality, and will impact business case.
|
|
|
-
|
Time: longer development time needed
|
|
-
|
Quality: reduction in the scope or performance of the deliverable
|
|
-
|
Costs: increase in the resources
|
|
A risk can be viewed as an opportunity
|
|
|
Proximity of the risk
|
|
|
-
|
Risk magnitude vary – completed tasks risks disappear
|
|
-
|
Time period when the risk may occur
|
|
-
|
Uncertainty high at beginning due to unknowns. As knowledge increases uncertainty is reduced.
|
|
Consequence of mitigating action, update:
|
|
|
-
|
project schedule
|
|
-
|
development costs
|
|
-
|
functional scope
|
|
-
|
Performance of the deliverables
|
|
Accepting the risk
|
|
|
If prob low, impact low, & other actions not practical could accept risk and monitor it
|
|
|
Maybe cost of action outweighs impact
|
|
|
Preventing the risk aka 'risk avoidance'.
|
|
|
Reducing the risk
|
|
|
Action before the expected risk occurs
|
|
|
Transferring the risk to another party, outsource for eg
|
|
|
Contingency
|
|
|
No action before the risk occurs
|
|
|
Plan of action once risk occurs, or certain
|
|
|
Generally only incurs costs if risk arises
|
|
|
Costs
|
|
|
$ to manage risk and with creating the conditions in the contingency action plan
|
|
No comments yet.
Cheatography n. The art of mapping complex subjects into clear, instantly navigable reference guides.
