All language subtitles for KU PMGT 823 Session 3 (Part B)-Identifying Scope Risks

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