Ruslan Seredyuk
RISKS IN SOFTWARE
PROJECTS SUCCESS RATE
Failed18%
Challenged43%
Successful39%
Projects
Chaos Report 2013 by Stabdish Group
RECENT EVIDENCE • Obama Care - only 1% of people managed to successfully enroll
with the site in its first week of operation• The Surrey Integrated Reporting Enterprise Network (SIREN). Not
fit for purpose. Team was not capable to finish the project. (15M GBP failure)
• Digital Media Initiative (By 2013, the project was judged to be obsolete (as much cheaper commercial off the shelf alternatives by then existed) and was scrapped by BBC management. (98M GBP)
• Expeditionary Combat Support System . US Air Force. No significant capabilities ready on time; would have cost $1.1bn more just to get to 1/4 of the original scope. (1.1 bn USD )http://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects
BUT WHY IN SOFTWARE
RISKS ARE INEVITABLE IN SOFTWARE. WHY???
• Misunderstanding of requirements • Lack of top management commitment and support• Lack of adequate user involvement• Failure to gain user commitment • Failure to manage end user expectation• Changes to requirements• Lack of an effective project management methodology
Top Ten Lists of Software Project Risks :Evidence from the Literature Survey, 2011
WHY WE DON’T DO RISKS MANAGEMENT
• Boring/Hard to do• Does not work • We should think positively toward the project goals • The data needed to do risk management effectively is lacking.• Agile handles risks as a part of methodology• One person can not manage risks effectively • People minimize the need for risk management by the absence of
evidence (nothing bad has happened yet).• We don’t really what is a RISK
WHAT IS A RISK
TYPE OF RISKS• known known – general software development risks • known unknowns - project specific risks • unknown unknowns - “Black Swans”
KNOWN KNOWS• Misunderstanding of requirements • Lack of top management commitment and support• Lack of adequate user involvement• Failure to gain user commitment • Failure to manage end user expectation• Changes to requirements• Lack of an effective project management methodology
KNOWN KNOWS. WHAT WE CAN DO ?• Be prepared, they will come• Identify using checklists (top 5 - Demarko , top 10 Bohem,
taxonomy method)• Have a risk response plan in place• Put avoidance strategies into estimates • Have contingency plans for mitigation
BOHEM CHEKLIST. TOP 10• 1 Personnel Shortfalls - avoid• 2 Unrealistic Schedules and Budgets - mitigate• 3 Developing the wrong software functions - avoid• 4 Developing the wrong user interface - avoid• 5 Gold-plating - avoid• 6 Continuing stream of requirements changes - mitigate• 7 Shortfalls in externally-performed tasks – avoid, transfer• 8 Shortfalls in externally-furnished components – avoid, transfer• 9 Real-time performance shortfalls – avoid, mitigate• 10 Straining computer science capabilities - avoid
TAXONOMY BASED RISK IDENTIFICATION
Software Engineering InstituteSoftware Engineering Institute
Software Engineering Institute
KNOWN UNKNOWNS• Project/product specific risks – new business area• New technology (e.g. Hadoop)• Team from Ukraine , cultural differences • High speed/performance objectives
KNOWN UNKNOWNS. WHAT WE CAN DO• Be prepared, they MAY come• Identify using brainstorming, Crawford Slip method, Weekly
Meetings, Documentation analysis etc.• Have a risk response plan in place• Put avoidance strategies into estimates • Have contingency plans/reserves for risk management
KNOWN UNKNOWNS. WHAT WE CAN DO
UNKNOWN UNKNOWNS• 50% of your team decided to quit • Virus broken source code repo• Server crashed with no backups
BLACK SWANS. AMOUNT VS DAMAGE
Amount Damage0%
10%20%30%40%50%60%70%80%90%
100%
Black Swans Other risks
According to Tom Kendrick most severe 20% of the risks are black swans. Black swans bring 50% of the damage
UNKNOWN UNKNOWNS. WHAT WE CAN DO• Be prepared they may occur• Have a reserve (100% from initial risks estimates)• Don’t get shocked with the risk• Have a swot team to handle that• Enjoy
WHERE ELSE I CAN LOOK FOR RISKS
User18%
Requirement21%
Complexity5%
Planning and Control
34%
Team11%
Organizational En-vironment
11%
User RequirementComplexity Planning and ControlTeam Organizational Environment
CONCLUSION• Don’t be afraid of risks• Identify as soon as possible• Use checklists and people around for risks identification and
management
SOMETHING TO READ