---
title: 'Project Risk Management Explained | What Is Project Risk Management? | Simplilearn'
source: 'https://youtube.com/watch?v=o1Ne5ySIGHk'
video_id: 'o1Ne5ySIGHk'
date: 2026-10-24
duration_sec: 2535
channel: 'Simplilearn'
---

# Project Risk Management Explained | What Is Project Risk Management? | Simplilearn

> Source: [Project Risk Management Explained | What Is Project Risk Management? | Simplilearn](https://youtube.com/watch?v=o1Ne5ySIGHk)

## Summary

This video provides a comprehensive introduction to project and risk management, covering fundamental concepts like project definition, lifecycle phases, scope, time, cost, quality, and the difference between risks and issues. It emphasizes the importance of structured planning and proactive risk management for successful project delivery.

### Key Points

- **What is a project?** [03:55] — A project is a temporary piece of work with a specific goal; it has a beginning and an end, unlike ongoing operations.
- **Definition of project management** [05:41] — Project management involves planning, organizing, executing, monitoring, and completing a project to achieve its objectives successfully.
- **Project constraints** [08:41] — The four major constraints are scope, time, cost, and quality, which are interconnected and must be balanced.
- **Project life cycle stages** [11:16] — Five phases: initiation, planning, execution, monitoring and control, and closure.
- **Project charter explained** [14:43] — A project charter defines why the project exists, its objectives, stakeholders, and authority.
- **Setting SMART goals** [16:39] — SMART goals (Specific, Measurable, Achievable, Relevant, Time-bound) provide clear direction.
- **Importance of scope management** [17:33] — Scope defines boundaries; uncontrolled additions lead to scope creep, harming the project.
- **Work Breakdown Structure (WBS)** [20:02] — WBS breaks a large project into smaller, manageable pieces for better estimation and tracking.
- **Project milestones** [22:50] — Milestones are significant points that help track progress at a high level.
- **Risk vs. issue; threats vs. opportunities** [31:30] — Risk is an uncertain event; an issue has already happened. Threats are negative risks, opportunities are positive.
- **Risk appetite, tolerance, threshold** [34:56] — Risk appetite is the willingness to take risk; tolerance is acceptable variation; threshold is the point for action.
- **Risk management lifecycle** [37:44] — The lifecycle includes identify, analyze, plan response, implement, and monitor.

## Transcript

ever wondered how successful projects are planned, organized, monitored and completed while also dealing with unexpected problem along the way, then this course is a great place to begin. Now projects are everywhere. Launching a
application, organizing an event, setting up a new office or even introducing a new process inside a company can all be managed as projects. successfully is not just about finishing a list of task. You also need to manage
time, budget, scope, quality, people, communication and most importantly uncertaintity. And that's exactly where project management and risk management we are going to start from the absolute basics. So even if you have never worked
on a project before, you'll be able to follow along comfortably. So whether you're a student, a work professional, a new project manager, a team lead, or simply someone looking to understand the fundamental of managing project and
risk, this course will give you a strong foundation. Now before we move on, let me share something exciting with you guys. If you are serious about building a strong career in project management, then the PMP certification training in
collaboration with Simply Learn can be a great next step for you. This course is designed to help you understand project management in a practical structured and important concepts like project planning, work breakdown structures,
resource allocation, GN chart, risk and issue management, stakeholder communication, cost and budget planning, schedule management, agile and hybrid delivery, leadership, governance and value based project delivery. What makes
this course even more useful is that it also covers modern project management skills like genai in project management, sustainability, business value and real world decision-m. So whether you are a project manager, team lead, software
developer, project executive, engineer or someone who wants to move into you build the confidence, structure and and grow in your career. So without wasting any further time, let's get
wasting any further time, let's get started. including what a project is, how project management works and how project move through their different life cycle. Moving ahead, we'll also cover project
charters, goal setting, scope management, work breakdown structure, scheduleuling, milestone, budgeting and resource planning. We will then explore including risk versus threat versus issues and opportunity, tolerance and
threshold. After that we will understand how to identify, analyze, prioritize and respond to risk using tools such as risk registers, probability and impact analysis. Finally we will cover stakeholder management, project
communication, performance monitoring, change management, escalation and a real change management, escalation and a real world project and risk management case. module which is project management fundamentals. Now before we get into
planning, risk management, shoulduling of any of the more advanced concept, we of project management and meaning if you're completely new to this field, because almost everything we discuss later will connect back to the concept
covered in this particular lesson. So moving ahead we are going to understand what exactly a project is. What project management means. The major objective and constraint that every project needs to balance. How a project moves through
finally we will look at three common ways project can be managed which is predictive, agile and hybrid. And don't worry if some of these terms sound very technical right now. We will break them using simple examples so that even if
you have never managed a project before, you'll still be able to understand of how all this work. So starting up with what is a project. Now let us begin with a very basic question. What exactly is a project? Now in simple term a project is
a temporary piece of work that is carried out to create a specific result. Now the word temporary is very important here. A project has the beginning and end. It doesn't continue forever. For example, building a new mobile
new website is a project. Constructing a bridge is a project. Organizing company event is also a project. Even something like moving an office from one location In all of these example, there is specific goal that needs to be achieved.
There are people involved, resources are required, usually a deadline is there and once the desired result has been delivered, the project comes to an end. regular operation. Let's take a simple example. Suppose a company is launching
a new online shopping website. Designing and developing that website is a project because it has a clear start, a target, launch date, defined budget and a final outcome. But once the website is launched, activities such as processing
customer orders every day, responding to customer queries and maintaining the website become ongoing business operation. So seeing this difference is important. Project are temporary and goal oriented whereas operation are
continuous and repetitive. Now another important thing to understand is that every project is created for a reason. A company doesn't normally start a project something new. There is always a business requirement or a problem that
needs to be solved. A company may want to launch a new product to enter a new market. It may want to automate an existing process to reduce cost. It may need to upgrade its IT infrastructure to improve security or it may even want to
build a new office to support business. So in simple term project starts with a need and end when a specific outcome has been delivered. Now that we understand what a project is the next big question is what is a project management? Now
project management is basically the process of planning, organizing, executing, monitoring and completing a project so that its objective can be achieved successfully. Meaning having a good idea is not enough. You need to
decide what exactly needs to be done, who is doing what and how much time it will take, how much it will cost and what resources are required. What could go wrong and how you're going to track the progress. Now let us take a simple
example. Suppose a company decides to launch a new mobile application within 6 months. Now someone has to define what features the application should include. Someone has to create the design. Developer have to build it. Tester need
to test whether everything is working correctly. Then marketing team may may need to prepare the launch campaign. Budgets have to be approved. Deadlines need to be tracked and different team have to communicate within each other.
If all of these activity happen without coordination, the project can become chaotic very quickly. And that is exactly where project management comes in. Project management provides structure. It helps everyone understand
what needs to be happened, why it needs to happen, who is responsible for making it happen. A project manager therefore is not simply someone who creates meeting or follow-ups on deadline. A good project manager connects people,
task, timeline, budget, risk and business goal. They constantly look at the bigger picture while also making sure that individual activities are ahead, one of the most important thing is about decision making. Project really
go exactly according to plan. A vendor may deliver something late. A team customer may suddenly request an technology may fail. So the project manager need to continuously evaluate
what is happening and decide how the project should respond. That is why project management is not simply about creating a plan at the beginning. It is about managing the project from start to end. Now let us talk about project
objective. Every successful project should have a clear objective and objective tell us what the project is actually trying to achieve. For example, saying we want to improve our website is quite vague. But saying we want to
redesign our e-commerce website and launch it within four month to improve the customer purchasing experience gives us more clear direction. Now a good project objective should ideally be clear and measurable. If the objective
is unclear, different team members may interrupt the project differently. One person may think speed is priority, another may focus on quality and someone else may think reducing cost is the main goal. So right from the beginning
everyone should understand what success actually looks like. For example, if the learning platform, success could mean launching the platform by particular users, delivering specific learning features, staying within the approved
budget and meeting a defined quality standard. So meaning a project objective becomes the destination that everyone is working towards. Now this brings us to the project management which is scope, time, quality and cost. You can think of
these as the major areas that a project manager constantly need to balance. Now let us begin with scope. Scope define exactly what the project will deliver and equally important what it will not deliver. Let us say you're developing a
food delivery application. The agreed scope may include customer registration, restaurant listing, online payment, order tracking and customer reviews. Now halfway through the project someone says why don't we also add grocery delivery
table reservation and a loyalty program. Those idea may be useful but they were not necessarily part of the original project. If we keep adding new schedule, budget or resource the project
can quickly become difficult to manage. This is often called the scope creep. So defining the controlling scope is extremely important. Now moving ahead we have time. Every project usually has a deadline. The mobile application may
need to launch in six months. The building may need to be completed by December. The company event may need to happen on a fixed date. Project manager therefore break the work into activities. Estimate how long those
activity will take. Identify dependency and create a schedule. If one important activity gets delayed, it may affect several other activities that depend on it. Next comes the cost. Project require money. There may be employees cost,
software cost, vendor cost, equipment cost, travel expenses, infrastructure cost and many other expenses. So if the project manager needs to make sure the project can achieve its objective without unnecessarily exceeding the
approved budget. And then we have equality. Completing something quickly and cheaply doesn't really help if the final result doesn't work properly. application exactly on the time and within the budget. Whenever customer try
to make a payment technically the deadline and budget may have been met but we shouldn't call that successful project. So equality measure what we deliver actually meets the required expectations. Now here's where project
management becomes interesting. These areas are connected. Suppose you increase the scope by adding more feature. You may need more time or more money. Suppose the deadline is suddenly reduced from 6 month to 4 month. you may
need additional people which increases cost or perhaps the team tries to work faster. So project management is really about balancing these competing requirement and making sensible decisions. Now that we understand these
fundamental, let us look at how a project actually move from an idea to described through the project life cycle. While organization may use slightly different terminology, a simple way to understand the project life cycle
is through five stages which is initiation, planning, execution, monitoring and control. Now let us start with the initiation. This is where the project idea is evaluated. We ask questions such as why are we
doing this project? What problem are we trying to solve? What value will the stakeholders? Is the project actually feasible? So initiation is basically about understanding whether the project makes sense and establishing its overall
direction. Now once the project is approved, we move into planning and planning is one of the most important stages because this is where we decide how the project will actually be delivered. We define the scope, create
schedule, estimate cost, identify resource and assign responsibility, identify risk, establish communication methods and decide how progress will be measured. Meaning if initiation tells us where we want to go, planning creates
the route for getting there. Moving ahead, we enter execution. This is where write the code, engineering construct buildings, designer create design, marketing team develop campaigns and
project team produces the required deliverables. The project manager coordinate activity, remove obstacle, communicate with stakeholder and make sure the team has what it needs to perform the work. At the same time, we
also have monitoring and control and this doesn't necessarily happen only after execution. It usually happen alongside execution. The project manager continuously compare actual progress with the original plan. Are we on the
schedule? Are we within the budget? Is the quality acceptable? Have any risk appealed? a stakeholder requesting any changes. If something is going wrong, corrective actions may be required. Finally, we reach the closure. Once the
project work has been completed and the deliverables has been accepted, the project can formally close. During the closure, teams may complete documentation, hand over final deliverable, close vendor contract,
release project resource, and capture lesson learned. And that last point is particularly useful. Lessons learned help future teams understand what went well, what went wrong and what could be done differently next time. So seeing
the whole life cycle together, we have initiate the project, plan the work, execute the plan, monitor the performance and finally close the performance and finally close the project.
fundamental of project management, the next logical step is to understand how a moved into execution. In the previous module, we looked at what a project is, what project management means, how
scope, time and cost are connected and how project moves through its different life cycle. Now, so moving ahead, this module is where we start turning the theory into something much more practical because meaning having a
project idea is one thing, but converting that idea into clear plan that people can actually follow is where project management really begins. So in understand project charter, goal setting, scope management, work
breakdown structure, project shoulduling, milestone, budget planning, resource planning and finally some important basics of project execution. And again we'll keep everything simple and practical so that even if you are
completely new to project management, you can follow the complete flow without any doubt. Now let us begin with project charter. Now project chart sounds like a very formal document but the basic idea behind it is actually quite simple. It
is a document that officially define why the project exist, what is expected to achieve, who is involved and who has the authority to manage it. You can think of it as a project starting point before a team starts creating detailed schedule
or assigning hundreds of task. Everyone needs to understand the bigger picture. problem are we trying to solve? What outcome do we expect? Who is responsoring the project? Who is responsible for managing it? And what
are the major limitation or assumptions we already know about? Now let us take a very simple example. Suppose a company wants to launch a new employee learning portal. The project charter might explain that the goal is to create a
centralized online platform where employees can access training program, track their progress and complete mandatory courses. Now here it may mention that the project needs to be completed within six months that the
estimated budget is a certain amount that HR department is the project sponsor and that IT team will support development and integration. It may also identify the key stakeholder and major rift that are already visible at the
beginning. Now seeing this example you can probably understand why the project charter is useful. Without it different people may have completely different expectations. The HR may think that the project is mainly about compliance
training while the technology team may assume that the priority is building a sophisticated learning platform with many advanced feature. The finance team may believe that the objective is to reduce training cost so that the charter
bring everything back to one common understanding. Moving ahead alongside project goal and this is extremely important because vague goals create vague project. For example, saying we want to improve customer service is not
a very strong project goal. Improving it by how much, by when, in what area. Instead, a clearer goal could be reduce the average customer support response time from 12 hours to 4 hours within 6 months. Now, we have something specific
that we actually want to measure and this is where you may hear about smart goal. Smart generally stand for specific, measurable, achievable, relevant and time bound. Meaning instead of setting a broad objective, you define
exactly what needs to happen, how success will be measured, whether the goal is realistic, why it matters, and when it should be achieved. So if your project goal is to launch a mobile application, a better version could be
launch the first version of the application with five core feature by the end of third quarter while staying within the approved budget. That is much clearer and gives the team a target to work toward. Now once the project goal
is clear the next major question is what exactly are we going to deliver and this is where scope management comes in. Scope defines the boundaries of the project. In simple term it tells us what is included and what is not. Now this
may sound obvious but unclear scope is one of the biggest reasons project becomes difficult to manage. Now let us continue with our employee learning portal example. The project scope may include user login, course browsing,
video lessons, quizzes, completion tracking, and basic report for HR managers. But perhaps live virtual classroom, advanced AI recommendation and external certification integration are not part of the first phase. Clearly
defining this at the beginning help team understand what they are responsible for delivering. So now as project move forward, people often start requesting additional features. A stakeholder may say, can we also add this? Another may
say this could be easy let us include it as well and another team may request a new integration. One small request may not look like this a big issue but if project suddenly the team may be trying to deliver twice as much work within the
same budget and deadline. This is what we call scope creep. Meaning scope creep happens when the project keeps expanding without properly evaluating the impact of those addition. So scope management does not always mean no changes are
allowed. Project can absolutely have changes. The important thing is that changes should be controlled. If a new feature is requested, the team should require. Do we need additional resources? Will another feature need to
be removed? What risk does this create? That way changes become conscious decision instead of simply being added to the team's workload.
project scope we need to turn that scope into actual work and this is where the work breakdown structure commonly called as WBS becomes very useful. Now the idea very simple. Take a large project and break it into smaller manageable pieces
because when someone says build a new website that sounds like one task but obviously it is not. There may be a dozen or even hundreds of activities behind it. For example, a website project could be divided into areas such
as planning, design, development, tasting, content creation, deployment and then each of those areas can be broken down further. Design may include wireframes, homepage design, product page design, mobile design and design
approval. Development may include front- end development, backend development, database, API integration and authentication. Testing may include functional testing, mobile testing, performance testing, and bug fixing. So
meaning that WPS creates a hierarchy. At the top you have the overall project. Under that you have major deliverables or work areas. Under those you have smaller work packages or task. Now this is extremely helpful because large
project can feel overwhelming. But when you divide them into smaller pieces suddenly the work become easier to estimate, assign, schedule and track. Now let us take another very simple example. Suppose you're organizing a
corporate event. The project may look simple at the first but a WBS could break it into venue, speakers, marketing, registration, catering, technical setup, and event day operation. Then the venue could be
broken down into finding options, comparing cost, visiting location, negotiating contracts, and confirming the booking. Marketing could include email campaign, social media promotion, banners, and registration reminders. So
the WBS helps answer the question what exactly needs to be done to deliver this project successfully. Now that we have identified the work, the next question is when should all of this happen? This brings us to projectuling. Project
shoulduling means deciding when different tasks should start and finish, how long they will take and what order they need to follow. Now the order part is particularly important because not every task can begin at the same time.
example, if you're building a website, the development team may need approved design before they can start implementing the user interface. Testing cannot begin until at least part of system has been developed and launch
cannot happen until testing and approval are completed. Now these relationships are called dependencies. So when building a schedule, the project manager looks at the list of activities and ask question like how long will each task
take? Which task need to happen first? Which activities can happen at the same time? Which one depends on the earlier work? Who is responsible for each task? And where could delays create problem? Now let us say a project has five
activities. Task A takes three days. Task B can only begin after task A and task C can happen at the same time. Task D depends on both B and C and task A is the final approval. A schedule help the team understand the sequence and
delayed. Now project schedules can be very simple or very detailed. For example, a small project a spread treat or task board may be enough. For larger project, teams may use GAN chart,
dedicated project management software or agile boards. But again, the tool is not the most important part. What matter is visibility. Everyone should understand what needs to happen, when it needs to happen and how their work connects with
the rest of the project. Moving ahead within project schedule, we also have milestone. A milestone is a significant point or achievement in a project. Unlike a normal task, a milestone generally represents an important event
rather than a piece of work with the long duration. Now, for example, design approved could be a milestone. Beta version released could be a milestone. Construction foundation completed could be another milestone. Client acceptance
received could be a milestone. Now, milestones are useful because they make larger projects easier to understand. And at higher level, senior stakeholder may not want to look at all the schedule containing 500 task. They may simply
want to understand whether the major milestones are being achieved on time or not. Now let us say a six-mon software project has four major milestones. Requirement approved by the end of the month, prototype completed by month two,
beta version ready by month four and final launch in month six. Now project is moving in the right direction or not. So in simple term task tell us what work is happening while milestone tell us when something important has
very practical part of planning the project budget. Every project consumes resources and most of those resources have a cost. So budget planning is about estimating how much money the project is expected to require and then controlling
that spending as the project progresses. Now project cost can include many things. Uh there may be employee salaries, contractor fees, equipment purchase, software license, cloud infrastructure cost, traveling cost,
venue charges, marketing expense, training cost, material and vendor payments. Now let us take a simple example. Suppose you're building a small mobile application. You may need two developers, one designer, one tester,
cloud hosting, software tool, and perhaps an external security audit. All of those need to be estimated. Now just to let you know, no estimate is perfect. There is always some uncertaintity. A supplier may increase prices.
expected. Additional testing may be required. So project budgets often include some of contingency to handle unexpected cost. But the main idea is clear. A project manager should know not only how much money has been approved
but also where that money is expected to go. And then during execution, actual spending should be compared with the planned budget. If the project has spent 80% of the budget but only completed 50% of the work that is obviously a warning
sign. So budget planning is not simply about creating a number at the understanding whether project spending is still aligned with the progress or not. Now closely connected to budget is resource planning. Resources are the
material required to complete the project. Now in many project people are common mistake is assuming that because a person exists in the organization they
are automatically available for the project. For example you might need a cyber security expert for two week but what if that person is already committed to three other projects you might need a designer in a month but perhaps they are
only available in month three that immediately affect the entire project schedule. So resource planning involves us how many people do we need, when do we need them, are they actually available, do we need external support,
what equipment or systems are required. Now let us say a software project needs five developer but the organization only has three available. The project manager now has choices. Maybe the timeline needs to be extended. Maybe two
contractor needs to be hired. Maybe the project scope needs to be reduced. Again we can see how all these project management areas are connected. Now scope affects resources. resource affect time. Time can affect cost and changes
in any of these areas can create additional risk. So resource planning is project has the right capabilities available at the right time. Now after this planning we eventually reach execution and execution is where project
plan starts becoming reality. During execution team members perform actual project work, developer develop, designers design, engineer spelt, campaigns and vendor deliver their services. But project execution is not
working. The project manager still plays a major role here. One of the most execution is coordination. Different team needs to communicate with each other. Dependencies need to be managed. Issues need to be resolved. Decisions
need to be made quickly when something changes. For example, suppose the designer team is one week late. That delay may not affect the development. The project manager needs to understand the impact and decide what can be done.
Can another part of development start earlier? Can additional design resources be added? Should the milestone be adjusted? Does the client need to be informed? Another part of execution is communication. Stakeholder need regular
updates. Team members need clarity. Senior management may want progress reports. Vendor may need approval. Without good communication, even a technically strong team can struggle. And then we have issue management.
happen while an issue is something that has already happened. If a key developer suddenly leaves the company that is a issue. If the project server goes down that's a issue. If the client reject an important deliverable that is again an
issue. The project team needs to respond resolve the problem and reduce the impact. So the core responsibility includes connect different teams, manage dependencies, remove blockers by communicating which are updating the
stakeholders about the project, give team the clarity and share their progress. Then in the issue management, a good project manager resolves problem that have already happened. Change management, he should be able to change
quickly and evaluate request before accepting them. So that is all for this particular module. I'll see you in the next one.
planned and executed, the next important area we need to focus is on risk management. And this is where project management becomes even more practical. Because no matter how detailed your plan is, no project is completely free for
uncertainty. Something may get delayed. A key team member may become unavailable. Cost may increase. A customer may change requirements. A supplier may fail to deliver or a new opportunity may suddenly appear that
could actually improve the project. So meaning risk management is really about preparing for uncertaintity before it starts affecting the project. So in this understand what project risk actually means. How risk is different from an
issue. Why risk can be both threat and opportunity. Terms like risk appetite, tolerance and threshold mean. And finally, how the complete risk management life cycle work from identifying a risk all the way to
monitoring it. So first thing first, what is a project risk? Let's begin with the most basic question. What exactly is a project risk? In a simple term, a project risk is an uncertain event or condition that if it happens can affect
the project. Now that effect could be negative but it could also be positive and this is an important point because many beginners assume that risk always means something bad. So in project management risk basically means
uncertainty that may influence project objectives such as time, cost, scope, quality or overall business value. Now let us take a very simple example. mobile phone application and plans to launch it in four months. Now that there
developer leaves the team before the application is completed that is a risk because it has not happened yet but if it does happen it could delay the project. Similarly there may be possibility that a new technology
becomes available during the project that could reduce the development time that is also a risk but in this case it could create a positive effect. So seeing in this way a risk is not a problem that already exist. It is
something uncertain that could happen in the future. Another easy example could be organizing an outdoor event. There's a possibility of heavy rain on the event day. That possibility is a risk. If the event is scheduled for next month, you
do not know for certain whether it will rain, but you know that there is a chance. So the project team may prepare an out indoor backup location, additional tent or recheduling the plan. That is really what risk management is
something to go wrong and then reacting, you try to think ahead and prepare. Moving forward, good risk management does not mean eliminating every possible goal is to understand which risks matter. How likely they are and how much
impact they could create and what the team should do about them. Now coming to risk versus value which is one of the most common areas of confusion is the difference between a risk and an issue. There are two term related but they are
not the same. A risk is something that might happen. An issue is something that has already happened. That is probably the easiest way to remember it. Now let project and one of your developer may
point that is a risk because it has not happened yet. You may prepare by cross-raining another developer or planning backup resources. Now suppose point it is no longer a risk. It has become an issue because the event has
deal with it. Let's take another example. Suppose a supplier has a identify the possibility that your equipment could arrive late that's a risk. But if the delivery date arrives and the equipment is actually delayed by
2 weeks now that is an issue. So meaning risk management is proactive while issue management is more reactive. With risk we ask what could happen and how can we prepare. With issues we ask what has happened and how do we solve it. Now
because if project team only focuses on issue they are always reacting to the problem after they occur. A strong project team try to identify risk early so that few problem become serious issues later. Of course not every risk
can be prevented. Sometimes a risk happen even after you prepare for it. But because you already thought about it your response can be much more faster. For example, if you already knew that supplier delay was possible, you may
backup. So when the delay actually happens, the team does not have to start from zero. Now let us move into something more important and that is move to something that is sometimes overlooked. Risk can be divided broadly
into threats and opportunities. A threat is a risk that could negatively affect the project. An opportunity is a risk that could positively affect the they are easier to understand. A threat might be a delay, cost, increase,
technical failure, security problem, resource shortage or quality issue. For example, support your project depends on cloud service provider and there is a possibility of service disruption. That could be a threat because if it happens
the project could be delayed or users could be affected. Now let's look at the opportunities. Suppose the same project is using a certain software tool and during development the vendor releases a new key feature that could automate part
of work. If the team adopts that feature successfully, the project might finish earlier or cost less. That is an opportunity. Another example could be a construction project. Perhaps the project budget assumes a certain
material cost. If the market price unexpectedly decreases, the project could save money. That is a positive uncertaintity. So moving ahead, risk management is not only about asking what could go wrong. It is also about asking
what could go better than expected. And this is actually a very useful mindset because sometimes project team becomes so focused on avoiding problem that they miss opportunities to improve the project. For example, there may be an
earlier, use a more efficient technology, negotiate a better supplier contract or reuse something developed in another project. So in simple term threats should be managed to reduce negative impact while opportunities
benefit from them. Now let us move into three terms that sounds similar but have different meaning. Risk appetite, risk tolerance and risk threshold. Let us start with risk appetite. Now risk appetite refers to how much risk an
willing to take in order to achieve an organization have different level of risk appetite. For example, a startup willing to take significant technical and market risk because it is trying to
grow quickly and innovate. It may accept the possibility that some experiment may fail. On the other hand, a bank working on a payment system may have a very low appetite for risk involving security, compliance or customer data. So risk
appetite is more like a broad attitude towards risk. You can think of it as asking how much uncertaintity are we generally comfortable accepting. Another simple example could be investment. One person may be comfortable investing in
high risk assets because they are looking for high returns. Another person may prefer safer investment even if potential return is lower. Their risk appetites are different. Now projects work in a similar way. Now risk
tolerance is slightly more specific. Risk tolerance refers to how much variation from the expected result the organization is willing to accept. Now let us say a project is planned to cost $100,000. The organization might say we
are comfortable if the final cost varies by up to 5%. That means the project has some tolerance for the cost variation. Similarly, if a project is scheduled to finish in 100 days, management might accept a delay of up to 5 days without
major escalation. That is timed tolerance. So meaning appetite is broad while tolerance gives us a clearer idea of how much deviation is accepted. Now September 1st. The business may be willing to accept a delay of 2 to 3 days
if necessary but not a delay of 1 month. That gives us a practical understanding of tolerance. Now we come to risk thresholds. A threshold is a point at which a risk becomes important enough that action or escalation is required.
Now for example suppose a project budget has a 5% cost tolerance. Management may say that if cost exceed 5% the project manager must escalate the situation to senior leadership. Now that your very 5% point becomes the threshold or suppose a
critical task is allowed to slip by 2 days without major concern. But if the delay reaches 5 days, it must be reported and corrective action must be taken. Again that 5day point becomes the threshold. So an easy way to remember
these three concept in this is risk appetite tells us how much risk we are tolerance tells us how much variation we are comfortable accepting and risk threshold tells us the point where action must be taken and seeing this
distinction is very useful because project teams need to know not only what risk exist but also when those risk becomes a serious enough to require attention. Now coming to risk management life cycle. Now that we have understood
the basic terminology let us look at how risk management works as a complete process. A simple risk management life cycle can be understood through five stages. Identify the risk, analyze the risk, plan the response, implement the
response and monitor the risk. Now let us understand each of these. The first step is risk identification. This is where the team ask what could happen that might affect our project. The team may look at schedule risk, budget risk,
technical risk, resource risk, supplier risk, legal risk, security risk, stakeholder risk and many other areas. Now, for example, if you're developing a mobile application, you may identify risks such as delayed API integration,
security vulnerabilities, poor user adoption, insufficient testing time, or a key developer becoming unavailable. Now, the goal at this stage is not immediately. The first goal is to simply identify them and document them. Now,
once the risk are identified, we move into risk analysis. Here we try to understand two important things. How likely is the risk happen and how serious would the impact be if it happens? For example, suppose there is a
70% chance that a critical supplier will deliver late and that if it happens, the entire project could be delayed by 3 weeks. That risk deserves serious attention. Now, compare that with a 5% chance that a non-critical meeting room
happens, the team can simply use another room. That risk is probably not as important. So, analysis helps us prioritize. We do not want to spend the same time on every risk. We want to focus on the risk that we have greatest
risk has been analyzed, we plan a response might involve trying to avoid the risk, reduce the probability, reduce the impact, transfer part of the risk to another part or simply accept it. Let us
say there is a risk that a single supplier may fail to deliver an important component. One response could be to use two supplier instead of one that reduces dependency on a single source. Or if there is a risk that a new
technology might create technical problem, the team could run a small proof of concept before using it across the entire project. Now for an opportunity, the response might involve taking action to increase the chances
that the opportunity happens. For example, if using automation could reduce project time, the team may allocate resources to test and adopt that automation earlier. After the response is planned, the next step is
This is where the team actually carries out the response. If your plan says create a backup supplier, then someone needs to identify that supplier, negotiate terms, and make sure that the backup option is actually ready. If your
plan says train a second developer, then that training needs to happen. A risk response written in a document but never implemented does not really protect the project. And finally we have risk monitoring. This is extremely
important because risk change throughout the life of a project. A risk that looked small at the beginning might become more serious later. Another risk may disappear completely. New risk may appear and some risk may actually occur
and turn into issues. So project team should regularly review their risk. For example, during weekly project meeting, the team may review the most important risk and ask, is the probability increasing? Has the impact changed? Is
our responses still effective? Has the risk already happened? Do we need a new action? Now, let us say a supplier delay originally had a low probability, but missing smaller deadline. Now, the probability may be much higher. So, the
team may need to activate its backup plan. And this is why risk management is not only one-time activity done at the beginning of the project. It's an ongoing process. Identify, analyze, response, monitor and repeat. So this
was all for this particular module. I'll see you in the next one. understand how to plan, manage and monitor project from start to finish structured way. You will be able to define project goals, manage scope,
identify and prioritize risk, create communicate effectively with stakeholder, manage changes, monitor project performance, and apply both project management and risk management
project management and risk management concept to real world scenarios.