Conceptualisation Stage Continued

Transcription

1 Conceptualisation Stage Continued

2 Conceptualisation Inputs to conceptualisation stage Influencing factors Stakeholder analysis Feasibility Risk Outputs from conceptualisation stage

3 Risk

4 Structured Approach to Risk Engineering Risk Engineering Risk Assessment More... Risk Management More... From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

5 Structured Approach to Risk Engineering Risk Assessment Risk Identification Risk Analysis checklists decomposition system dynamics performance modelling assumption analysis decision driver analysis cost modelling network analysis decision analysis quality factor analysis From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

6 Structured Approach to Risk Engineering Risk Management Risk Prioritisation Risk Reduction Risk Planning Risk Control Risk exposure Buying information Risk item planning Risk resolution Compound risks Risk avoidance Risk plan integration Risk monitoring Risk transfer Risk reporting Risk reduction leverage Risk reassessment From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

7 Risk management control loop Start Risk assessment Risk prioritisation Risk reduction Risk management planning Risk resolution From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC- D4-001-R2 Risk monitoring End

8 Risk Assessment Risk assessment Risk identification Risk analysis Risk assessment involves the identification and analysis of risks From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

9 Risk monitoring Risk monitoring Is risk plan effective? Is risk plan adequate? Are new risks identified? Is project complete? To risk resolution To risk prioritisation To risk assessment To end From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

10 Risk Model Identify Assess Not Significant Upwards Allocate Project Member Containment Control Project Plan Trigger Contingency

11 Risk Model: part 1 Identify Upwards to client/key stakeholders Assess Allocate More... Not Significant Project Member

12 Risk Model: part 2 Containment Control Project Plan More...

13 Risk Model: part 3 Project Plan Trigger Contingency

14 Risk Process Identify Key Stakeholders Identify Critical Success Factors Isolate the Baseline Plan Analyse and Assign Risks

15 Identify Key Stakeholders Many people want many things from a software development project Identify the key stakeholders the people whose wants count

16 Identify Critical Success Factors Ask key stakeholders what is required for success The answers are the critical success factors of the project, used to measure its success A risk is something that could prevent one or more of the critical success factors being met

17 Risks versus Issues A risk is something that might happen An issue is something that has happened......and needs to be resolved

18 Isolate the Baseline Plan Risks must be associated with a plan before they can be handled Risks could prevent the achievement of objectives plans for achieving objectives must be in place before risks can be considered

19 Analyse and Assign Risks Identify: What are the potential risks? Assess: What is the impact of each risk? What is the likelihood of the risk occurring? How can the risk be prevented or identified early? What needs to be done if the risk does occur? Allocate: To whom can I assign the risk?

20 Risk Identification Risks identified should be those considered to be risks to the achievement of the organisation s, project s or department s objectives Risks should be grouped under the five headings agreed as part of the Statement of Risk Appetite. Within those headings risk should be presented with the highest residual risk first and then in descending order. Arrows should be used to indicate whether the risk has increased, decreased or stayed the same since the last review.

21 Risk Appetite The amount of risk which is judged to be tolerable and justifiable is the risk appetite

22 Major groupings of sources of risk Contractual/environmental Management/process Personnel Technical From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

23 Contractual/environmental Unreasonable customers Defaulting subcontractors Late delivery of components Dependencies/demands from other projects Company operation Industrial action Disasters From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

24 Management/process Undefined/ill-defined responsibilities & authorities Undefined procedures Unknown quality of development products Inadequate control of development products Problems and errors detected late Inadequate technical approaches Inadequate support facilities & services Lack of visibility From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

25 Personnel Wrong people available wrong grade wrong training wrong expertise Wrong availability too many people for current tasks too few people for current tasks From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

26 Technical Requirement changes genuine changes of mind by the customer hidden implications emerge Failure to meet requirement cannot produce a feasible design acceptance test fails Problem or error detected inconsistent design missing component inadequate time for testing From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

27 Risk Assessment Tool Consequence catastrophic medium negligible low medium high Probability

28 Risk Assessment Tool: Risk Prioritisation Consequence catastrophic B A A medium C B A negligible D D B low medium high Probability

29 Risk Assessment Tool: Risk Prioritisation Severity Of Impact Catastrophic 5 Major 4 Moderate 3 Minor 2 Insignificant Rare Unlikely Possible Likely Almost certain Likelihood of occurrence Risk tolerability matrix: Green activities require no further action Yellow activities should be monitored and managed down to green where it is considered practical and cost-effective Red activities require immediate action and should be reported to the Risk Committee, however the activity may be allowed to continue given the current environment the University operates in. Black activities must immediately be referred to the Vice Chancellor and Chair of Governors.

30 Risk Assessment: Risk Prioritisation Risk Impact Likelihood Severity (Impact * Likelihood) Insufficient disk space Tracker Action/Contingency Vic (Action) Investigate cost & lead time for upgrade. Insufficient memory Ian (No action at present) Version 2.0 of the database is a bit buggy Requirements not too detailed. Users not available for CAT Kami (Action) Send Kami on early training course. (Contingency) Use version Vic (Action) Check on progress and choose best areas for phased delivery Ian (Action) Check user plans (Contingency) Use external testers.

31 Risk Assessment Form Title of Process/Procedure/ Experiment: Brief description of work involved: Significant hazards: Significant risks: Risk Rating: Low Medium High Likelihood Severity Risk Rating Total (Likelihood x Severity):... Risk (Low = 1-3, Medium = 4,6 High = 9):... Groups at risk (staff, students, etc): Special risk groups (disabled persons, maintenance workers etc):

32 Risk Assessment Risk Title Raw Risk Risk Controls Residual risk Financial Further M itigations L S Sc L S Sc I mpact R equired Risks associated with support systems and processes, and in particular management and quality assurance Risk Owner Failure to provide accurate funding returns Data Quality Management Programme Board Detailed report to Audit Committee. Quality Assurance provided by Internal and External Audit millions Reputatio nal damage Funding project approach applied Development of the Office of Institutional Effectiveness DC E Director of Finance CEO

33 Risk Assessment Raw risk calculation Likelihood of occurrence ( L ) graded on a scale of 1 to 5 (rare/ unlikely/ possible/ likely/ almost certain) Severity of impact ( S ) graded on a scale of 1 to 5 (insignificant/ minor/ moderate/ major/ catastrophic) The raw risk score ( Sc ) calculated by multiplying the likelihood of occurrence and severity of impact scores.

34 Risk Assessment Risk controls The controls actually in place not those to be put in place or those that should be in place Some controls designed to reduce likelihood of risk occurring (e.g. back-up files to reduce risk of loss) Other controls designed to reduce severity of impact (e.g. insuring against the risk)

35 Addressing Risk: Treat Most risks will be addressed in this way. The purpose of treatment is that whilst continuing with the activity giving rise to the risk, action (control) is taken constrain the risk to an acceptable level Such controls can be further sub-divided according to their particular purpose

36 Addressing Risk: Tolerate Exposure may be tolerated without further action Even if not tolerable, ability to do anything about some risks may be limited, or the cost of taking any action may be disproportionate to the potential benefit gained Response may be to tolerate the existing level of risk This option may be supplemented by contingency planning for handling the impacts that will arise if the risk is realised

37 Addressing Risk: Transfer For some risks the best response may be to transfer them conventional insurance paying a third party to take the risk in another way Good for mitigating financial risks or risks to assets Transfer of risks may be considered either reduce the exposure another organisation more capable of managing risk Some risks are not (fully) transferable, e.g. reputational risk

38 Addressing Risk: Terminate Some risks will only be treatable, or containable to acceptable levels, by terminating the activity Option to terminate activities may be severely limited and will almost certainly require approval of key stakeholders This option can be particularly important in project management if it becomes clear that the projected cost / benefit relationship is in jeopardy

39 Addressing Risk: Take the Opportunity Not an alternative should also be considered whenever tolerating transferring treating a risk Two aspects: 1. While mitigating threats, an opportunity arises to exploit positive impact. E.g. if funding is at risk in a major project, are controls good enough to justify increasing investment to gain greater advantages? 2. Positive opportunities arise without generating threats. E.g. lower costs of goods/services allows other resources to be re-deployed

40 Risk Containment action versus contingency plan containment action action taken before the risk occurs might prevent the risk from taking place reduce the impact should the risk occur is it cost-effective, or better to leave as it is? contingency plan plan of action made before the risk occurs alternative plan triggered by the risk occurring funds need to be set aside in case the plan is needed

41 Outputs Feasibility report to contain: Project goals, objectives & scope Stakeholders Constraints Success criteria Feasibility analysis & risk level Scope of the next stage of project Go/no-go recommendation

42

43 References & further reading Burke, R (2003), Project Management: Planning and Control Techniques, Wiley (or more recent editions) Field, M & Keller, L (1998), Project Management, International Thomson Business Press Maylor, H (1999), Project Management (2 nd Edition), Pitman Publishing Ould M A (1992), Strategies for Software Engineering: The Management of Risk and Quality, John Wiley & Sons, Inc. Redmill F (1995) Risk Management is for Everyone, IText Volume 1, Issue 1, pages 58-60, Oxford University Press. Rook P & Cowderoy A, (1993), Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2, GOAL ESPRIT 6283