Original subtitles

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