All language subtitles for KU PMGT 823 Session 5 (Part B)- Contingency Planning and Risk Documentation

Hi everyone and welcome to Part B of
Session 5 in PMGT 823, Project Risk

Management. In this part, we will
continue exploring the plan risk

process with a focus on contingency
planning and risk documentation.

Let's dive into it.

In this part of Module 5, we will
explore how to prepare backup plans for

uncertain situations and how to document
risk responses clearly within the

project. Both of these are key to making
sure your plans are understood and

successfully carried out.

A contingent response strategy is a
backup plan that only gets activated if

certain conditions happen.

These strategies are useful when the
team expected enough warning to act in

time. The condition that triggers the
response is known as a trigger.

These strategies are also called
conditional responses.

Triggers can include things like missed
deadlines, quality issues, or vendor

delays. They help the team stay ready
without committing too many resources

upfront.

Contingency plans are common in projects
where there is uncertainty, but it can

be anticipated.

These plans help teams get ready for
possible disruptions by defining actions

ahead of time.

For example, a construction team might
prepare a backup supplier in case the

primary vendor fails to deliver
materials on time.

A software team may assign a backup
developer in case a key engineer leaves.

a logistics company might plan a backup
route in case of road closures or other

local disruptions. These examples show
how planning ahead helps teams stay on

track even when surprises happen.

this table shows some common project
triggers along with suggested

plans each trigger represents a specific
situation that could lead to a risk

like technology failures or a shortened
project timeline instead of just listing

the possible outcomes this version
focuses on what the team can actually do

response for example if a key technology
fails the team might use a backup

option they have already tested or if
their schedule is compressed they can

identify tasks to scratch crash, and
prepare extra resources in advance.

These plans help the team stay ready
without overcommitting and ensure the

project keeps moving even when things do
not go as expected.

Both contingency and fallback plans are
reactive strategies used in uncertain

situations. But what are the differences
between them?

Well, a contingency plan is triggered
when a specific condition happens and

answers the question, what if this
occurs?

But a fallback plan is used when the
original response fails and answers what

nothing goes as planned.

Together, they provided layered
protection against risk and uncertainty.

Both plans should clearly define
resources, timing, and the path for

Sometimes when we respond to a risk, we
might unintentionally create new risks.

These are called secondary risks, and
they happen as a direct result of the

response itself.

Some tweets may also remain even after
we have taken action.

These are called residual risks, and
they reflect what is left over after the

response is complete.

Both secondary and residual risks should
be documented and accessed, like any

other risk in the project.

Once you define your response triggers
and new risks, you need to update the

risk register and other related
documents.

This helps the whole team stay aligned
and ensure everyone is working with the

most current information.

You should update the risk register with
details like strategies, triggers,

fallback plans, and secondary risks, if
possible.

The project schedule may also need
change to reflect contingency

resource calendars or team assignments
should be adjusted if responsibilities

shift.

In this example, Daniel is leading a
hospital renovation project and sharing

lessons learned with his team.

Early on, they identified a risk of
delay in medical equipment delivery, so

created a contingent response plan. The
trigger was missing the shipping

confirmation, and the response was to
contact the backup supplier.

They also had a fallback plan to borrow
emergency stock from a university

warehouse in case the first plan failed.

Fortunately, the main plan worked, but
knowing they had a fallback increased

their confidence.

Later, they discovered a secondary risk
when the backup supplier was unfamiliar

with the hospital procedures.

This caused delays and required extra
training, which they document as a new

risk. Daniel explains how they updated
the risk register.

project schedule, and resource
assignments to reflect all changes.

He ends by saying not everything went
exactly as planned, but planning ahead

keeping documents updated helped keep
things on track.

And this brings us to the end of Part B.

we have explored how to design
contingency and fallback plans and how

project documents as new risks emerge if
you have any questions feel free to

send an email or share them on the
discussion board thank you very much

for watching this video and when you are
ready please continue to part c