1. Risk Management
Risk identification

2. Project Risks and How to Identify Them
The first approach to take is to take a broad overview of the
different areas of the project:
• Scope
• Equipment
• Technology
• Existing Data
• People
• Timescale
• Budget

3. Identification
Risk identification can start with the source of problems, or with
the problem itself.
●Source analysis: Risk sources may be internal or external to
the system that is the target of risk management.
oExamples : stakeholders of a project, employees of a company or the
weather over an airport.
●Problem analysis:Risks are related to identified threats.
oExample:the threat of losing money, the threat of abuse of privacy
information or the threat of accidents and casualties

4. Common identification method
Objectives-based risk identification:
Organizations and project teams have objectives. Any event that may
endanger achieving an objective partly or completely is identified as risk.
Scenario-based risk identification:
In scenario analysis different scenarios are created. The scenarios may be the
alternative ways to achieve an objective, or an analysis of the interaction of
forces. Any event that triggers an undesired scenario alternative is identified
as risk.
Taxonomy-based risk identification :
The taxonomy in taxonomy-based risk identification is a breakdown of
possible risk sources. Based on the taxonomy and knowledge of best
practices, a questionnaire is compiled. The answers to the questions reveal
risks.

5. Common-risk checking:
In several industries, lists with known risks are available. Each risk in the list
can be checked for application to a particular situation.
Risk charting:
This method combines the above approaches by listing resources at risk,
Threats to those resources Modifying Factors which may increase or decrease
the risk and Consequences it is wished to avoid. Creating a matrix under these
headings enables a variety of approaches.

6. Scope Risk
Some of the common sources which leads to scope Risk:
● Scope creep
● Hardware defect
● Software defect
● Scope gap (ill defined scope)
● Dependency change (unexpected legal, regulatory, etc.)
● Integration defect (change due to unexpected behavior)

7. Scope Risk
Scope Risk Key Ideas:
●Clearly define deliverable
●Ensure the value of the deliverable exceeds the scope of
work
●Define a work breakdown structure small enough to ensure
work is understood
●Assign ownership and determine reasons any items are not
accepted
●Note all risks, including non-quantifiable risks due to size or
complexity of project

8. Question that needs to be asked to
identify Scope Risk
●Is the Objective of the project clearly stated?
oeg: Increase response rate
oeg: Improve quality of data obtained
●Is the Objective short and concise?
●Is Objective agreed to by all stakeholders?
●Does requirement help achieve the Objective?
●Is the format for specifying the requirements have been
agreed upon by the client and Project team?
●Is the Author of the requirement identified?
●Does Author has domain as well as software development
knowledge?
●Is the good review Processes are in Place to identify the
details?

9. Question ...(contd)
●Is the language consistent ?
●Is Glossary of terms and Definition in the requirement
document created?
●Has the requirement verified by stakeholder?
●Is Requirement flexible to accommodate change as long as
objectives are still being met.
●Is requirement illustrative with the help of diagrams,picture or
sample data?

10. Schedule Risk
Some of the common source of Schedule Risk
●Parts Delays
●Estimation errors
●Decision Delay
●Hardware Delay
●scope change

11. Schedule Risk
Schedule Risk Key ideas:
●Estimates with wide variations should be investigated for
thorough understanding
●Identify source of estimates, especially if not empirical
●Identify high risk dependencies
●Compare estimates to historical values looking for large
variations
●Pull risk forward to allow time to react
●Identify all potential critical paths
●Note project duration risk

12. Question that needs to be asked to
identify Schedule Risk
What method of estimation has been used?
Whether used the right estimation methods in which our past
experiences has been ?
Have the Historical data been used?
Have the different factors in the historical data considered?
Have the skill of the resource assessed?
Have you considered the dependency of the project?
Is the org culture of the stakeholders considered?