[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] 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
[00:35] 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
[00:49] 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
[01:01] 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
[01:13] 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,
[01:26] 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
[01:39] 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
[01:52] 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
[02:05] 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
[02:19] 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
[02:33] 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
[02:46] 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
[03:01] 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:15] 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:27] 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:41] 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
[03:55] 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:08] 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:23] 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:36] 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:50] 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:02] 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:15] 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
[05:27] 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
[05:41] 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
[05:53] 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
[06:05] 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
[06:17] 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.
[06:29] 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
[06:41] 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,
[06:54] 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
[07:08] 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
[07:21] 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
[07:33] 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
[07:46] 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
[07:59] 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
[08:11] 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
[08:26] 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
[08:41] 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
[08:53] 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:05] 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:18] 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:31] 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
[09:43] 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,
[09:57] 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
[10:10] 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
[10:23] 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
[10:37] 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
[10:49] 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
[11:02] 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
[11:16] 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
[11:29] 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
[11:43] 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
[11:55] 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
[12:09] 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
[12:22] 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
[12:36] 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
[12:48] 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
[13:01] 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,
[13:14] 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
[13:27] 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.
[13:40] 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
[13:52] 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
[14:04] 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
[14:17] 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
[14:29] 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
[14:43] 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
[14:55] 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
[15:09] 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
[15:21] 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
[15:33] 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
[15:46] 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
[15:58] 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
[16:10] 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
[16:25] 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
[16:39] 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
[16:52] 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
[17:05] 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
[17:20] 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
[17:33] 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,
[17:46] 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
[17:59] 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
[18:11] 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
[18:27] 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
[18:40] 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
[18:53] be removed? What risk does this create? That way changes become conscious decision instead of simply being added to the team's workload.
[19:08] 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
[19:23] 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
[19:35] 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
[19:48] 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
[20:02] 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
[20:15] 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
[20:29] 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
[20:41] 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
[20:54] 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
[21:06] 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.
[21:19] 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
[21:32] 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
[21:45] 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
[21:58] 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
[22:12] 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,
[22:24] 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
[22:38] 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
[22:50] 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
[23:04] 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
[23:16] 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,
[23:30] 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
[23:44] 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
[23:57] 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,
[24:10] 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,
[24:22] 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.
[24:35] 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
[24:49] 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
[25:03] 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
[25:17] 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
[25:29] 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
[25:41] 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,
[25:54] 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
[26:06] 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
[26:19] 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
[26:32] 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
[26:47] 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
[27:02] 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.
[27:14] 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
[27:26] 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.
[27:39] 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
[27:54] 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
[28:09] 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
[28:22] quickly and evaluate request before accepting them. So that is all for this particular module. I'll see you in the next one.
[28:35] 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
[28:47] 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
[29:00] 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
[29:15] 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
[29:28] 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
[29:42] 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
[29:54] 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
[30:08] 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
[30:22] 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
[30:34] 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
[30:47] 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
[31:01] 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
[31:16] 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
[31:30] 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
[31:42] 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
[31:59] 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
[32:14] 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
[32:29] 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
[32:44] 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
[32:56] 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
[33:12] 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,
[33:26] 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
[33:38] 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
[33:50] 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
[34:03] 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
[34:15] 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
[34:28] 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
[34:41] 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
[34:56] 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
[35:12] 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
[35:25] 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
[35:39] 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
[35:53] 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
[36:06] 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
[36:20] 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
[36:35] 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.
[36:48] 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
[37:03] 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
[37:16] 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
[37:31] 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
[37:44] 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
[37:56] 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,
[38:10] 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,
[38:22] 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,
[38:37] 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
[38:50] 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
[39:04] 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
[39:18] 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
[39:32] 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
[39:46] 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
[39:59] 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
[40:13] 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
[40:27] 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
[40:41] 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
[40:53] 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
[41:07] 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
[41:23] 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
[41:36] 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,
[41:52] identify and prioritize risk, create communicate effectively with stakeholder, manage changes, monitor project performance, and apply both project management and risk management
[42:04] project management and risk management concept to real world scenarios.