What is Risk ?

A software risk refers to the possibility of an unwanted event that may have a negative impact on
the software project, that can affect the objectives of a project, such as scope, time, cost, quality, or
customer satisfaction.

It represents uncertainties that can arise during any phase of the SDLC and can affect project success.

Risk is the chance of loss or failure in a software project due to known or unknown factors.

Risks are future-oriented, they are possibilities of problems that may arise in the future.

Risk has two components: Probability – Likelihood of the risk occurring.

Impact – Severity of damage if the risk occurs.

Types of Risks https://www.geeksforgeeks.org/different-types-of-risks-in-software-project-

development/

1. Project Risk: Risks that affect the planning and execution of the software project. These arise due
to improper estimates, planning errors, or management issues.
• Project deadline is too short
• Budget underestimation
• Sudden increase in team workload
• Frequent change requests from the client

2. Technical Risk: Risks that come from the technology, tools, or technical complexity involved in
the software system.
• Using a new or untested technology
• System not integrating with external APIs
• Application crashes under heavy load
• Lack of support for chosen tech stack

3. Business Risk: Risks that impact the business value or profitability of the software product.
• Product doesn’t meet user expectations
• Client changes business model mid-project
• Software has no competitive advantage
• Project costs more than it earns

4. People Risk (Human Resource Risk): Risks caused by issues related to personnel, team members,
or human behavior.
• A key developer leaves during the project
• Lack of skilled testers or designers
• Communication gap in team
• Team members falling sick or going on sudden leave
5. Process Risk: Risks that arise from inefficient or poorly followed development processes.
• Incomplete or no documentation
• Improper version control or backups
• Weak quality assurance or testing processes
• No formal code review system

6. Requirements Risk: Risks related to gathering, understanding, or managing requirements.

• Requirements not clearly defined
• Client keeps changing the requirements
• Misunderstanding between client and developer
• Late discovery of missing features

7. External Risk: Risks that are caused by external factors beyond the control of the project team.
• New government regulation affecting the project
• Vendor fails to deliver a tool or service
• Natural disaster delays the work
• Currency fluctuations increase project cost

8. Security Risk: Risks that can affect the confidentiality, integrity, or availability of the software
system.
• Data breach or hacking attempt
• Weak login or password protection
• Sensitive data not encrypted
• Unauthorized access to admin features

Risk Identification
• Risk Identification is the first and most crucial step in the risk management process.
• It involves identifying all possible risks that may negatively affect a software project in any
phase of the SDLC
• The objective of this step is to create a complete list of risks before they occur so that they can
be analyzed, monitored, and mitigated proactively.
• Risks can be related to technology, people, processes, resources, requirements, etc.

Risk Identification Process includes the following activities:

• Understanding the Project Scope and Environment
Analyze the project’s objectives, technologies used, timelines, team size, and complexity.
Helps in identifying risks related to project scale, feasibility, and environment.
• Consulting Experts and Stakeholders
Involve developers, project managers, business analysts, clients, and subject matter experts
(SMEs).
Gather different perspectives on possible project risks.
• Studying Past Projects
Analyze previously completed or failed projects with similar features.
Learn from historical data to identify recurring risks or avoid previous mistakes.
• Using Standard Risk Checklists and Templates
Many organizations maintain predefined risk categories and checklists.
These help in systematically covering technical, business, and process-related risks.
• Brainstorming Sessions and Interviews
Team discussions or interviews with key members to uncover hidden risks.
Promotes collaborative awareness and brings forward overlooked possibilities.

Examples of identified risks:

• Team may lack experience in new technology
• Client may frequently change requirements
• Budget estimation may not be accurate
• Integration with external systems may fail

Risk Projection
• Once risks have been identified, the next step is to project or estimate their potential effect
on the software project.
• This process is called Risk Projection or Risk Estimation.
• The goal is to analyze:
1. How likely the risk is to occur (Probability)
2. How severe the damage would be if it occurs (Impact)
• Risk Projection allows the project team to prioritize the risks and prepare for the most
dangerous or most likely ones first.
• This helps in prioritizing which risks need more attention.

Steps in Risk Projection:

1. Estimate Probability (P):
o How likely is it that this risk will happen?
o Can be categorized as: Low (0.1–0.3), Medium (0.4–0.6), High (0.7–1.0)
o Alternatively, use qualitative labels: Low, Medium, High
2. Estimate Impact (I):
o What will happen if the risk occurs?
o Impact is the amount of damage, delay, or cost it can cause
o Also classified as: Low, Medium, High
3. Calculate Risk Exposure (RE):
o Risk Exposure=Probability × Impact
o A higher RE means the risk is more dangerous to the project.
4. Prioritize Risks:
o Risks with High Exposure are handled first in risk mitigation.
o Teams often prepare a Risk Table to sort and monitor them.
Example:
Risk Probability Impact Risk Exposure Priority
Developer may leave 0.8 10 8.0 High
Requirements may change 0.5 6 3.0 Medium
Client delays feedback 0.3 3 0.9 Low

Risk Refinement
• Some risks identified in the earlier stages may be too general or complex.
• Risk Refinement is the process of breaking down broad risks into smaller, specific, and more
manageable sub-risks.
• Helps in understanding the risk better and planning specific mitigation actions.
• Used mainly for broad or complex risks like technology or business risks.

Risk Refinement Techniques:

• Risk Trees: A tree-like hierarchical diagram where the main risk is shown at the top (root),
and it is broken down into sub-risks (branches and leaves)
• Cause-and-effect diagram : Also known as Ishikawa or Fishbone Diagrams. A diagram that
looks like a fish skeleton — the “head” represents the main problem (risk), and the “bones”
represent major categories of potential causes.
• Root cause analysis : A systematic method for identifying the underlying cause of a problem
or risk, rather than just addressing the symptoms.
Common RCA Methods:
▪ 5 Whys Technique: Ask “why?” repeatedly (usually 5 times) to trace the cause.
▪ Fault Tree Analysis: Similar to Risk Trees but focused more on logical failure paths.

Example of refinement:
General risk: "Technology Risk"
Refined into:
• Chosen framework may not support scalability
• Developers lack experience in the new technology
• Third-party libraries may be deprecated
• Integration with existing system may fail

The RMMM Plan stands for Risk Mitigation, Monitoring, and Management Plan, and it is a core
part of software project risk management. It defines how to handle risks after they have been
identified and analyzed.
It is an action-oriented plan that outlines how each significant risk will be:
1. Avoided or reduced (Mitigation)
2. Observed throughout the project (Monitoring)
3. Handled if it actually occurs (Management)
This plan is prepared after the risk analysis phase (which includes risk identification, projection, and
refinement).

Why is RMMM Important?

• Ensures that the project team is prepared in advance for possible problems.
• Reduces the chances of project failure, cost overrun, and delays.
• Acts as a risk response plan, just like a fire drill in a building.
• Increases project stability and confidence for both the team and stakeholders.

1. Risk Mitigation
• Risk mitigation involves taking proactive steps to prevent a risk from happening or to
minimize its impact if it does occur.
• It is a proactive approach, meaning action is taken before the risk happens.
• This is the first response layer after risk identification and analysis.
• It involves identifying root causes and finding ways to neutralize or minimize them.
• The main goal is to reduce risk exposure by either:
Lowering the probability of the risk
Lowering the impact of the risk
• Effective mitigation leads to lower risk exposure and increased project reliability.

Steps / Activities Carried Out

• Analyze each risk’s cause and impact.

• Brainstorm multiple mitigation strategies with the team.
• Evaluate and choose the most practical and cost-effective strategy.
• Document the strategy in the risk register or plan.
• Allocate time, budget, and team responsibilities for mitigation tasks.
• Ensure mitigation tasks are scheduled and tracked as part of the project plan.

Examples

• Risk: Unfamiliar technology may cause delays

→ Mitigation: Conduct proof-of-concept; assign training sessions
• Risk: Client may change requirements frequently
→ Mitigation: Freeze requirements after sign-off; maintain change control system

🔷 2. Risk Monitoring
• Risk monitoring refers to the continuous tracking and observation of known risks
throughout the software development life cycle (SDLC)
 • It ensures that no risk is ignored and that the risk status is regularly reviewed and updated.
• Monitoring helps detect if:
o A risk is becoming more or less probable.
o A new risk is emerging.
o An old risk has changed its nature or intensity.
• It involves watching for risk triggers (signs or early symptoms of a risk approaching).
• Monitoring helps in early warning and faster reaction.

Steps / Activities Carried Out

• Review risk status in regular project meetings.

• Use a risk log or risk register to update risk data.
• Identify and define risk triggers or indicators.
• Set up alerts or monitoring tools for external systems (like API status).
• Track whether mitigation actions are being implemented and effective.
• Reassess and update risk probability, impact, and priority.

Examples

• Risk: Unstable third-party API

→ Monitoring: Track API uptime, changelogs, and performance metrics
• Risk: Team productivity may reduce
→ Monitoring: Review task completion rates and team feedback regularly

🔷 3. Risk Management (Contingency Planning)

• Risk management (in RMMM) refers to handling risks that have already occurred. .
• It is a reactive process, unlike mitigation (which is proactive).
• Focuses on damage control, minimizing impact, and keeping the project stable.
• When a risk turns into a real problem, a contingency plan (pre-planned response) is
executed to control the damage and recover the project stability.
• Helps reduce panic and confusion, ensuring quick and systematic recovery.

• Important for business continuity and project survival under unexpected events.

Steps / Activities Carried Out

• Prepare contingency plans for each high-priority risk during planning.

• Assign team members who will act when the risk occurs.
• When the risk event happens:
o Notify key stakeholders
 o Execute predefined plan
o Adjust schedules and resources as needed
• Perform a post-risk assessment to understand the impact and take lessons.

Examples

• Risk: Code repository is lost due to system crash

→ Management: Restore from last cloud backup
• Risk: Key developer leaves unexpectedly
→ Management: Assign trained backup developer; notify HR for recruitment

SCM
- Software Configuration Management (SCM) is a process in software engineering that focuses
on systematically controlling, tracking, and managing changes to software project (documents,
codes and other entities) throughout the development life cycle.
- It provides a structured and disciplined approach to manage evolving software products, track
versions, and maintain integrity.
- These activities work together to ensure that the right version of the right component is available
to the right person at the right time.
It ensures that: SCM helps developers and project managers to
• Software quality is maintained handle:
• All changes are documented • Multiple versions of code and documents
• Teams are working on the correct version of • Team collaboration and change conflicts
files • Recovery from mistakes (e.g., restore an
• The product remains stable and consistent, earlier version)
even as it evolves • Deployment of correct configurations

1. Identification and Establishment

• This is the first and foundational activity in SCM.
• It involves identifying all the software items that need to be managed as Configuration Items
(CIs).
• Configuration items may include:
➢ Source code files
➢ Design documents
➢ Test plans and test cases
➢ User manuals
➢ Scripts or libraries
• Once items are identified, they are assigned unique names, versions, and attributes.
• A baseline is established, which is a formally reviewed and agreed-upon version of a CI or set of
CIs.
• Baselines serve as the starting point for further development, and only authorized changes are
allowed after baseline approval.
• Relationships among configuration items are established to manage dependencies and
structure.
• A system for change control and version management is also set up during this phase.
2. Version Control
• Version control manages the evolution of configuration items over time.
• Each change to a configuration item results in a new version being created and tracked.
• It allows:
➤ Tracking history of changes
➤ Reverting to earlier versions if needed
➤ Parallel development by different team members (via branching)
➤ Merging updates from multiple contributors
• Versions are named using a structured versioning system.
Example:
v1.0 → v1.1 → v1.1.1 → v2.0
• Multiple versions may co-exist and be supported simultaneously depending on product
needs.

3. Change Control
• Change control is a procedural method which ensures quality and consistency when
changes are made in the configuration object.
• Change control ensures that all changes to configuration items are:
➤ Properly evaluated
➤ Documented
➤ Approved before implementation

• Steps involved:
1. A developer/user submits a Change Request (CR).
2. The CR is reviewed for:
▪ Technical correctness
▪ Impact on other modules
▪ Cost and timeline effects
3. A Change Control Board (CCB) decides whether to approve or reject the CR.
4. If approved, an Engineering Change Request (ECR) is created with:
▪ Details of what needs to be changed
▪ Constraints
▪ Criteria for testing and auditing
5. The configuration item is:
▪ Checked out → Modified → Tested → Checked in
6. A new version is generated using version control.

4. Configuration Auditing
• Configuration auditing is a process used to verify that software configurations meet predefined
criteria.
• It ensures that:
➢ Configuration items are correct and complete.
➢ Changes are implemented as approved.
➢ Standards, guidelines, and procedures are strictly followed.
• Types of Audits in SCM:
1. Physical Audit: Verifies that all required files, code, documents, and artifacts exist in the
configuration repository.
2. Functional Audit: Checks if the software works correctly after changes. Ensures that new
updates do not break existing features.
• The audit process helps identify pending issues or inconsistencies that need resolution before a
release or handover. Any action items raised during audits are systematically tracked until
closure.
• Configuration auditing is vital in SCM because it ensures quality, compliance, and integrity of
the software, preventing unauthorized changes and misconfigurations.

5. Status Reporting (Configuration Status Accounting)

• This SCM activity tracks and reports the current state of all configuration items within a project.
• It provides visibility into:
➢ Current versions of software components.
➢ Who made changes and when.
➢ Pending updates or modifications.
• Common Reports in SCM:
• These reports are beneficial for developers, testers, project managers, and stakeholders:
➢ Admin Guides – Documentation for system administration.
➢ User Manuals – Guides for end users.
➢ Release Notes – Summary of updates and changes in a version.
➢ Installation & Configuration Guides – Instructions for setting up the system.
➢ FAQs & Change Logs – A record of modifications made.
• Status reporting maintains transparency throughout the software lifecycle, helping teams stay
informed about changes and preventing configuration drift.