All language subtitles for KU PMGT 823 Session 3 (Part A)-Identifying Risks Process

Hi everyone and welcome back to PMGT
823.

In today's session, we will focus on one
of the most important stages in risk

management, that is identifying risk.

This is where everything begins.

If we don't know what risks we are
facing, we cannot manage them

So in this session, we will explore how
to identify potential risks in a

structured, thoughtful way.

We will use proven tools, examples, and
a case study.

So let's get started together.

Alright, let's dive into Part A of
Module 3, the process of identifying

In this section, we will walk through
the steps that usually project teams

to recognize and document potential
risks before they become problems.

Understanding this process is key to
managing uncertainty in any project, and

is one of the most foundational skills
in project risk management.

So let's take a closer look at how this
process works in real -world project

settings.

Now let's get into the process itself.

Identifying risks is actually the second
step in project risk management, and it

is a critical one.

In this step, we aim to identify both
individual risks and the overall source

uncertainty in a project.

What is important here is not just
listing risk randomly.

We are documenting their
characteristics, potential causes, and

impact our objectives.

as shown in this diagram we will use
specific inputs like the project

plan and historical data and apply tools
like brainstorming interviews and root

cause analysis and generate key outputs
such as the risk register we will break

this down together throughout the next
slide

deeper into risk identification it is
important to recognize the range of

we are looking for this process is not
just about spotting isolated issues it

includes identifying broader sources of
uncertainty that can affect the whole

project we are aiming to capture both
individual risks such as a delayed

shipment or a miscommunication with a
vendor and systemic risks such as

organizational culture or unclear rules
that can amplify uncertainty over time

Clear documentation at this stage lays
the foundation for effective analysis

a well -targeted risk response that
comes later.

Risk identification isn't a solo
activity.

It is a collaborative process that
brings together people from different

perspectives. Of course, the project
manager and project team members are at

center of this. But ideally, we also
involve customers, end users, and

matter experts who can help us but risk
that we might overlook.

Even people outside the core team like
other project managers or operations

managers can offer valuable insight.

It is important that all stakeholders be
encouraged to speak up about potential

risks, especially those tied to their
own areas of expertise.

But at the same time, we should never
rely too heavily on SMEs.

One important thing to keep in mind is
that risk identification isn't a one

-time task.

It is an iterative process that
continues throughout the project

As project evolves, new risks may
emerge, and our understanding of

risks may also change.

That's why ongoing monitoring on risk is
very essential.

The frequency of risk identification and
who participates in each cycle or phase

depends on the project size, complexity,
and risk profile, and it should all be

defined in our risk management plan.

As you can see in the diagrams below,

This applies across both waterfall and
agile approaches.

In both cases, risk identification needs
to happen regularly, not just at the

start of the project. So remember, risk
identification isn't a box to check. It

is a habit to maintain.

To identify risks effectively, we need
solid information, and here we outline

where that information usually comes
from.

first we rely on project management plan
especially components like schedule

cost and risk management plans these
give us context and structure then we

baselines like wbs schedule and cost
baselines which helps us spot where

might go off track project documents
such as assumption log and issue log

contains clues about potential risks

Contracts and agreements are another key
area. Look for hidden risks in

milestone dates, penalties, or vague
terms in contracts.

We also use procurement documentation
and also enterprise environmental

like industry reports and organizational
process assets like lessons learned and

templates from past projects.

Let's take a quick look at the main
categories of risks you will likely

encounter in a project.

First, we have scope risks. These relate
to things like unclear requirements,

technology challenge, or unrealistic
capabilities.

Then there are change and defect risks,
often tied to evolving specifications or

quality issues.

We also have schedule risks, which can
stem from inaccurate time estimates or

unreliable suppliers.

And finally, resource risks.

which include anything from staffing
shortage or missing equipment or

facilities. These categories help us
organize our thinking and guide the

identification process, and we will
explore each of them more in the

sections.

When it comes to identifying risk,
sometimes the hardest part is knowing

to start.

Here we have a list of great sources to
help generate ideas.

For example, industry and government
databases often provide risk checklists,

case studies published articles or
professional societies like PMI can

-to -date insight from across the field
don't forget about looking sideways at

your competitors what risks have they
encountered and internally your

suppliers team members and even
management are all valuable voices in

potential risks the key message here is
that don't try to do this alone There is

a wealth of information already out
there, and you just need to know where

start.

When it comes to identifying risks,
there's not just one way to do it. As

can see, we have a whole toolkit
available.

It often starts with expert judgment,
tapping into people who have seen

projects before and know where teams can
go wrong.

We also use a range of data gathering
techniques like brainstorming,

and interviews.

Tools like the affinity diagram help
organize those ideas visually.

Then comes data analysis, including root
cause analysis and SWOT.

These can help us dig deeper into what's
driving potential risks.

Don't underestimate the power of
interpersonal and team skills or simply

up structured meetings to gather
insights from stakeholders.

After we identify risks, the next step
is to make sure everything is documented

properly, and that's where these outputs
come in. The assumption log captures

the assumptions and constraints that may
influence risks, and it is updated as

new insights emerge.

The issue log is used to track problems
as they arise, whether they are project

-related or risk -related, and it
evolves as the situation changes.

Then we have the risk register, which is
really the heart of risk documentation.

It includes all identified risks, along
with important information like

probability, impact, and assigned risk
owners.

And finally, the risk report.

The risk report gives a high -level view
of the most significant risks and any

conclusions we have drawn through this
analysis.

Now let's zoom in on one of the most
important outputs from the risk

identification process, that is the risk
register.

Once risks are identified, they are
recorded here at initial entry.

But this document isn't static.

It grows and evolves over time. At this
stage, your register should include a

list of identified risks, probability
and impact of each, possible response

strategies, root causes, and any updates
to your risk categories.

This register becomes a central place
for tracking and managing risks

the entire project.

Here you can see a more detailed example
of what a real -world risk register can

look like. This one is modeled after a
PMI style format.

As you can see, it includes much more
details than just a list of risks.

It tracks information across the entire
project lifecycle, from identification

through analysis, planning, and
monitoring.

As you can see, it includes crucial
information about each identified risk.

What is important here is that this
register isn't just a document. It is a

leading tool used to guide decision
making and keep the project team aligned

risk responses.

Soon we will see a sample of how it can
be applied in a real project.

This is a sample risk register report
which expands on the risk register by

offering a more detailed structured
summary.

It includes things like task titles,
dates, descriptions, risk scores,

and mitigation actions.

As you can see, all of them are laid out
in a formal reporting format.

This kind of report is especially useful
for communicating with senior

stakeholders or sponsors who want a
clear snapshot of where risks stand.

Notice how risks are categorized by
impact level and supported with

strategies. This helps project leaders
quickly focus on what needs attention

why.

And that brings us to the end of Part A
of our session on identifying project

risks. If you have any questions or need
clarification on anything we covered,

feel free to reach out, and when you are
ready, please continue to Part B.

Thanks again for watching this video.