Risk Management In Software Product Development

Discriminative Study on Risk Management In Software Product Development Amandeep Midha EMBA 2007-09

Risk - Definition possibility of loss or injury someone or something that creates or suggests a hazard the chance of loss or the perils to the subject of a contract the degree of probability of such loss a person or thing that is a specified hazard a hazard from a specified cause or source the chance that an investment (as a stock or commodity) will lose value Ref: www.m-w.com

Dynamics of Software Product Development Things Unique to IT Industry: No Trade Associations and Collective Platforms Most ‘other’ industries follow the law of diminishing returns (i.e. after a certain time it costs more to increase your market share against entrenched competitors). IT does the opposite ‘ Absurd Preoccupation’ with underlying technology and everyone always is searching for next big wave! Ref: “Who Says Elephants Can’t Dance” – Louis V. Gerstner, Jr.

Hypothesis Framing H 0 (Null Hypothesis): Identification & management of schedule & operational risks shall improve the predictability of launching a software product/platform with needed feature set in the predefined time-to-market window Ha (Alternate Hypothesis): Project failures cannot be avoided by identification & management of schedule & operational risks

Sequence of Work Checkpoint A – Theoretical Study Inputs Completion Checkpoint B – Qualitative Study Verdict & Questionnaire Begin Checkpoint C – Early Drawings from Empirical Study Checkpoint D – Final Verdict Problem Conclusion Analysis Empirical (Quantitative) Theoretical Study Empirical (Qualitative) D C A B

A. Theoretical Study – 1 Risk Basics & Application Risk – Confusing Topic! Product Development – Never Identical & Different Stakeholders Risks do not have to be negative! Project: Time, Cost, Quality Phases of a Project Customer get Actual Control Here! Feasibility Formulation Implementation Installation Sustaining

A. Theoretical Study -2 Addressing Business Challenges 3 Ongoing Challenges Improving Customer Intimacy Achieving Operational Excellence Providing Product Leadership To Meet the Above Challenges Businesses have to be innovative Innovations does not have to be expensive Primary Business Driver is ‘Increasing Product Complexity and Customization’

A. Theoretical Study – 3 Risks Classification & Handling Risks Classification – Internal vs. External Handling Avoid Prevent Accept Share Limit Transfer

A. Theoretical Study – 4 Risks Reporting Technical Review Checkpoints Acceptance Criteria at each Checkpoint Allowing Overlapping Phases Running one-step ahead Caveat Register Action Impact Y/N Resolution Source Caveat Serial

B. Empirical Study – 1 Interviewing Qualitative Study First 6 Product Managers, 3 Delivery Leaders, 7 Development Managers, 3 Test Managers, and 2 Quality People Section-1: Background Section-5: Risk Reduction Section-2: General Risk Questions Section-3: Risk Transfer Section-4: Risk Retention Section-6: Risk Analysis Section-7: Specific Risk Conversation

B. Empirical Study – 2 Interview – Case Generation Case-1: Change of Solution Design Case-2: Change of Process Case-3: Pilot Unprecedented Process Case-4: Customer Management Case-5: Outsourcing Risks Case-6: Customer Communications Case-7: Estimation Risk Case-8: New Product Development Case-9: Legal Risks (Open source Use) (Please refer to handout for Case Internals)

B. Empirical Study Analysis – 1 First Analysis – Inferences Y Y Global Factors Rest of the World Y Y Y Quality & Schedule Supplier Y Y Y Y Y Biases & Influences Stakeholder Y Y Y Y Y Cost, Time Overruns Offers & Contracts Y Ability to Pay Customer External Y Y Y Y Y Low Mental Ability Team Individual Y Y Y Y Poor Decision Making Project Manager Internal 9 8 7 6 5 4 3 2 1 ‘ Said Risk’ Source

B. Empirical Study Analysis – 2 Analysis – Hypothesis Check Least Inconsistent Evidence Why Software Projects Fail? C-Consistent Evidence I-Inconsistent Evidence C C I I C I I Quality Issues C I I I I I C Platform Incompatibility C I C C I I I Suite Integration Issue I I C I I I C Platform Issue I I C C C C I Schedule Delay I I C C C I I Cost Overrun Lack of Talent Lack of Focus No Risk Study Poor Estimation Poor Planning Changing Requirements Choosing Wrong Technology Problem Evidence Multiple Alternate Hypotheses

C. Empirical Study-3 Quantitative Study Findings Scope Schedule Project Management Program Constraints Scope Program Constraints Schedule Scope Program Constraints

D. Drawings from Empirical Study-I

D. Empirical Study –H 0 Proved? 91% of respondents are of view that “Scope” and “Schedule” related risks must be considered 90% of respondents consider “Business Impact” as an area which requires prior risk study 73% respondents expressed their view that “Dependent delivery” of product/components is to be considered as risk prior Only 33% respondents expressed manpower in high risk consideration 82% of respondents suggested risk measures for customer involvement, while around 73% suggested prior risk measures & study for use of technology 50% respondents answered ‘Customer Involvement’ as High Risk 78% of respondents express their view that ‘Scope’ constitutes medium and high risk aspects of their project 82% of respondents express their view that ‘Business Impact’ constitutes medium and high risk aspects of their project

D. H 0 – Devil’s Advocacy When I stood out against doing risk study as Devil’s advocate, here is the verdict of respondents!

Agile/Cellular: Solution? Least Risk only at End of Project R I S K Plan Develop Code Implement T I M E Plan Develop Code Implement Plan Develop Code Implement Plan Develop Code Implement Plan Develop Code Implement Plan Develop Code Implement R I S K T I M E

Lessons from TOC Focus on Constraints (Risks), since, there is huge potential for “Growth” Ref: “Theory of Constraints”, Goldratt, Eliyahoo OE : Operational Excellence I : Inventory T : Throughput

Forces & Future of Software Delivery Product Growth Product Maturity Generic Expected Augmented Potential Developing Thinking Collaborating Planning Releasing

Solutions? – Ah! Risk was defined as degree of probability of loss arising due to … That does not mean that Risk has to be defined as first derivative of the probability function!  Common Sense approaches like JIT and TQM had been a success in past without any supporting mathematical model Securitized assets were products of “good risk management” which somebody thought of !

Solutions? – Other Thoughts ! Software - Unprecedented System by its Nature No homogenous methods for risk management exist Onsite Engagements to have outcome ownership Quantitative Techniques (Monte Carlo Simulations practice by Intel) One point Requirement Management Unified Product Dashboard Continuous Integration

Achieving Business Level Buy-In No “IF”s No “BUT”s No “We are different” What should be first thing …? “ IDENTIFY RISKS”

Achieving Business Level Buy-In Involve the businesses up-front Work with and complement existing processes Demonstrate clear benefits

Achieving Business Level Buy-In Study reveals that Organizations must understand that Project Key Risk Areas (KRA) hold a direct mapping with project (and hence organizational) Critical Success Factors Goal well worth attaining! Tremendous Costs in product development Resources ready to start on a Late Design Marketing all primed to sell high-margin products. Therefore, the ability to finish a project sooner or with additional features is a great motivator

Thanks for Listening! Amandeep Midha [email_address] .The author pays high regards for information sources for this presentation. Refer to Bibliography for further details

Annex: Limitations of Study The study is formed on the basis of pure product development projects. This bias is clearly orchestrated if we look at following figures: Budget is considered Low to medium by 77% of the respondents Only 33% of respondents say Manpower as high risk 64% respondent rate management support as Low risk activity 82% of respondents classify business impact as medium to high risk Technology is a high risk item for only 55% of the respondents Clearly, such situations can arise only where established product development group within an organization exists which has necessary management approvals & budgetary allocations, and has skilled technical resources available ready to architect a high impact software product. Hence scope of this study should be deemed limited to cluster of such product organizations

Risk Management In Software Product Development

More Related Content

What's hot (20)

Viewers also liked (13)

Similar to Risk Management In Software Product Development (20)

More from Amandeep Midha (7)

Risk Management In Software Product Development

Editor's Notes