Original subtitles

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.