Risk Management

Lecturer-Daw Aye Khaing Khaing Moe

 How do we manage risk?

 Success in systems analysis and design requires not only skills in methodologies and
techniques, but also project management skills for managing time, resources, and risks.
 If a project is considered to be high risk and highly complex, and has a development
team made up of hundreds of people, then more traditional methods will apply.
 Less risky, smaller, and simpler development efforts lend themselves more to Agile
methods.
 Other determining factors include organizational practice and standards, and the extent
to which different parts of the system will be contracted out to others for development.
Identifying and assessing risk

 The goal of this activity is to identify sources of project risk and estimate the
consequences of those risks.
 Risks might arise from the use of new technology, prospective users’
resistance to change, availability of critical resources, competitive reactions
or changes in regulatory actions due to the construction of a system, or team
member inexperience with technology or the business area.
 You should continually try to identify and assess project risk.
 What are some sources of risk in a systems analysis and design project and
how does a project manager cope with risk during the stages of project
management?
Where is Risk ?
 It is important to note that all projects have risk and that risk is not necessarily
something to avoid.
 Yet it is also true that, because organizations typically expect a greater return on their
investment for riskier projects, understanding the sources and types of technical risks
proves to be a valuable tool when you assess a project.
 Also, risks need to be managed in order to be minimized; you should, therefore, identify
potential risks as early as possible in a project.

 The potential consequences of not assessing and managing risks can include the
following:
 • Failure to attain expected benefits from the project
 • Inaccurate project cost estimates
 • Inaccurate project duration estimates
 • Failure to achieve adequate system performance levels
 •Failure to adequately integrate the new system with existing hardware, software, or
organizational procedures
 Risk Factors -Planning
 Following is the list of risk factors for the feasibility study phase:

 Project manager often make a mistake in estimating cost, time, resources and scope of the project.
Unrealistic budget, time, inadequate resources and unclear scope often leads to project failure.
 Unrealistic Budget: As discussed above inaccurate estimation of budget may lead to project running
out of funds early in the SDLC. Accurate estimation budget is directly related to correct knowledge of
time, effort and resources.
 Unrealistic Schedule: Incorrect time estimation lead to a burden on developers by project managers
to deliver project on time. Thus compromising the overall quality of the project and thus making the
system less secure and more vulnerable.
 Insufficient resources: In some case the technology, tools available are not up-to date to meet project
requirements or resources(people, tools, technology) available are not enough to complete the
project. In any case it is the project will get delayed or in worst case it may lead to project failure.
 Unclear project scope: Clear understanding of what project is supposed to do, which functionalities
are important, which functionalities are mandatory, which functionalities can be considered as extra
is very important for project managers. Insufficient knowledge of the system may lead to project
failure.
 Requirement Elicitation-- Analysis

 It starts with analysis of application domain.

 This phase requires the participation from different stake holders to ensure
efficient, correct and complete gathering of system services, its performance and
constraints.
 This data set is then reviewed and articulated to make it ready for the next phase. 
 Risk Factors
 Incomplete requirements: In 60% of the cases users are unable to state all
requirements in the beginning. Therefore requirements have the most dynamic
nature in the complete SDLC Process. If any of the user needs, constraints or other
functional/non functional requirements are not covered then the requirement set is
said to be incomplete.
 Inaccurate requirements: If the requirement set do not reflect real user needs then in
that case requirements are said to be inaccurate.
 Unclear requirements: Often in the process of SDLC there exists a communication gap
between users and developers. This ultimately affects the requirement set. If the
requirements stated by users are not understandable by analyst and developers then
these requirements are said to be unclear.
 Ignoring non functional requirements: Sometimes developers and analyst ignore the
fact that non functional requirements hold equal importance as functional
requirements. In this confusion they focus on delivering what system should do rather
than how system should be like scalability, maintainability, testability etc.
Risk Factors
 Conflicting user requirements: Multiple users in a system may have different
requirements. If not listed and analyzed carefully, this may lead to inconsistency in
the requirements.
 Gold plating: It is very important to list out all requirements in the beginning.
Adding requirements later during the development may lead to threats in the
system. Gold plating is nothing but adding extra functionality to the system that
were not considered earlier. Thus inviting threats and making the system
vulnerable.
 Unclear description of real operating environment: Insufficient knowledge of real
operating environment leads to certain missed vulnerabilities thus threats remain
undetected until later stage of software development life cycle.
 Requirement Analysis Activity
 In this step requirements that are gathered by interviewing users or brainstorming or
by another means will be:
 first analyzed and then classified and organized such as functional and non functional
requirements groups and then these are prioritized to get a better knowledge of
which requirements are of high priority and need to be definitely present in the
system. After all these steps requirements are negotiated. 
Risk Factors
Risk management in this step has following task to do: 
 Non verifiable requirements: If a finite cost effective process like testing, inspection etc
is not available to check whether software meets the requirement or not then that
requirement is said to be non verifiable.
 Infeasible requirement: if sufficient resources are not available to successfully
implement the requirement then it is said to be an infeasible requirement.
 Inconsistent requirement: If a requirement contradicts with any other requirement then
the requirement is said to be inconsistent.
 Non traceable requirement: It is very important for every requirement to have an origin
source. During documentation it is necessary to write origin source of each requirement
so that it can traced back in future when required.
 Unrealistic requirement: If a requirement meets all above criteria like it is complete,
accurate, consistent, traceable, verifiable etc. then that requirement is realistic
enough to be documented and implemented.
Requirement Validation Activity

 This involves validating the requirements that are gathered and analyzed till
now to check whether they actually defines what user want from the system. 
 Risk Factors

 Misunderstood domain specific terminology: Developers and Application specialists

often use domain specific terminology or we can say technical terms which are not
understandable for majority of end users. Thus creating a misunderstanding
between end users and developers.
 Using natural language to express requirements: Natural language is not always the
best way to express requirements as different users may have different signs and
conventions. Thus it is advisable to use formal language for expressing and
documenting
Requirement Documentation Activity

 This steps involves creating a Requirement Document(RD) by writing down all

the agreed upon requirements using formal language. RD serves as a means of
communication between different stakeholders. 
Risk Factors

 Inconsistent requirements data and RD: Sometimes it might happen, due to

glitches in gathering and documentation process, actual requirements may
differ from the documented ones.
 Non modifiable RD: If during RD preparation, structuring of RD with
maintainability is not considered then it will become difficult to edit the
document in the course of change without rewriting it.
Types of Risks in Software Development and How to
Deal with Them

 Inaccurate Estimation Risks

 It is a critical part of risk management in software development. We are constantly
making estimates, but there is a risk of creating expectations that are not realistic.
 Estimation in software development is primarily on the timeframes and the
budget.
 In terms of the timelines, the risk is mainly underestimating the time frames
required for different iterations.
 The mitigation to this risk would be thoroughly understanding the client’s
requirements, communicating the same to the development team, and coming up
with a realistic timeframe.
Types of Risks in Software Development
and How to Deal with Them
 As a project manager or decision-maker, you should resist the temptation to
pressure the development team to deliver on unrealistic timelines. The risk-
reward analysis of doing this is not worth it. You run the risk of getting a low-
quality iteration.
 However, you also need to manage the customers and their expectations regarding
delivering the software releases. Customers are known to be notoriously
impatient, but they too should avoid their impatience materializing to a risk.
 The greater risk would be underestimating the project expenses in terms of
budget, which can easily lead to delays.
 The mitigation on the front would be something like coming up with a contingency
budget to cover any unforeseen expenses.
Scope Variation Risks

 Among the biggest challenges that software developers face is scope variation.
Changing requirements due to ongoing client and user feedback is a constant risk in
software development.
 It is a good thing on hand as it ensures that the final product is of sound quality and is
helpful to the end-users.
 However, from a risk management perspective in software development, it is a risk
that can delay project implementation, introduce numerous uncertainties or even lead
to budget overruns.
 As such, it is a critical risk that needs analysis, tracking, and mitigation. The best way
to mitigate against this risk is by having structured communication between the
development team and the client/end-user.
 The project manager is usually the link between the development team and the client.
Scope Variation Risks

 The best practice is monitoring scope variations using a scope variation metric
visible to both the development team and the customer.
 The variation metric will serve as a tool to show how the scope variations have
impacted the project in terms of budget and timelines. More importantly, it will
help in prioritizing tasks.

One of the significant variation risks in software development is the scope creep,
which can lead to cost overruns, delays, and an increase in the project’s overall
risk.
 However, for legacy system migration, managing the scope can be challenging, as
the existing software is often complex, interconnected, and highly customized.
The scope of migration of legacy systems must be clearly defined to ensure that
the project is manageable and to avoid unnecessary costs and risks
 End-user Engagement Risks
 You cannot talk about risk management in software development and fail to address the
risk involved with end-user engagement.
 The end goal of software development is to develop a product that is useful to some
people. If these people have any problems using the final product, then that’s a
considerable risk.
 End-user engagement is critical to the project’s success, whether the software is for
external customers or internal.
 Strong end-user involvement and engagement throughout the project life cycle ensure
the final product is easily acceptable.
 Achieve engagement through:
 User surveys
 Frequent releases
 Minimum Viable Product (MVP) release
 Beta testing
 These mitigation strategies will hopefully ensure a smoother adoption phase.
Stakeholder Expectations Risks
 There is always some stakeholder expectation risk in every software
development project. Stakeholders in these projects are all people involved
in one way for the successful completion of the project.
 Of particular concern in mitigating this risk are:
 End users
 Customers
 Investors
 Development team
 These groups will require a mitigation strategy to address their expectations
before developing into a risk affecting the project.
Technical Risks
 Technical risks in a software development project are generally those that impact
the quality of the end product. These are things like poor code, support, integration
issues, etc. These technical risks can have a severe negative consequence on the
usability of the product. That’s why it’s necessary to address technical risk when
talking about risk management in software development.
 The thing with technical risk management is that they are not quickly noticeable
during the development phase. They become apparent at the end of the process,
which can make them challenging to correct.
 Poor productivity among software developers is a technical risk. It mainly occurs in
projects that have a long life cycle. Developers may lose motivation the longer the
project goes.
 There is also the risk that a long-term deadline is far away, and there is enough time
to cover for any tasks not done.
 Intense oversight of software iterations reduces technical risks.
 Agile methodologies are particularly robust in maintaining productivity and
motivation among the development team.
Human Resource Risks

 While working with people, there is always a risk that someone may
unexpectedly become unavailable. This person may be a vital member of the
team, which has the chance of creating a knowledge gap.
 The person may be from the development team or the client-side, actively
involved in the project.
 To mitigate this risk, proper documentation of every detail of the project is
critical. Software development documentation is an active and continuous
process.
 Additionally, having contingency plans on how to onboard new team members
should always be in place.
Communication Risks

 Just like in any other project, a breakdown in communication during software

development is disastrous. Constant and effective communication is essential
to project success. A communication breakdown will lead to delays and lower
productivity.
 The whole team should be committed to the project to mitigate a
communication breakdown risk. When we talk about the team here, we mean
everybody from the project manager, developers, testers, customers, etc.
 Regular meetings of all stakeholders are an excellent way to keep everyone
engaged and communication flowing. The purpose of the meetings should be
to appraise each other of the progress and expectations.
Common Risk Management in Software
Development Strategies
 Having discussed the seven most common risks in software development, let’s
now look at some practical digital strategies to mitigate these risks.
Monitoring

 Software risk monitoring is the active scrutiny of project activities to identify

risks early enough and apply the correspondent action plan to mitigate them.
 Project stand-up or meetings are an excellent time to identify emerging risks.
Project reports, risk plans, status reports are also opportunities to evaluate if
any trouble is materializing.
 Risks are more likely to come up when deploying any changes or changing the
scope than at any other time.
Risk Avoidance

 It doesn’t sound like a good strategy, but some risks are not worth mitigating.
It is best to avoid them altogether. If the risk is too big, has a very high
probability of happening, or could be costly to mitigate, avoiding it may be
the best option.
 Small organizations/businesses or startups would benefit from this approach
as some risks would wipe them off.
Risk Transfer

 It is a strategy where you procure someone to deal with any risks on your
behalf. This risk management strategy in software development is attractive
to organizations/agencies with the resources to procure such services and
concentrate on their core software development task.
 Risk management in software development may take away precious time and
focus from the core work. Therefore it makes sense to outsource to a
professional whose only work is dealing with such risks.
 This approach has the added advantage of speeding up the process.
Closing Thoughts

 The ultimate objective of risk management in software development is to 

identify, track and mitigate all risks that could otherwise prevent successful
implementation.
 Agencies/corporates/startups should have a risk management framework for
all their software development projects to achieve their goals.
 The process of risk management in software development is continuous and
applies throughout the life cycle of the project. Organizations with a robust
risk management framework that guides all their software projects are more
successful than those that don’t. That’s why it’s important to know how to
select the right software development consultancy.
 https://www.geeksforgeeks.org/integrating-risk-management-in-sdlc-set-1/