All language subtitles for KU PMGT 823 Session 2 (Part A)- Project Failures and Risks

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