This document discusses risk management in projects. It provides statistics showing the percentage of projects from 2011-2016 that were successful, disputable, or failures. It then discusses the risk management process, which includes identification, analysis, strategy formation, and monitoring and control of risks. Some typical risks in outsourced development projects are also outlined. The document emphasizes the importance of identifying, assessing, and developing strategies to address risks in order to increase the likelihood of project success.

1. Risk management
Maksym Negoda | It Business School | Risk management

2. About me
● Certified ScrumMaster.
● Program manager at MIRS Corporation. Work with the e-
commerce projects program and integrates strategically the
initiatives aimed at changes in the organization.
● In IT 7 years, 6 of which are dedicated to project management.
● Started career from the position of QA-engineer. During this time
was in the role of PM in Outsource, Outstaff, Marketing agency,
Product companies.
● Worked with both as domestic and foreign customers (USA,
Australia, Israel, Great Britain).
● Formed a list of risks in the outsource development company's
and the policy of working with these risks.
Maksym Negoda | It Business School | Risk management

3. Risk definition
Maksym Negoda | It Business School | Risk management

4. Statistics of successfully completed projects
2011 2012 2013 2014 2015 2016
Successful 29 % 35 % 22 % 37 % 39 % 36 %
Disputable 53 % 46 % 51 % 42 % 43 % 48 %
Failure 18 % 19 % 27 % 21 % 18 % 16 %
Maksym Negoda | It Business School | Risk management

5. Statistics of successfully completed projects
Small
76%
20%
4%
Large
10%
52%
38%
SUCCESSFUL DISPUTABLE FAILURE
Cost
of human resources
less than 1 million dollars
Cost
of human resources
more than 1 million dollars
Maksym Negoda | It Business School | Risk management

6. An example of the constructing of the Opera House
Sydney Opera House
Pre-project assessments
Time
Budget
4 years
7 000 000 $
Maksym Negoda | It Business School | Risk management

7. An example of the constructing of the Opera House
Sydney Opera House
Results after completion of the project
Time
Budget
14 years
120 000 000 $
Maksym Negoda | It Business School | Risk management

8. Risk management process
Maksym Negoda | It Business School | Risk management

9. Risk management process
● Identification, analysis
Maksym Negoda | It Business School | Risk management

10. ● Identification, analysis
● Strategy formation
Maksym Negoda | It Business School | Risk management
Risk management process

11. ● Identification, analysis
● Strategy formation
● Monitoring and control
Maksym Negoda | It Business School | Risk management
Risk management process

12. Risks identification
Maksym Negoda | It Business School | Risk management

13. Questions for identification
● Why do we need identification?
Maksym Negoda | It Business School | Risk management

14. Questions for identification
● Why do we need identification?
● Whom to involve for discussion of risks?
Maksym Negoda | It Business School | Risk management

15. Questions for identification
● Why do we need identification?
● Whom to involve for discussion of risks?
● How to organize and plan a discussion?
Maksym Negoda | It Business School | Risk management

16. Questions for identification
● Why do we need identification?
● Whom to involve for discussion of risks?
● How to organize and plan a discussion?
● How will we monitor and control?
Maksym Negoda | It Business School | Risk management

17. Direction of risk identification
● Time
● Scope
● Budget
Maksym Negoda | It Business School | Risk management

18. Direction of risk identification
● Time
● Scope
● Budget
● People
Maksym Negoda | It Business School | Risk management

19. Direction of risk identification
● Time
● Scope
● Budget
● People
● Quality
Maksym Negoda | It Business School | Risk management

20. Brainstorm Session
Allows your team to discuss
what they perceive as risks
Allows the group to work off of
one another’s ideas
Maksym Negoda | It Business School | Risk management

21. The purpose of the Brainstorm Session
● Identify the list of risks
● Consider similar projects
● Assess the likelihood of risks
● Assess the impact of risks
Maksym Negoda | It Business School | Risk management

22. Priority and impact of risks
High priority Critical priority
Low priority
Average
priority
Likelihood:
HIGH
Degree of impact:
HIGH
Degree of
likelihood:
LOW
Likelihood:
LOW

23. Risk Register
● ID*
● Name (description)
● Impact
● Probability
● Plan
● Owner
● Details
Maksym Negoda | It Business School | Risk management

24. Internal
Risk groups
Maksym Negoda | It Business School | Risk management

25. Risk groups
External
Maksym Negoda | It Business School | Risk management

26. Types of risks
● Social
Maksym Negoda | It Business School | Risk management

27. Types of risks
● Social
● Production
Maksym Negoda | It Business School | Risk management

28. Types of risks
● Social
● Production
● Financial
Maksym Negoda | It Business School | Risk management

29. Types of risks
● Social
● Production
● Financial
● Commercial
Maksym Negoda | It Business School | Risk management

30. Types of risks
● Social
● Production
● Financial
● Commercial
● Environmental
Maksym Negoda | It Business School | Risk management

31. Types of risks
● Social
● Production
● Financial
● Commercial
● Environmental
● Security Risks
Maksym Negoda | It Business School | Risk management

32. Typical risks in outsource
development
Maksym Negoda | It Business School | Risk management

33. Typical risks in outsource development
● Risk of incorrect scope scope definition
● Uncontrolled changes / continuous growth of the scope of the project
● Functionality adding by dev team that is not in the scope
● Ambiguity of requests for changes
● Ignoring (non-observance) of communications
● Mismatched expectations
Maksym Negoda | It Business School | Risk management

34. Typical risks in outsource development
● Conflicts within the team
● Lack of experience / knowledge of technology
● Low productivity
● Delay in the timing of approval
● Non-scalable technologies
● Decreased team motivation
● Change of stakeholders
Maksym Negoda | It Business School | Risk management

35. Strategy of work with risks
Maksym Negoda | It Business School | Risk management

36. Risks require ...
● Solutions
● Action
● Responsibility
Maksym Negoda | It Business School | Risk management

37. Actions with risks
Allows your team to discuss
what they perceive as risks
Allows the group to work off of
one another’s ideas
Maksym Negoda | It Business School | Risk management
Accept the Risk

38. Actions with risks
Avoid the Risk
Changing your plans so that you
eliminate the risk
Maksym Negoda | It Business School | Risk management

39. Actions with risks
Transfer the Risk
You are making another party
responsible
Maksym Negoda | It Business School | Risk management

40. Actions with risks
Mitigate the Risk
Take action to make the risk
less likely or less impactful
Maksym Negoda | It Business School | Risk management

41. Updating of risks
● Risk Status
● Risk Probability
● Impact of risks
● Risk Priority
● The risk budget
Maksym Negoda | It Business School | Risk management

42. Risk assessment
Maksym Negoda | It Business School | Risk management

43. Descriptive risk matrix
Risk Likelihood
Risk Impact Very Low Low Moderate High Very High
Very High LOW MODERATE HIGH HIGH HIGH
High LOW MODERATE MODERATE HIGH HIGH
Moderate LOW LOW MODERATE HIGH HIGH
Low LOW LOW LOW MODERATE MODERATE
Very Low LOW LOW LOW LOW MODERATE
Maksym Negoda | It Business School | Risk management

44. Quantitative descriptive risk matrix
Risk Likelihood
Risk Impact 1- Very Low 3 - Low 5 - Moderate 7 - High 9 - Very High
10 - Very High 10 - LOW 30 - MODERATE 50 - HIGH 70 - HIGH 90 - HIGH
8 - High 8 - LOW 24 - MODERATE 40 - MODERATE 56 - HIGH 72 - HIGH
6 - Moderate 6 - LOW 18 - LOW 30 - MODERATE 42 - HIGH 54 - HIGH
4 - Low 4 - LOW 12 - LOW 20 - LOW 28 - MODERATE 36 - MODERATE
2 - Very Low 2 - LOW 6 - LOW 10 - LOW 14 - LOW 18 - MODERATE
Maksym Negoda | It Business School | Risk management

45. Practical part
Maksym Negoda | It Business School | Risk management

46. Practical part
Maksym Negoda | It Business School | Risk management
● Risk of incorrect project scope definition

47. Practical part
● Risk of incorrect project scope definition
Mitigate. It is necessary to decompose the list of requirements. To
evaluate in detail the first short period of time. If you can not determine -
discuss this risk with the customer.
Attention! The larger the project volume, the more likely it is to err in the
assessment.
Maksym Negoda | It Business School | Risk management

48. ● Uncontrolled changes / continuous growth of the project scope
Practical part
Maksym Negoda | It Business School | Risk management

49. Practical part
● Uncontrolled changes / continuous growth of the project scope
Transfer. Determine the conditions for growth in the scope of the project.
Is such a scenario acceptable to the customer? Discuss the conditions for
increasing the budget and time of the project.
Mention the decrease in the motivation of the team. Tell about the
importance of the invariability of architectural solutions.
Maksym Negoda | It Business School | Risk management

50. Practical part
● Risk of change of stakeholders
Maksym Negoda | It Business School | Risk management

51. Practical part
● Risk of change of stakeholders
Active acceptance. We accept this risk. Control that key agreements have
been fixed in the documentation. Discuss with the customer that the
agreement with the change of key persons remains in force (or other
conditions).
Discuss with the customer the level of project alienation. Transfer all
information to new key persons.
Maksym Negoda | It Business School | Risk management

52. Practical part
● Selected technologies do not allow to fulfill the project objectives
Maksym Negoda | It Business School | Risk management

53. Practical part
● Selected technologies do not allow to fulfill the project objectives
Avoid. At the stage of architectural planning, make sure that the selected
technologies can achieve the goals. Otherwise, abandon the technology or
change the stack. Involve external experts in the expertise. Or abandon the
project.
Maksym Negoda | It Business School | Risk management

54. Maksym Negoda | It Business School | Risk management

55. Common prejudices
● Hope everything will go well
Maksym Negoda | It Business School | Risk management

56. Common prejudices
● Hope everything will go well
● People can predict
Maksym Negoda | It Business School | Risk management

57. How to be?
Maksym Negoda | It Business School | Risk management