Original subtitles

Hi everyone and welcome back. This is session two of our course, Project Risk

Management. Today we will be focusing on one of the most important parts of the

risk management process, planning risk management.

As the name suggests, we are going to look at how to design a clear and

structured approach from the very beginning of the project to identify,

and respond to risk effectively.

Let's start this section with something we all want to avoid, project failure.

In the world of project management, failure isn't always dramatic.

Sometimes it is less obvious, like delays, budget overruns, or unmet

expectations. But in almost every case, risks that were not properly identified

or managed play a big role.

So in this part, we are going to look at the connection between project failures

and poor risk planning and set the stage for why proactive risk management

really matters.

Project failures happen when a project does not fully meet the goals it was

meant to achieve. Even if a project succeeds in some areas, it can succeed

short in others.

Most of the common causes of failure are actually risks that were not properly

managed. Things like poor planning, unclear expectations, or lack of support

seriously impact a project's success.

By identifying these risks early, teams can take action to avoid failure and

improve their chance of delivering value.

That leads us to an important question.

How many projects actually fail? There is a common belief floating around that

75 % of all projects fail, but that number is often misunderstood.

It actually comes from a chaos report, and it mostly refers to large IT

projects, not all types of projects.

So in many cases, this number is exaggerated.

Now, if we look at what the report actually says, around 25 % of projects

canceled before delivering results.

About 50 % were considered challenge, meaning they were delivered late, over

budget or with reduced scope.

And only about 25 % were fully successful, meeting scope, time and cost

So the takeaway here is why failure isn't quite as dramatic as some people

think. There is still a huge room available for improvement, especially

better risk management.

This chart comes from a three -year study that analyzes 200 different

to categorize the schedule delays based on their root causes.

Some of the most common reasons include unforeseen technical problems, poor

effort estimation or relying too heavily on top -down scheduling, weak product

or system design, especially when it comes to integration, and frequent

in product definition.

As you can see, Especially technical problems and inaccurate planning cause

most significant delays in terms of engineering months lost.

This kind of data is really useful because it reminds us that the project

aren't just about bad luck. They often trace back to predictable, manageable

risks. And that's exactly what we are learning to handle in this course.

Based on what we have covered so far, we can group project failures into three

main categories.

Some projects are impossible from the beginning because they depend on

technologies that don't yet exist.

Others are over -constrained by timelines, budgets, or resources that

too limited to allow them for success.

In many cases, failure happens due to poor management such as unclear

weak leadership, or lack of coordination.

These three categories help us better understand the root causes of project

failure. In session three, we will expand on this and explore how different

types of risk fall within these categories.

Let's look at three common types of projects that are likely to fail.

The first example shows a technically impossible project.

A company tries to develop an anti -gravity device within a year, even

there is no scientific foundation that supports their idea.

No matter how motivated the team is, the project cannot succeed.

Second example is an over -constrained project.

An organization wants to move its entire financial system to a new database in

just two weeks using only part -time student workers and no budget.

The third example shows a poorly managed project where a team is developing a

mobile app, but unclear planning and weak follow -up cause delays and quality

issues.

us to the end of part a if you have any questions please feel free to reach out

thank you so much for watching this video and when you are ready go ahead

start part b