Switch off your Mobiles Phones or Change Profile to Silent Mode

Topics Introduction Project Life Cycle Conceptualisation Stage Planning Stage Planning Tools & Techniques Implementation Stage Team Dynamics & Management

Conceptualisation Stage Cont.. Inputs to conceptualisation stage Influencing factors Stakeholder analysis Feasibility Risk Outputs from conceptualisation stage

Risk

Risk has always been defined loosely as: Chance of Loss Possibility of Loss Uncertainty Measure of probability and consequence of not achieving a defined project goal Actual outcome is likely to deviate from expected results Probability of any outcome different from one expected

Risk In recent years, there has been a growing awareness of the presence of risk on projects and the need to manage it consciously. Projects are particularly susceptible to risk because each project is unique in some measure. Most decision is made on the basis of expectations, assumptions and forecast of future events.

Risk Relationship between risk and uncertainty can be summarised as Risk is quantifiable, uncertainty is non quantifiable Risk can be assessed by using various statistical techniques, uncertainty cannot Risk can be quantified with hard data, uncertainty only attach to subjective opinion

Risk Two common elements / possible outcomes caused by risk Outcome may be better than originally expected – upside risk Outcome may be worse than originally expected – downside risk

Risk Studies indicate that all project have inherent risk Such risk would have been handled one way or another ultimately Some risk Disappears Matures and Develops into problems that need management attention Turns into crisis if being ignored or not handled properly, which would ultimately destroy the project

Risk Categorisation Financial and Non Financial Risks Financial Risks Exposure to loss Destruction and dispossession that will cause financial loss a peril that can cause the loss

Risk Categorisation Non Financial Risks Static and Dynamic Risks Dynamic risks are losses caused by changes in external and internal factors. Pure and Speculative Risks Pure risk refers to situations that involve only chance of loss or no loss. In contrast, speculative risk involves situations that hold a possibility of either loss or gain

Risk Categorisation Risk can also be classified further as: High Level Risks That will have critical impact on a project Low Level Risks Cumulative effect of combining many Low Level Risks could have the same or greater impact than High Level Risk Business Risk Risk that affect profit and loss, involving business activities, competitors and customer action, economic and general industrial situation

Risk Categorisation Insurable Risks Risk that only give us a chance for a loss, which include such elements as direct physical damages such as project material, equipment and other properties; protection for indirect consequential loss due to third party actions; protection for legal liability for non performance; protection for employee due to bodily injury, resignation and other losses from employee action

Risk Categorisation External Risks Risks outside the Risk Manager’s control but have impact on the project. Natural Hazards Act of God Financing Material Changes in government regulations Introduction of new competitor products Major Technological Breakthroughs

Risk Categorisation Internal Risk Controllable risks Involving labor Cash flow and Budget cuts associated with declining corporate profitability Employee reward issues Appointment of a new vice president in charge of the division Assignment of resources to our project coming from other work units.

Risk Categorisation Technical Risk Technical Risk comprises the risk factors associated with the development or operation of the deliverable. Including changes in technology, in state of art, design and operation Market Risk Market Risk is the risk that the product or service we develop will fail in the market place.

Risk Categorisation Human Risk Human Risk arises from the fact that human players in projects Project staff Managers Customers Vendors and are complex, marginally predictable beings.

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

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

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

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

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

Risk - Reward Trade - Offs We are willing to assume risk because we anticipate that the rewards of our venture will more than offset the losses. Risk and Time Horizon The further off an event is in the future, the less certain we are of its exact composition, and the higher the probability that some unanticipated action will affect it adversely.

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

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

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

Risk Management Control Loop Start Risk Assessment Risk Prioritisation Risk Reduction Risk Management Planning Risk Resolution Risk Monitoring End From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

Risk Assessment Risk Assessment attempts to identify the nature of risk events and to anticipate their impacts on the project (Analysis of risks) Risk Assessment Risk Identification Risk Analysis From: Rook P & Cowderoy A, (1993): Risk Engineering, GOAL/ICSTM-DOC-D4-001-R2

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

Risk Identification Risk Identification is a process of uncovering potential risk events in order to avoid unpleasant surprises. Use checklists, comparison, decomposition, … Top Software Risk Personnel shortfalls Unrealistic schedules and budgets Developing the wrong functions and properties

Risk Identification Developing the wrong user interface Continuing stream of requirements changes Shortfalls in externally furnished components Shortfalls in externally performed tasks Real-time performance shortfalls

Risk-Management Planning Important risks (top-10 priorities) have to be managed through well-defined plans. Why, what, when, who, where, how, how much Important techniques Buying information Risk avoidance Risk transfer Risk reduction Plans have to be integrated into main project plan

Risk-Management Techniques Personnel shortfalls Top talents, job matching, team building, training Unrealistic schedule and budget Detailed estimation, incremental development, reuse Developing wrong functionality Prototyping, analysis, user participation

Risk-Management Techniques Requirements changes High change threshold, information hiding, incremental development External jobs Benchmarking, inspection, compatibility analysis, pre-award audit

Risk Mitigation A risk becomes a problem when “Risk Factors” cross a threshold, as defined in plan. Contentment Action planning Prevention Immediate response e.g. training Contingency planning Correction When needed e.g. use of extra resources

Risk Mitigation Containment Action versus Contingency Plan Containment action before 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?

Risk Mitigation Contingency plan plan of action made before the risk occurs triggered by the risk alternative plan triggered by the risk occurring funds need to be set aside in case the plan is needed

Risk Resolution and Monitoring Implementing the risk management plans and monitoring the risks Top-10 risk item tracking Rank project’s most significant risk items Regular review schedule for higher management Summary of top-10 items in project review meetings Monitor the planned activities for risk management Revise the list in review meetings

Risk Monitoring Risk Monitoring is concerned with developing strategies to cope with risk events. Risk Monitoring furnishes with actions we can take to either avoid a risk event or dampens its impacts. It generally focuses on three risk-coping strategies Developing and following System Standards Acquiring Insurance Developing Planning Alternatives.

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

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

Risk Model: Part 2 Containment Project Plan Control More...

Risk Model: Part 3 Contingency Project Plan Trigger

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

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

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

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

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

Risk Component Risk is said consist to three key components An Event Probability of occurrence of a particular event Magnitude and impact of that event

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

Severity and Frequency of Risk Loss CategorySeverityFrequency MinorVery LowVery High SmallLowHigh Medium Low LargeHighVery Low

Severity and Frequency of Risk Severity and Frequency of loss are inversely proportional, with one rise, the other will fall Categorising Severity of Risk Emergency Avoided only if agreed by all parties with immediate and decisive action Alarm Occur if recommendation preventing it are action quickly

Severity and Frequency of Risk High Risk Occurs unless some avoiding action is taken Moderate Occur as supported by enough factors Low Risk Occur if situation deteriorates Slight Risk Unlikely to cause problem No Risk No evidence of Risk occurring

Level of Complexity and Risk All Information Systems differ dramatically in their size, scope, level of complexity and organisational and technical components Some Systems Development project are more likely to fail purely because they carry much higher level of risk than others

Level of Complexity and Risk The level of project risks are being influenced by Project Size The larger the project, the greater the risk. Project size is commonly measured by money spent, size of the project team, time allocated and number of organisational units affected

Level of Complexity and Risk Project Structure Some projects are likely to be more structured than others, with clear and straightforward requirements. As such, their outputs and processes can be easily defined. Users are unlikely to change their minds since they know exactly their own requirements and clear of what the system should do. Project of this nature runs a much lower risk than those with loosely or relatively undefined requirements.

Level of Complexity and Risk Experience with Technology Higher risk will be expected if both the project team and the information system staff lack the required technical experience. If project team is not familiar with the Hardware, Systems Software, Application Software or Database Management Systems proposed for the project, one of the following events occur Unexpected time slippage due to needs to master new skills

Level of Complexity and Risk Technical problems if new tools have not been mastered Extra costs and time due to inexperience with new Hardware and Software

Risk Assessment Tool Probability Consequence low catastrophic medium negligible mediumhigh

Risk Assessment Tool: Risk Prioritisation Probability Consequence low catastrophic medium negligible mediumhigh BDD C B B A A A

Risk Assessment: Risk Prioritisation

Risk Manager Anyone entrusted with responsibility of performing Risk Management Can be Employee of Organisation Outside Consultant Project Manager normally assumes role of Risk Manager

Role of Risk Manager Assist Top Management in formulating and developing Risk Management Policy Implement Risk Identification and Measurement process Analyse, consider and recommend alternative risk financing technique for adoption Negotiate insurance coverage and manage claims

Role of Risk Manager Administer risk functions including loss prevention and administrative function such as maintenance and monitoring of records, manuals, schedules and agreement Accounting matters relating to risk issues such as allocating risk and insurance charges to appropriate cost centers

Role of Risk Manager Internal communication with other departments and outside parties, using formal documents such as “Risk Management Manuals”, meetings and other informal ways, updating and provide guidance and consultation on risk issues.

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

Any Questions?