risk management

45
Risk Management

Upload: khangminh22

Post on 20-Feb-2023

0 views

Category:

Documents


0 download

TRANSCRIPT

Risk Management

What is “Risk”?

• Risk is the 'effect of uncertainty on objectives'.

– Uncertainties include events (which may or not happen)

– Uncertainties caused by ambiguity or a lack of information.

– It also includes both negative and positive impactson objectives.

(ISO 31000:2009)

Software Engineering in Practice #2 2

Risk vs Uncertainty

• Uncertainty: the lack of complete certainty; the existence of more than one possibility. The “true” outcome is not known.

• Measurement of uncertainty: a set of probabilities assigned to a set of possibilities.

– There is a 20% chance Mega-JK will be president among 5 candidates appeared today.

Software Engineering in Practice #2 3

Risk vs Uncertainty

• Risk: A state of uncertainty where some of the possibilities involve a loss, catastrophe, or other undesirable outcome.

• Measurement of risk: A set of possibilities each with quantified probabilities and quantified losses. – There is a 20% chance Mega-JK will be president

that makes me loss of USD 1 million in betting.

(Doug Hubbart)

Software Engineering in Practice #2 4

Risk vs Uncertainty

• Dari 100 fitur aplikasi, 5 di antaranya belum dites oleh Tester.

• Ada 5 fitur aplikasi yang tidak sempurna. Perlu 10 mandays programer untuk menyelesaikan dan 2 mandays tester untuk melakukan tes.

• Aplikasi kita sudah dicoba dan berjalan baik di lingkungan Windows. Entah kalau SO-nya Linux, Mac, atau lainnya.

• Jika aplikasi ternyata harus jalan di Linux, maka kita harus re-development mulai dari Nol.

Software Engineering in Practice #2 5

Risk vs Uncertainty

• One may have uncertainty without risk, but NOT risk without uncertainty.

– We can be uncertain about the winner of the contest. We have no risk. If we bet money on the outcome of the contest, then we have a risk.

– In both cases, there are more than one outcome.

• The measure of uncertainty refers only to the probabilities assigned to outcome, while the measure of risk requires both probabilities and losses quantified for outcomes.

Software Engineering in Practice #2 6

Key #1

Leave which you are in doubt to which you are in no doubt.

(Al-Hadits – Tirmidzi)

Software Engineering in Practice #2 7

ك إلى ما دع ما يريب

ال يريب ك

More about “Risk”

• Risk concerns future happenings.– Yesterday and today are already happened.

– We are already reaping what was previously sowed by our past actions.

• Risk involves choice, and the uncertainty that choice itself entails.

• Risk involves change– By changing our actions today, we can create a better

situation tomorrow.

(Robert Charette)

Software Engineering in Practice #2 8

The Foundation

Software Engineering in Practice #2 9

Key #2

Thus paradoxically, risk, like death and taxes, is one of the few certainties of life.

(Robert Charette)

Software Engineering in Practice #2 10

Robert N. CharetteRisk management

consultant

Charette’s Concept

• The future is our concern– What risks might cause the software project to go

awry

• Change is our concern– How will changes in any entity connected to the

project affect overall success

• Choice is our concern. Means we must grapple with choice. – What methods, tools should be used, how many

people should be involved, etc?

Software Engineering in Practice #2 11

Charette’s Three Conceptual Underpinnings

Risk: Negative or Positive?

• People have a negative connotation when thinking about Risk.

• Risk itself is not really a bad thing.

• Taking risks can even have a positive impact.– You may get a discount from a vendor because of

past order.

– A change request from customer allows project six more weeks of development time.

• Positive risks are called Risk Opportunities.

Software Engineering in Practice #2 12

Risk: Negative or Positive?

• Let see the interesting video of Mario Teguh regarding the “Risk”.

Software Engineering in Practice #2 13

Software Risks

• Important goals of software projects:

– Deliver the software to customer at the agreed time

– Keep overall costs within the budget

– Deliver software that meets customer’s expectations

– Maintain a happy and well-functioningdevelopment team.

– .....

Software Engineering in Practice #2 14

Software Risks

• Some differences of the software:

– The product is intangible

– Large software projects are often “one-off”projects.

– Software processes are variable and organization-specific.

• It is not surprising that some software projects are late, over budget, and behind schedule.

Software Engineering in Practice #2 15

Software Risks

• Any risk that is related to software engineering.• In software engineering, risks are rampant. • All projects deal with risks that are usually so far

off the risk radar.– The company might go out of business.– An asteroid could crash into the office building– Thunder in a rainy day damages all devices, included

data storage.– A thief steals your production computer. There is no

back-up of your codes.– Senior programmer might be move to Hawai.

Software Engineering in Practice #2 16

Software Risk

Software Engineering in Practice #2 17

Software Risk Types

• Risk types of software engineering– Product Risk: related to software development

– Project Risk: related to project management.

• There is another risk that is closed to software engineering.– Business Risk: related to organization developing

or procuring the software.

– Pure Risk: related to any bad stuff that nobody likes.

Software Engineering in Practice #2 18

Software Risks Example

Software Engineering in Practice #2 19

Example of common Risks

Characteristics of Risks

• Risk always involves two characteristics:– Uncertainty: the risk may or may not happen;

there are no 100% probable risk.

– Loss: if the risk becomes a reality, unwanted consequences or losses will occur.

• When risks are analyzed, it is important to quantify:– The level of uncertainty

– The degree of loss associated with each risk.

Software Engineering in Practice #2 20

Risk Strategies

• Reactive Risk Strategy

– Called “Indiana Jones school of risk management”

– When faced with over-whelming difficulty, he says, “Don’t worry! I’ll think of something!”

– Never worrying about problems until they happened.

Software Engineering in Practice #2 21

Risk Strategies

• The average SW project manager is NOT Indiana Jones, and the members are NOT his trusty sidekicks.

• But, the majority of software team rely solely on reactive risk strategies.– The software team does nothing about risks until

something goes wrong.

– The team flies into action in an attempt to correct the problem rapidly

– This is often called a fire fighting mode.

Software Engineering in Practice #2 22

Risk Strategies

• Proactive Risk Strategy

– Begins long before technical work is initiated.

– Potential risks are identified, their probability and impact are assessed, they are ranked by importance.

– Then the software team establishes a plan for managing risks.

Software Engineering in Practice #2 23

The right mindset is nothow brave to take the risks, but how can anticipate and overcome the risks that might be occured at the future.

Software Engineering in Practice #2 24

Key #3

(Tung Desem Waringin)

Key #4

If you don't actively attack the risks, they will actively attack you.

(Tom Gilb)

Software Engineering in Practice #2 25

Risk Management

• Risk Management involves:

– anticipating risks that might affect the project schedule or the quality of the software being developed, and then

– taking action to avoid these risks.

• Every organization has its own approach to risk management.

Software Engineering in Practice #2 26

Risk Management Process

Software Engineering in Practice #2 27

The risk management process is an iterative process that continues throughout the project.

Risk Identification

• A systematic attempt to specify major threatsto the software engineering process

• By identifying known and predictable risks,PM takes a first step toward avoiding them when possible and controlling them when necessary.

Software Engineering in Practice #2 28

Risk Identification Method

• The method you use to gather information and identify risks is not as important as the fact that you are obtaining as much information as possible.

• For this risk identification, put the emphasis on quantity. More is better.

• Focus on some subset of known and predictable risks.

Software Engineering in Practice #2 29

Risk Identification Methods

• Brainstorming

– The crucial element of a brainstorm is spontaneity.

– Anything goes; no risk is too far out there.

– Include any conceivable risk that could threaten the project’s success

– Your brainstorming session should be done in a big meeting with all the key stakeholders present

Software Engineering in Practice #2 30

Risk Identification Methods

• Delphi Method– Allows stakeholders to anonymously offer their

input into identifying risks

– They can send their suggestions via e-mail to one person who will then consolidate the information into one document --without naming the source of the information.

• Using PM experience to identify the most probable or critical risks

• Etc.

Software Engineering in Practice #2 31

Questions List

Software Engineering in Practice #2 32

No Questions Answers

1. Have top software and customer managers formally committed to support the project?

Yes

2. Are end-users enthusiastically committed to the project and the system/product to be built?

Yes

3. Are requirements fully understood by the software engineering team and their customers?

No

4. Have customers been involved fully in thedefinition of requirements?

No

5. Do end-users have realistic expectations? Yes

6. Is project scope stable? Yes

7. Does the software engineering team have the right mix of skills?

No

8. Are project requirements stable? No

Type of Risk

• Technology risk

• People risk

• Organizational risk

• Tools risk

• Requirement risk

• Estimation risk

Software Engineering in Practice #2 33

List of Potential Risks

• As starting point for risk identification, a List of Potential Risks may be used.

• A long list of potential risks that could occur and which could affect the product, the process, and the business may be created.

• Prune this list to manageable size.

Software Engineering in Practice #2 34

List of Potential Risks

Software Engineering in Practice #2 35

Risk Analysis

• Consider each identified risk and make a judgment about the probability and seriousnessof that risk.

• There is no easy way to do this. You have to rely on your own judgment and experience of previous projects and the problems that arose in them.

• It is not possible to make precise the numericassessment of the probability and seriousness of each risk

Software Engineering in Practice #2 36

Risk Analysis

• Assign the risk to one of a number of bands:

– The probability of the risk might be assessed as very low (<10%), low (10–25%), moderate (25–50%), high (50–75%), or very high (>75%)

– The effects of the risk might be assessed as catastrophic (threaten the survival of the project), serious (would cause major delays), tolerable (delays are within allowed contingency), or insignificant

Software Engineering in Practice #2 37

Risk Analysis

• Tabulate the results of this analysis process using a table ordered according to the seriousness of the risk

• The assessment of probability and seriousnessis arbitrary

• To make this assessment, you need detailed information about the project, the process, the development team, and the organization

Software Engineering in Practice #2 38

Risk Analysis List

Software Engineering in Practice #2 39

Risk Analysis

• The right number of risks to monitor mustdepend on the project.

• The number of risks chosen for monitoring should be manageable.

• It is appropriate to consider the risks that have catastrophic or serious consequences.

Software Engineering in Practice #2 40

Risk Analysis List

Software Engineering in Practice #2 41

Discussion

Software Engineering in Practice #2 42

References

• Sommerville, Ian, Software Engineering, 9th edition, Addison-Wesley, 2011.

• Pressman, Roger S., Ph.D., Software Engineering: A Practitioner’s Approach, 5th edition, Mc. Graw Hill, 2001.

• Luckey, Teresa, PMP, MBA, and Phillips, Joseph, PMP, Software Project Management for Dummies, Wiley Publishing, Inc., 2006.

• Ambler, Scott W., Software Development Success Rates, Dr. Dobbs Jurnal, available in the internet at: www.drdobbs.com/ architecture-and-design/software-development-success-rates/216600177.Accessed: 25/11/2012.

Software Engineering in Practice #2 43

References

• Ambler, Scott W., 2008 IT Project Success Rates Survey Result, Ambysoft.com, available in the internet at: www.ambysoft .com/surveys/success2008.html. Accessed at: 25/11/2012.

• ________, DJJ 2008 Project Success Survey, SurveyMonkey .com, available in the internet at: http://www.survey monkey.com/MySurvey_Responses.aspx?sm=eEhCAwWO. Accessed at: 25/11/2012.

• ________, Risk, BusinessDictionary.com, available in the internet at: www.businessdictionary.com/definition/risk.html. Accessed: 24/11/2012.

• Teguh, Mario, Dipimpin oleh Risiko, Video of Mario Teguh Golden Ways, available in the internet at: www.youtube.com. Accessed: 24/11/2012.

Software Engineering in Practice #2 44

References

• ________, Risk, Wikipedia.com, available in the internet at: en.wikipedia.org/wiki/Risk. Accessed: 24/11/2012.

Software Engineering in Practice #2 45