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