0% found this document useful (0 votes)
14 views15 pages

SPM Lecture 23

The document outlines the processes involved in performing qualitative and quantitative risk analysis in software project management, including inputs, tools, techniques, and outputs for each analysis type. It also discusses monitoring and controlling risks, risk mitigation strategies, and provides various scenarios with identified risks and suitable mitigation strategies. The focus is on prioritizing risks, assessing their impacts, and implementing strategies to minimize their likelihood and effects on project success.

Uploaded by

mediasales345
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
14 views15 pages

SPM Lecture 23

The document outlines the processes involved in performing qualitative and quantitative risk analysis in software project management, including inputs, tools, techniques, and outputs for each analysis type. It also discusses monitoring and controlling risks, risk mitigation strategies, and provides various scenarios with identified risks and suitable mitigation strategies. The focus is on prioritizing risks, assessing their impacts, and implementing strategies to minimize their likelihood and effects on project success.

Uploaded by

mediasales345
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 15

1|Page

Course Name: Software Project Management

Course Code: SESM-470

Semester: [BSCS-7] Credit hours: [3+0]

Presented by: Hina Mehjabeen

Week 13: Performing Qualitative Risk Analysis, Performing Quantitative Risk


Analysis, controlling risks

Performing Qualitative Risk Analysis


This process involves prioritizing risks based on their probability and impact to focus
on those that are most critical to the project.

Inputs:

 Project Management Plan (risk management plan)


 Project Documents (risk register, stakeholder register, assumption log)
 Enterprise Environmental Factors (EEFs) (industry benchmarks, risk
tolerance of stakeholders)
 Organizational Process Assets (OPAs) (qualitative risk analysis templates,
historical data)

Tools & Techniques:

 Risk Probability and Impact Assessment: Assessing the likelihood and


impact of each risk.
 Probability/Impact Matrix: Charting risks to prioritize them based on their
severity.
2|Page

 Risk Data Quality Assessment: Ensuring the data used to analyze risks is
accurate and complete.
3|Page

 Risk Categorization: Grouping risks by categories (e.g., technical, external,


organizational).
 Risk Urgency Assessment: Determining the proximity or immediacy of a risk.
 Expert Judgment: Gaining insights from experienced team members or
external experts.
 Meetings: Discussing and analyzing risks collaboratively with stakeholders.

Outputs:

 Risk Register Updates: Enhancements to the risk register, including revised


risk rankings, probability, impact scores, and categorized risks.
 Risk Report Updates: Updated information on prioritized risks and trends.
 Project Document Updates: Modifications to assumption logs, issue logs, and
lessons learned repository based on the analysis.

Performing Quantitative Risk Analysis


Inputs:

 Risk Register: Includes identified risks, their probabilities, impacts, and risk
owners.
 Risk Management Plan: Guides the approach for quantitative analysis,
including data collection methods and models to use.
 Cost Management Plan: Provides information about the project’s budget and
funding levels to assess financial risks.
 Schedule Management Plan: Provides time-related information to assess
risks related to project timelines.
 Stakeholder Register: Can provide insights into stakeholder concerns and
expectations that may impact risk analysis.
 Enterprise Environmental Factors (EEFs): Such as industry standards and
risk tolerance that influence the analysis.
 Organizational Process Assets (OPAs): Historical data or lessons learned
from previous projects to support the analysis.

Tools & Techniques:


4|Page

 Decision Tree Analysis: A diagramming technique to evaluate possible


decision alternatives and their potential outcomes. It includes Expected
Monetary Value (EMV), which helps calculate the expected profit or loss for
each decision path.

 Simulation (Monte Carlo Analysis): A statistical method used to model the


possible outcomes of risk events, based on probabilistic distributions of
different project parameters (e.g., time, cost).
5|Page

 Sensitivity Analysis: Examines how changes in one or more input variables


impact project outcomes (e.g., project costs, schedule).
6|Page

 Expert Judgment: Used to estimate probabilities, impacts, and other risk-


related parameters.
 Data Gathering and Representation Techniques: Techniques such as
interviews or surveys to collect relevant data.

Outputs:

 Risk Report: Provides updated information on risk impacts, probabilities, and


quantitative analyses of risks.
 Risk Register Updates: Incorporates any changes based on the results of the
quantitative analysis, including revised risk responses, impact estimates, and
risk probabilities.
 Quantitative Risk Analysis Results: Numerical values or statistical
distributions that provide insights into the probability of achieving project
objectives, cost overruns, or schedule delays.
 Contingency Reserves: Updated amounts based on the analysis, specifying
the additional funds or time needed to manage identified risks.
7|Page

Monitoring/Controlling Risks
Inputs:

 Risk Management Plan: Provides the processes and guidelines for tracking
and managing risks.
 Risk Register: Contains the updated list of identified risks and their associated
information (probabilities, impacts, responses).
 Work Performance Data: Provides real-time information on project
performance, which is crucial for risk monitoring.
 Project Documents: Includes project schedules, cost reports, issue logs, and
any other documents that can provide insight into how well the project is
managing its risks.

Tools & Techniques:

 Data Analysis: Techniques like trend analysis, variance analysis, and reserve
analysis to assess the effectiveness of risk responses and track ongoing risks.
 Audits: Independent reviews of the project’s risk management processes to
ensure that risk responses are being followed and are effective.
 Meetings: Regular team meetings or risk review sessions to discuss current
risks, new risks, and the effectiveness of risk response strategies.
 Risk Reassessments: Re-evaluation of risks and their potential impacts,
considering changes in project conditions and new risks.
 Workarounds: Unplanned, reactive actions taken to address risks when no
prior contingency plans are available.

Outputs:

 Work Performance Information: Provides insights into how well the risk
responses are working and whether adjustments are needed.
 Change Requests: Proposals for changes in risk responses, schedules, costs, or
other aspects of the project in response to monitored risks.
 Updates to the Risk Register: Inclusion of newly identified risks, changes in
risk probabilities, and updated risk response strategies.
 Updates to the Project Management Plan: Modifications to the overall plan,
particularly in areas like scope, schedule, or cost management, as a result of
monitoring risks.
8|Page

 Organizational Process Assets Updates: Documentation of lessons learned


and effective risk responses that can be used for future projects.

Risk Mitigation Strategies


Once risks are identified and categorized, mitigation strategies should be proposed to
minimize their impact or likelihood. Mitigation strategies can be preventive (avoiding
the risk) or corrective (addressing the risk after it occurs).

General Mitigation Strategies:

1. Risk Avoidance:
o Change the project plan to eliminate the risk entirely.
o Example: Switching to a more stable technology to avoid technical
risks.
2. Risk Transfer:
o Transfer the risk to a third party, such as outsourcing a part of the project
or purchasing insurance.
o Example: Subcontracting a risky component of the project to a
specialist firm.
3. Risk Reduction:
o Reduce the probability or impact of the risk.
o Example: Implementing additional testing to catch defects early or
breaking the project into smaller milestones to monitor progress more
closely.
4. Risk Acceptance:
o Acknowledge the risk and prepare a contingency plan to address it if it
occurs.
o Example: Accepting a minor schedule delay if it has minimal impact on
the project’s success.
5. Contingency Plans:
o Prepare for unexpected risks by establishing a backup plan.
o Example: Having a plan for managing resource shortages or a backup
team in case of critical skill gaps.
9|Page

Scenario Examples: For Risk Identification/Categorization


with Suitable Mitigation Strategies
Scenario: A software development project to build a new mobile app is behind
schedule due to frequent changes in client requirements. Additionally, a key
developer is unavailable due to health issues.

Solution:

Identified Risks:

 Schedule Risk: Delays caused by frequent changes in client requirements.


 Resource Risk: Key developer is unavailable due to health issues.

Mitigation Strategies:

 Schedule Risk:
o Mitigation: Introduce more robust change management processes, set
clearer client expectations, and allocate buffer time for unexpected
changes.
 Resource Risk:
o Mitigation: Cross-train team members, plan for additional resources, or
bring in a temporary developer to cover the key role.

Scenario: A software development project has a tight deadline to launch a new


mobile app. However, the project has experienced delays due to unexpected design
changes from the client, and the testing phase is projected to take longer than
anticipated.

Solution:

Risk Identification:

 Risk Type: Schedule Risk


 Description: Delays in meeting project deadlines due to unexpected client
changes and extended testing time.

Mitigation Strategies:

 Mitigation 1: Adjust Project Timeline: Reassess the project schedule and


incorporate additional buffer time for unexpected changes or delays. Prioritize
key features for the initial launch and defer non-critical features.
10 | P a g e

 Mitigation 2: Set Clear Expectations: Work closely with the client to finalize
requirements early, minimizing the chances of further changes.
 Mitigation 3: Agile Approach: Adopt an agile methodology where iterations
allow flexibility to adjust and incorporate changes incrementally without
disrupting the entire timeline.

Scenario: The project team is small, and a key developer falls ill and is unable to
work for a few weeks. This may lead to delays in key development milestones,
especially in areas of the project requiring their expertise.

Solution:

Risk Identification:

 Risk Type: Resource Risk


 Description: Critical team member is unavailable due to illness, leading to
delays in development.

Mitigation Strategies:

 Mitigation 1: Cross-Training: Train other team members in key areas so they


can step in and take over critical tasks if needed, reducing dependency on a
single individual.
 Mitigation 2: Temporary Resource Augmentation: Hire a temporary
developer or outsource parts of the work to maintain progress during the
absence.
 Mitigation 3: Shift Workloads: Reallocate tasks among available team
members to ensure the project continues moving forward despite the absence.

Scenario: During the initial stages of a software development project, the team
encounters significant compatibility issues between the app's front-end framework
and the backend API, which could lead to integration challenges and delays.

Solution:

Risk Identification:

 Risk Type: Technical Risk


 Description: Compatibility issues between the front-end framework and
backend API may delay development or lead to unexpected technical debt.

Mitigation Strategies:
11 | P a g e

 Mitigation 1: Prototype Early: Develop a small proof-of-concept or


prototype to identify potential compatibility issues before the full-scale
development begins.
 Mitigation 2: Use Well-Supported Frameworks: Select technologies and
frameworks with broad community support and compatibility assurances to
reduce the likelihood of integration issues.
 Mitigation 3: Regular Technical Reviews: Hold regular technical reviews
and pair programming sessions to identify and address compatibility issues
early in the development process.

Scenario: The project is developing a healthcare app that handles sensitive patient
data. The development team is concerned about potential data breaches or security
vulnerabilities, especially since the app needs to comply with strict healthcare
regulations (e.g., HIPAA).

Solution:

Risk Identification:

 Risk Type: Security Risk


 Description: The risk of data breaches or failure to comply with security and
regulatory standards could lead to legal issues, loss of reputation, and financial
penalties.

Mitigation Strategies:

 Mitigation 1: Data Encryption: Implement encryption for sensitive data both


at rest and in transit to protect patient information.
 Mitigation 2: Secure Coding Practices: Follow industry-standard security
practices, such as input validation, authentication mechanisms, and regular
vulnerability scanning.
 Mitigation 3: Compliance Checks: Ensure the application complies with
relevant laws and regulations, such as HIPAA, by engaging legal and
compliance experts early in the development process.

Scenario: The software development team is working with a new project


management tool to track progress and deliverables. However, the tool has a steep
learning curve, and there is concern that team members may struggle to use it
effectively, impacting productivity.

Solution:
12 | P a g e

Risk Identification:

 Risk Type: Operational Risk


 Description: Operational inefficiencies due to team members’ unfamiliarity
with the new project management tool.

Mitigation Strategies:

 Mitigation 1: Training and Support: Provide proper training for team


members on the new tool to ensure they can use it efficiently.
 Mitigation 2: Phased Adoption: Gradually introduce the new tool, allowing
the team to become familiar with it over time rather than expecting immediate
full adoption.
 Mitigation 3: Alternative Tools: If the new tool remains ineffective, have a
backup plan to switch back to a previous tool or select a more user-friendly
alternative.

Scenario: A software company is developing an app aimed at a particular


demographic group. However, early market research suggests that preferences in the
target audience are shifting, and the demand for the app might not be as high as
initially projected.

Solution:

Risk Identification:

 Risk Type: Market Risk


 Description: Market demand may decline due to changing preferences in the
target audience, impacting the app's adoption.

Mitigation Strategies:

 Mitigation 1: Market Research: Continuously monitor market trends and


customer feedback throughout the development process to adapt to changing
demands.
 Mitigation 2: Product Pivot: Be ready to pivot the app's features or target
audience if early findings indicate that the current direction may not succeed.
 Mitigation 3: Marketing Strategy Adjustment: Adjust marketing strategies
and messaging to better align with the current needs and expectations of the
target market.
13 | P a g e

Scenario: A software development company has secured funding for a new project.
However, due to unforeseen costs—such as higher-than-expected labor expenses,
licensing fees for third-party software, or unexpected delays—there's a concern that
the project could run over budget.

Solution:

Risk Identification:

 Risk Type: Financial Risk


 Description: The risk of exceeding the project's budget, which may affect the
overall financial viability of the project or lead to funding shortages.

Mitigation Strategies:

1. Detailed Budget Planning: Establish a clear, detailed budget at the start of the
project, including a contingency fund to address unforeseen costs.
2. Regular Financial Monitoring: Implement regular reviews of project
expenses to track spending and identify areas where cost overruns are
occurring.
3. Cost Optimization: Look for opportunities to reduce costs without
compromising quality, such as optimizing the use of resources, reducing scope,
or negotiating better rates with suppliers.
4. Contingency Planning: Prepare for the possibility of financial shortfalls by
securing additional funding or restructuring payment schedules with investors
or clients.

Scenario: A software company develops a healthcare app that collects and processes
personal health data. However, the company is unaware of the recent updates in
privacy regulations, such as the General Data Protection Regulation (GDPR) in the
EU or Health Insurance Portability and Accountability Act (HIPAA) in the US.

Solution:

Risk Identification:

 Risk Type: Regulatory Risk


 Description: Changes in laws or failure to comply with existing regulations
can result in fines, penalties, or project delays. In this scenario, the risk could
14 | P a g e

involve the app not meeting required legal standards for data security or
privacy, leading to legal actions or market withdrawal.

Mitigation Strategies:

1. Regular Regulatory Monitoring: Stay updated on laws, regulations, and


industry standards that affect the software project, particularly regarding data
privacy (e.g., GDPR, HIPAA). This can involve subscribing to legal update
services or consulting legal experts regularly.

Example: Monitor changes in data privacy laws across different regions where
the app will be released to ensure compliance.

2. Compliance Audit: Conduct a thorough audit of the project to ensure that it


meets all regulatory requirements before launch. This should include reviewing
data collection methods, storage, and sharing practices, especially in sensitive
areas such as healthcare, finance, or education.

Example: Implement regular compliance checks with privacy law


requirements (such as data encryption, user consent, and access control).

3. Engage Legal and Regulatory Experts: Work with legal teams or external
consultants who specialize in relevant regulatory frameworks. These experts
can guide the development team on how to structure data collection, storage,
and sharing to comply with laws.

Example: Work with GDPR consultants to ensure that user data is stored and
handled according to regulations and that users’ consent is properly recorded.

4. Legal Risk Insurance: Purchase insurance to cover the potential financial


impact of non-compliance, especially in high-risk industries like healthcare or
finance.

Example: Obtain insurance that covers fines, legal fees, or damage to


reputation due to data privacy violations or regulatory breaches.

5. Regulatory Risk Management Plan: Develop a specific risk management


plan to address potential regulatory risks. This plan should include clear steps
for mitigating risks, such as adjustments to software features or user processes
to align with legal requirements.
15 | P a g e

Example: Prepare a response plan for addressing issues if the app fails to meet
regulatory standards, including corrective measures and communication with
regulatory bodies.

6. Training and Awareness: Ensure that the development team is trained and
aware of the relevant regulations affecting the project. This can help prevent
accidental violations due to ignorance or misunderstanding.

Example: Organize regular training sessions on data privacy laws for the
development and legal teams involved in the project.

You might also like