Project Risk Management Guide — Step-by-Step Guide & Transcript

[00:07] 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

[00:20] new product, building an application, organizing an event, setting up a new office or even introducing a new process inside a company can all be managed as projects. But meaning completing a project successfully is not just about

[00:33] 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 come together.

[00:45] 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

[00:58] fundamental of managing project and risk, this course will give you a strong foundation. So with that said, let's get started with the very first module which is project management fundamentals. Now before we move on, let me share

[01:11] something exciting with you guys. If you are serious about building a strong 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

[01:24] management in a practical, structured and exam focused way. You will learn important concepts like project planning, work breakdown structures, resource allocation, GL chart, risk and issue management, stakeholder

[01:36] 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

[01:48] 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

[02:01] project management, this course can help you build the confidence, structure and skills needed to manage project better and grow in your career. So without wasting any further time, let's get started.

[02:15] fundamental of project management including what a project is, how project through their different life cycle. Moving ahead, we'll also cover project charters, goal setting, scope

[02:28] scheduuling, milestone, budgeting, and resource planning. We will then explore the fundamental of risk management including risk versus threat versus issues and opportunity tolerance and threshold. After that, we will

[02:41] understand how to identify, analyze, prioritize and respond to risk using tools such as risk registers, probability and impact analysis. management, project communication, performance monitoring, change

[02:54] management, escalation and a real world project and risk management case study. module which is project management fundamentals. Now before we get into

[03:07] 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

[03:21] 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

[03:33] 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

[03:47] 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

[04:01] 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

[04:14] 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.

[04:29] 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

[04:42] 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

[04:56] 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

[05:08] 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

[05:21] 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 IoT infrastructure to improve security or it may even want to build a new office to support

[05:35] 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

[05:48] basically the process of planning, organizing, executing, monitoring and completing a project so that its objective can be achieved successfully. enough. You need to decide what exactly needs to be done, who is doing what and

[06:02] 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

[06:14] 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

[06:26] 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,

[06:38] 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

[06:51] responsible for making it happen. A project manager therefore is not simply follow-ups on deadline. A good project manager connects people, task, timeline, budget, risk and business goal. They constantly look at the bigger picture

[07:05] while also making sure that individual activities are moving in the right direction. Moving ahead, one of the most important thing is about decision making. Project really go exactly according to plan. A vendor may deliver

[07:17] something late. A team member may become unavailable. A customer may suddenly request an additional feature. Cost may increase. Technology may fail. So the project manager need to continuously evaluate what is happening and decide

[07:29] 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

[07:41] project should have a clear objective and objective tell us what the project 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

[07:55] 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

[08:08] 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

[08:20] like. For example, if the project is to launch a new online learning platform, platform by particular date, supporting a certain number of users, delivering specific learning features, staying within the approved budget and meeting a

[08:33] defined quality standard. So meaning a project objective becomes the destination that everyone is working towards. Now this brings us to some of project management which is scope, time, quality and cost. You can think of these

[08:47] 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

[08:59] 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

[09:11] 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

[09:24] 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

[09:37] need to launch in six months. The building may need to be completed by happen on a fixed date. Project [clears throat] manager therefore break the work into activities. Estimate how long those activity will take. Identify

[09:51] 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 requirement. There may be employees cost, software cost, vendor

[10:04] cost, equipment cost, travel expenses, infrastructure cost and many other expenses. So if the project manager needs to make sure the project can unnecessarily exceeding the approved budget. And then we have equality.

[10:19] doesn't really help if the final result doesn't work properly. Imagine launching a new mobile application exactly on the time and within the budget. Whenever customer try to make a payment technically the deadline and budget may

[10:33] 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

[10:47] 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

[10:59] 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

[11:12] 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,

[11:26] monitoring and control. Now let us start with 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

[11:39] 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

[11:53] 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

[12:07] 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 the

[12:20] the code, engineering construct buildings, designer create design, marketing team, develop campaigns and project team produces the required deliverables. The project manager

[12:33] 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

[12:46] 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

[12:58] appealed? our 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

[13:11] 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

[13:24] 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,

[13:37] 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

[13:50] project is actually planned and then 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

[14:02] 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

[14:14] that people can actually follow is where project management really begins. So in understand project charter, goal setting, scope management, work shoulduling, milestone, budget planning, resource planning and finally some

[14:29] 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

[14:42] charter. Now a project charter 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

[14:55] 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. Why are we doing

[15:07] this project? What 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

[15:20] 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

[15:33] mandatory courses. Now here it may mention that the project needs to be completed within 6 months that the estimated budget is a certain amount that HR department is the project sponsor and that IT team will support

[15:46] development and integration. It may also identify the key stakeholder and major risks that are already visible at the beginning. Now seeing this example, you charter is useful. Without it, different people may have completely different

[16:00] 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

[16:12] may believe that the objective is to reduce training cost so that the charter bring everything back to one common understanding. Moving ahead alongside the project charter we also need clear project goal and this is extremely

[16:25] 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

[16:38] the average customer support response time from 12 hours to 4 hour within 6 months. Now, we have something specific that we actually want to measure and goal. Smart generally stand for

[16:52] 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

[17:05] 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

[17:18] 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.

[17:32] 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

[17:46] 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

[17:59] 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

[18:12] 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

[18:25] not look like this a big issue but if these changes continue throughout the 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

[18:38] 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

[18:50] changes should be controlled. If a new feature is requested, the team should ask how much additional time will it require. Do we need additional resources? Will another feature need to be removed? What risk does this create?

[19:02] That way changes become conscious decision instead of simply being added decision instead of simply being added to the team's workload.

[19:14] the 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 structure is very simple. Take a large project and break it into smaller

[19:28] 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

[19:41] areas such as planning, design, development, pasting, content creation, deployment, and launch. Then each of those areas can be broken down further. Design may include wireframes, homepage design, product page design, mobile

[19:54] 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

[20:07] 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

[20:21] 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

[20:34] 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 set setup, and event day operation. Then the venue could be

[20:47] 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

[21:00] the WPS 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

[21:13] 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. Some tasks depend on other task. For

[21:27] 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

[21:40] are completed. Now, these relationships are called dependencies. So when building a schedule, the project manager looks at the list of activities and asks question like how long will each task take? Which task need to happen first?

[21:54] 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 3 days. Task B

[22:07] 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 E is the final approval. A schedule help the team understand the sequence and identify where project may become

[22:20] delayed. Now project schedules can be very simple or very detailed. For example, a small project or spread sheet or task board may be enough. For larger project teams may use Gant chart, dedicated project management software or

[22:33] 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

[22:46] 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

[22:58] 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

[23:13] milestones are useful because they make larger projects easier to understand 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

[23:25] milestones are being achieved on time or not. Now let us say a six month 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

[23:38] final launch in month six. Now management can quickly see whether the project is moving in the right direction or not. So in simple terms task tell us what work is happening while milestone tell us when something important has

[23:50] been achieved. Now we come to another 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

[24:02] 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

[24:14] infrastructure cost, traveling cost, venue charges, marketing expense, 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,

[24:28] 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. supplier may increase prices. Development may take longer than

[24:43] expected. Additional testing may be required. So, project budgets often include some of contingency to handle unexpected cost. But the main idea is clear. So a project manager should know not only how much money has been

[24:55] 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

[25:08] obviously a warning sign. So budget planning is not simply about creating a number at the beginning. It is about continuously understanding whether project spending is still aligned with the progress or not. Now closely

[25:20] connected to budget is resource planning. Resources are the people, material required to complete the project. Now in many project people are the most important resources. And one common mistake is assuming that because

[25:33] 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

[25:45] 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

[25:59] 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

[26:11] 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

[26:24] cost and changes in any of these areas can create additional risk. So, resource that the project has the right capabilities available at the right time. Now, after this planning, we eventually reach execution and execution

[26:38] is where project plan starts becoming reality. During execution, team members perform actual project work. Developer develop, designers design, engineers build, analyst analyze, marketers create campaigns, and vendor deliver their

[26:51] services. But project execution is not simply telling everyone, okay, start working. The project manager still plays a major role here. One of the most important responsibility during execution is coordination. Different

[27:03] team needs to communicate with each other. Dependencies need to be managed. 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.

[27:16] 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 adjusted? Does the client need to be informed? Another part of execution is

[27:31] 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.

[27:43] And then we have issue management. Remember, a risk is something that might 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,

[27:56] 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

[28:09] 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,

[28:22] 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

[28:35] 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.

[28:50] Because no matter how detailed your plan is, no project is completely free for uncertaintity. Something may get delayed. A key team member may become unavailable. Cost may increase. A customer may change. requirements a

[29:02] 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

[29:17] 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

[29:31] 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

[29:44] 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

[29:57] 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.

[30:09] Suppose a company is developing new mobile phone application and plans to launch it in 4 months. Now that there may be a possibility that a key developer leaves the team before the application is completed. That is a risk

[30:21] 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

[30:33] 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

[30:45] 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

[30:58] 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 all about. Instead of waiting for something to go wrong and then reacting,

[31:11] you try to think ahead and prepare moving forward. Good risk management does not mean eliminating every possible risk. That is usually impossible. The goal is to understand which risk matter, how likely they are and how much impact

[31:23] 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

[31:37] 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 resign in the next few months. At this

[31:50] point that is a risk because it has not happened yet. You may prepare by crossraining another developer or planning backup resources. Now suppose point it is no longer a risk. It has become an issue because the event has

[32:05] already occurred and now the team has to deal with it. Let's take another example. Suppose a supplier has a history of late deliveries. You may equipment could arrive late that's a risk. But if the delivery date arrives

[32:19] 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

[32:33] happened and how do we solve it. Now this distinction is very important 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

[32:46] 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.

[32:59] 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

[33:13] 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

[33:27] 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

[33:41] possibility of service disruption. That would 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

[33:53] 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

[34:06] project budget assumes a certain material cost. If the market price unexpectedly decreases, the project uncertaintity. So moving ahead, risk management is not only about asking what

[34:20] 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

[34:33] opportunity to deliver a feature 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

[34:46] should be so that the project can benefit from them. Now let us move into three terms that sound similar but have different meaning. Risk appetite, risk tolerance and risk threshold. Let us start with risk appetite. Now risk

[35:01] appetite refers to how much risk an organization or stakeholder is generally particular objective. Now different organization have different level of risk appetite. For example, a startup developing a new AI product may be

[35:14] 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

[35:28] 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

[35:42] 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

[35:56] 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

[36:09] 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

[36:23] finish in 100 days, management might accept a delay of up to 5 days without major escalation. That is time tolerance. So meaning appetite is broad while tolerance gives us a clearer idea of how much deviation is accepted. Now

[36:37] 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

[36:51] 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

[37:05] 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

[37:18] 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

[37:33] 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

[37:46] 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

[37:59] 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

[38:12] 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

[38:25] 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

[38:37] necessarily to solve every risk immediately. The first goal is to simply identify them and document them. [snorts] Now, once the risk are identified, we move into risk analysis. Here we try to understand two important

[38:49] 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

[39:03] delayed by 3 weeks. That risk deserves serious attention. Now compare that with a 5% chance that a non-critical meeting room may not be available. Even if that happens, the team can simply use another room. That risk is probably not as

[39:16] 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. For negative risk, the

[39:30] 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

[39:43] 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

[39:57] proof of concept before using it across the entire project. Now for an taking action to increase the chances that the opportunity happens. For example, if using automation could

[40:11] 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

[40:25] 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.

[40:38] 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 looks

[40:52] 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

[41:05] 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

[41:19] action? Now, let us say our supplier delay originally had a low probability, but 2 months later the supplier starts missing smaller deadline. Now, the probability may be much higher. So, the team may need to activate its backup

[41:32] plan. And this is why risk management is not only a one-time activity done at the beginning of the project. It's an ongoing process. Identify, analyze, was all for this particular module. I'll see you in the next one.

[41:51] monitor a project from start to finish while handling uncertainty in a define project goals, manage scope, schedules, budget and resources, practical response strategies, communicate effectively with

[42:06] project performance, and apply both project management and risk management project management and risk management concept to real world scenarios.