Original subtitles

Hi everyone and welcome back to Part B of our Session 3 on Risk Identification

Projects. Let's get started this section together.

In this section of Module 3, we will focus especially on identifying scope

-related risks.

These are the types of risks that can arise when the scope is unclear,

and beyond what the organization is realistically able to handle.

We will break down common categories of scope risk, look at some real examples,

and discuss how you can proactively recognize them in your own project.

Let's get started with what these risks might look like and why they matter so

much.

One of the best ways to protect your project is to start strong, and that

recognizing risks early.

A poor project start can lead to delays, rewards, stress for the team, and

sometimes even failure.

Interestingly, most project risks can be identified right at the beginning,

especially those related to a scope.

In fact, when we talk about the triple constraint, scope, schedule, and

resources, a scope risk is often the first concern that surfaces.

That's why early identification is so important.

If the project scope is unclear or unrealistic, it is better to address

front or even walk away if it is not feasible.

Scope risks usually fall into four main categories.

First, we have scope gaps.

This happens when the project starts before requirements are fully clear.

You move forward, but then discover missing needs later, forcing change in

stream. Then there is scope creep, probably the most familiar one.

This refers to small unofficial additions to the project that are added

time, often without proper analysis or approvals.

Scope dependencies are risks.

tied to the external factors like regulations, infrastructure readiness,

platforms that can impact the scope and need to be actively managed.

Lastly, we have defect risks, which include software bugs, hardware failure,

integration issues that disrupt how project components work together.

Let's look at some data to understand how significant scope risks really are.

According to the Project Experience Risk Information Library, or PERIL, scope

risks make up more than 40 % of all recorded project risks.

Even more striking is that scope -related risks account for almost half

total schedule impacting projects.

PERIL groups these scope risks into two major categories, chains and defects.

Among the chains, scope gaps where legitimate requirements are discovered

are the most frequent one but when it comes to damage a scope creep stands out

as the most harmful overall so if you are wondering where to focus your risk

identification efforts this data gives you a pretty clear answer

Let's look at a real -world example that shows both scope gap and scope creep. A

project aimed to develop an HR system for a large organization, including

payroll, lift tracking, and training.

Initially, only payroll and lift tracking were included.

Midway through, the HR manager realized training records were also needed.

This missed but valid requirement was a scope gap and caused delays as the team

had to design a new feature.

Later, a scope creep happened when a department manager unofficially asked

an employee satisfaction survey to be added just because they were already

building a system.

The team agreed without proper analysis and checking resources.

That unplanned change led to extra costs, more complexity, and added

This project faced both a missed requirement and an unapproved addition,

are common scope risks.

Now let's talk about black swan risks.

In project management, a black swan is a rare and highly unpredictable event,

something you didn't expect, but that has massive consequences when it

What is tricky is that these risks often seem obvious only after the fact.

You will hear things like, we should have seen this coming.

Looking at the table here, you will notice that creep, gap, and software

are the top contributors to total impact, each with more than 60 % of

impact attributed to black swan events.

In fact, across all the categories combined, 59 % of total impact weeks

from these rare but severe surprises.

So the lesson here is even if a risk looks unlikely, that doesn't mean it is

unimportant. Always make a room in your planning to monitor and prepare for such

unexpected events.

To manage a scope risk effectively, there are a few key steps that project

should take.

They start by clearly defining deliverables and documenting any known

early on.

Then set realistic boundaries based on the value and priority of each

deliverable to avoid overcommitting.

Break the project into smaller parts to uncover unclear or risky areas.

Assign clear ownership for each risk, as unclear responsibilities often cause

issues.

Finally, watch for risks linked to time or complexity.

Even simple -looking projects can hide technical or scheduling challenges.

These practices help you stay ahead of scope -related, problems

and this brings us to the end of part b where we explore different types of

project scope risks and how to identify them early on thanks for watching this

video and see you in the next part