Presentation-RA-R1-30-10-20

1. Risk Identification

2. Risk Identification
• Introduction
Projects function in an environment that is filled with uncertainty.
Concerning project funding, the availability of necessary resources,
shifting client expectations, potential technical issues, etc., there is
uncertainty. Project risks are based on this unpredictability, which
necessitates the use of risk management.

3. Risk Management Stages
a)Risk Identification for EMC Web Design Project.
• Incorrect Deadlines Set by a Client
• Generic Specification
• The Client Is Not Available to the Dev Team
• The Client Requires Too Much Communication
• Working in Offshore Teams Within the Same Time Zone
• Working in Separate Time Zones
• Compromising on Design
• Lack of Developers
• Unstable Workload
• No Testing
• No Post-Go-Live Support
• Not Choosing the Right Technology
• Integration of Popular Technologies
• Integration of New, Unproven Technologies
• Working on Existing Source Code

4. 1.Incorrect Deadlines Set by a Client
It frequently happens that a business analyst from the client's side has
established deadlines that are far harsher than the technical team from
the vendor's side anticipated. As a result, the vendor's team must put
in extra time or hire more personnel not included in the original
contract.
2. Generic Specification
There is a potential that a few features will be excluded from the project's scope if the project's specification is
too ambiguous or too limited. Because of this, additional project requirements will be introduced as the
project is being developed, deadlines will be missed, and overtime hours will accumulate, all of which will
undermine team morale.

5. 3. The Client Is Not Available to the Dev Team
The client must ensure that the requirements are correctly understood by
the development team as a project develops and that his expectations are
met. If there is insufficient communication between the two parties, there
may be delays in both providing the outcome and notifying about obstacles.
4. The Client Requires Too Much Communication
Active communication can also backfire if it occurs too frequently. It could result in pointless conversations, lengthy
technical explanations to non-technical persons, and going nowhere.
5. Working in Offshore Teams Within the Same Time Zone
This business risk has a small effect. Both teams may have different ideas
about how the product should be used if their technical leaders are strong.

6. • 6. Working in Separate Time Zones
Here is where there is a significant increase in risk. Teams are expected
to work together during the brief period when their working hours
coincide. For instance, 9 AM in New York corresponds to 5 PM in
Belarus, therefore there is a two to four hour time difference between
the teams. Overtime typically results from this.
7. Compromising on Design
Frequently, teams rush into performing "real" development activities
instead of taking the necessary steps in the design phase. However, the
entire process is a waste of dev hours without sufficient planning,
prototyping, and information architecture construction.

7. • 8. Lack of Developers
When resources are scarce, developers occasionally have to work on
numerous projects simultaneously. Bug-fixing tasks may divert
developers if a previous project's maintenance term is also still in
progress.
9. Unstable Workload
It is challenging to switch between the context of the two projects if
our workload is less than four hours per day per employee. When
crucial problems arise on two projects at once, the risk increases.

8. • 10. No Testing
Some clients want to avoid paying for QA by having developers test the
project on their own.
11. No Post-Go-Live Support
Once the project is online, the vendor's team frequently stops offering support or concentrates on the most
important problems, leaving smaller problems out of scope.
12. Not Choosing the Right Technology
During the project's discovery phase, selecting the technology stack and implementation team is perhaps the
most important choice you'll make. Each team possesses core expertise or experience in particular industries,
technologies, or products. One of the most common risks associated with custom software is relying too
heavily on a certain popular technology.

9. • 13. Integration of Popular Technologies
Integrations with third-party systems, plugins, or content management systems pose the majority of
vulnerabilities. If your staff is familiar with and comfortable using these tools and technology, the risk is
minimal. Popular libraries frequently have a strong community behind them, making it simple to find fixes for
emerging problems.
14. Integration of New, Unproven Technologies
A new technology may significantly raise the risk. You shouldn't expect the team to handle software integration
risks as rapidly as they do known ones.
15. Working on Existing Source Code
It's quite perilous to take over a project that's already been started using the existing source code. To boost
efficiency, the team must examine the source code, evaluate its quality, and pinpoint the components that
need to be refactored. In order to comprehend the project's overall flow, the team should also grasp it from
the perspective of its users.

10. Risk Assessment
• Introduction-
When conducting a qualitative risk analysis, the
probability/consequence matrix approach is a well-known method of
evaluating risk severity and can evaluate risks at all levels of the firm.
The probability/consequence matrix is a useful tool for assessing
hazards according to their seriousness by estimating their probable
consequences. This enables you to identify the key contributing causes
to each potential risk in addition to helping businesses better assess
the overall severity of a risk.

12. Risk Response
• Risk Response
• The risk response planning involves determiningways to Eliminateor reduced any threats to the project, and also the opportunities to increase their impact. Project Team should work to eliminate the threats before they occur. Similarly, the project managers should work to ensure that opportunities occur. Likewise, the project manager is also responsible to decrease the probabilityand
impact of threats and increase the probabilityand impact of opportunities.
• For the threats that cannot be mitigated, the project manager needs to have a robust contingency plan and also a response plan if contingencies do not work.
• It is not required to eliminateall the risks of the project due to resource and time constraints. A project manager should review risk throughout the project. Planning for risks is iterative. Qualitativerisk, quantitative risk, and risk response planning do not end ones you begin work on the project.
• Risk Response Strategies
• Avoid – eliminate the threat to protect the project from the impact of the risk. An example of this is cancelling the project.
• Transfer – shifts the impact of the threat to as third party, together with ownership of the response. An example of this is insurance.
• Mitigate – act to reduce the probability of occurrence or the impact of the risk. An example of this is choosing a different supplier.
• Accept – acknowledge the risk, but do not take any action unless the risk occurs. An example of this is documenting the risk and putting aside funds in case the risk occurs.
• There are also four possible risk responses strategies for positive risks, or opportunities:
1. Exploit – eliminate the uncertainty associated with the risk to ensure it occurs. An example of this is assigning the best workers to a project to reduce time to complete.
2. Enhance – increases the probability or the positive impacts of an opportunity. An example of this adding more resources to finish early.
3. Share – allocating some or all of the ownership of the opportunity to a third party. An example of this is teams.
4. Acceptance – being willing to take advantage of the opportunity if it arises but not actively pursuing it. An example of this is documenting the opportunity and calculating benefit if the opportunity occurs.

15. Risk Register