a risk is a potential event that might occur and could impact your project

A project risk might be a contractor missing a deadline, or introducing a tool that

may lead to a communication breakdown within your team, or unexpected, additional
work because of an unforeseen policy being put in place. When any risk occurs, the
consequence is a change to the project plan.

A change is anything that alters or impacts the tasks, structures, or processes

within a project. Changes are typically unexpected

. Changes can encompass any variance from the original project plan in regards to
the triple constraint. This may entail changing priorities and scope, budget and
resources, or changes to the project timeline.

some examples of changes may include new or changing dependencies. Dependencies are
tasks, activities, or milestones that are reliant on one another. So if one task
isn't completed on time, it may put your other tasks behind.

Next up, the capacity and people available could change

type of change could include a new limitation on your budget or resources.

Another change could be scope creep. Scope creep is when changes, growth, and other
factors affect the project scope.

Dependencies are the links that connect one project task to another, and as we
mentioned, they're often the greatest source of risk to a project. Two or more
project tasks may have a relationship with one another in which the completion of
one task is reliant on the initiation of another task, and vice versa.

Mandatory dependencies are tasks that are legally or contractually required.

Dependency management is the process of managing all of these interrelated tasks

and resources within the project to ensure that your overall project is completed
successfully on time and in budget. To pursue effective dependency management,
there are four important steps that a project manager can take: proper
identification, recording dependencies, continuous monitoring and control, and
efficient communication.

A risk register is a table or chart that contains your list of risks and
dependencies. The risk register should include a description of the dependency, the
date, and all activities or tasks that may be impacted by the dependency.

Risk management is the process of identifying potential risks and issues which
could impact a project, then evaluating and applying steps to address the effects
of the identified risks and issues.

Brainstorming with your team is one of the most effective techniques for
identifying risks in a project

Risk exposure is a way to measure the potential future loss resulting from a
specific activity or event

two variables: risk impact and probability. Write "risk impact" at the top,
horizontal axis, and write "probability" on the side, vertical axis. Mark high,
medium, and low along each axis as well, across the top from left to right and down
the side from top to bottom, because that's how you're going to chart risk exposure

The ROAM technique—which stands for resolved, owned, accepted, and mitigated—is
used to help manage actions after risks arise.

Once a risk has materialized, you need to decide what to do with it. If a risk has
been eliminated and will not be a problem, it goes into your "resolved" category.
If you give a team member ownership over a certain risk and entrust them to handle
it, that risk goes into the "owned" category and is monitored through to
completion. If the risk has been "accepted," it has been agreed that nothing will
be done about it. Finally, if some action has been taken such that the risk has
been mitigated, either reducing the likelihood of it occurring or reducing the
impact to the project, it goes into the "mitigated" category.

After each risk is placed into a category, the team will discuss each risk and
decide which should be prioritized.

Escalating issues:

Escalation is the process of enlisting the help of higher-level project leadership

or management to remove an obstacle, clarify or reinforce priorities, and validate
next steps. Escalation may seem to have a negative connotation, but that's not the
case in project management.

A project manager should escalate an issue at the first sign of critical problems
in the project. Critical problems are issues that may cause a delay to a major
project milestone, issues that cause budget overruns, issues that can result in the
loss of a customer, and issues that push back the estimated project completion
date.

Escalation is great for preventing two common issues within a project: trench wars
and bad compromises. Trench wars occur when two peers or groups can't seem to come
to an agreement, and neither party is willing to give in. This leads to a
standstill of the project and will likely delay certain aspects of the project's
progress.

A bad compromise occurs when two parties settle on a so-called solution, but the
end product still suffers. When it comes to compromising on important project
goals, it's not productive for either party to settle simply because it's a means
to an end.

As a project manager, when communicating a small change that will affect an

individual, it's a good idea to send an email.

A timeout means taking a moment away from the project in order to take a breath,
regroup, and adjust the game plan. A timeout may temporarily disrupt your momentum,
but it may be absolutely necessary to set you up for success in the long run.

Retrospectives are held throughout the project's life cycle. A retrospective

focuses on identifying the contributing causes of an incident or pattern of
incidents without blaming one individual.

Effective escalation emails:

Maintain a friendly tone

State your connection to the project

Explain the problem

Explain the consequences

Make a request

Decisions required to improve delivery rate to at least 90% for successful launch
of Plant Pals.