[MUSIC] The final step is risk assessment. You can earn a PhD in risk assessment. So for this short piece of our learning, I'll provide a short introduction. What I hope to give you here is the language you can use and to know what questions to ask in case this comes up at work. Recall that the task milestone list used to determine the duration and cost of a project and to create the project plan included a column for potential risks. Now it's time to dig deeper into the risks. Here's one way to look at them. In the risk column to find the challenge and be very specific. Any critical resource, a person with a unique skill set, a piece of equipment that is in high demand should be listed as a potential risk. People change jobs, equipment breaks down, include things like weather related delays, customs related delays for large ticket items purchased for international delivery, potential vendor issue. Whatever is related to your project, meeting one of its parameters and remember that is specification, budget, and deadline. Note what the risk might affect. Some risks affect more than one parameter. And it will be useful if you can specify any parameters that apply. Let's say that there's one person capable of completing a key task on the critical path in your project. And that person is also a member of several other project teams. Is there a risk they will not have time to allocate to your project when you need them? If you would need to delay the project, the risk would be to the deadline. If you would need to hire another person, the risk would be to the cost, and possibly also the deadline. In the probability column, note the likelihood the risk will occur. This could be difficult if you have no historical data. But the more you calculate risk probabilities, the better you're going to get at it. Highly complex projects might use algorithms to assess risk probabilities. But for most projects follow the same process you used for duration and budget. Check historical information, ask experts, include all relevant team members in the debate. In the cost column input the cost to the project, if the risk were to happen. Even those risks that are not directly related to the budget can be quantified. Delays cost money. How much per day would you lose if the deadline was pushed back in revenues and extra costs? Some risks are qualitative. For example, our image will be damaged if the quality isn't right. Consider how much these problems are worth to you. Will lost image translate to lower revenues? One of my teenage children asked if he could borrow the car to visit a friend. But as he held what is called a driving learner's permit and not an official driver's license, he did not have the legal right to drive a car without a parent. Getting caught would result in the loss of the permit for a full year. His response to my pointing that out was, I am a really good driver. I'll be fine. I won't get caught. And it is true, he is a good driver, and he's unlikely to get caught. So I said, well let's say there's what a 5% chance you would get caught. Sure, okay, he replied, sensing that he was walking into a trap. How much is it worth to you to be able to drive? He replied, I cannot wait to get my license. It's very important to me, how much I pressed a million dollars, he replied. The expected value of driving the car today with only your learner's permit is $50,000. Do you still want to drive? Nah, I'll walk. The expected value is the probability times the cost. Now this is not advice for parents. Try it at your own risk. But for work groups don't give up on quantifying risks just because their qualitative. In this example, the engineering team is concerned that components needed for task A could be delayed up to five days in customs. Based on their experience, they estimate this has a 35% chance of happening. Task A is on the critical path. Every day's delay in completion equals a day's delay in meeting the deadline. Based on profit and loss estimates, every day the product is not on the shelf represents a loss of $10,000. The total risk of a five day delay is $50,000. But the expected value or expected cost in this case is 17,500. This can be very difficult for people to understand. Yes, if the product is delayed five days, the company would be out $50,000, but that is not guaranteed to happen. Expected value or expected cost represents the average of each individual risk. Over many projects with greater experience, the probabilities will become increasingly accurate, and the expected costs will come closer to actual costs. Eventually this form will be filled out with all the potential risks, each with varying likelihoods of happening. We need to see the expected value for each to estimate the projects total risks. In the final column, WARM stands for watch, avoid, research, and mitigate. Risks with very high expected value should be avoided if all possible. In this case the engineering team has decided to attempt to reduce the likelihood of customs delayed, and they're going to need to devise an action plan for that. All risk responses should be added to the project plan as action steps. A common risk is change orders, when someone, the client boss, another department, even the project team itself adds to the project specifications or changes something originally planned. They're asking for a change to the project plan, and that can lead to scope creep. When the plan deliverable is changed or enhanced or added to over time. Projects often get delayed and go over budget. Now sometimes this is just caused by poor planning. Sometimes it's just effective innovation. We do not have experience with the thing we're trying to create then it can be difficult to know that things possibilities. As we create we discover new opportunities and risks and the project goal has to change. But some of it is preventable. So I'm going to share some tips, prevent them with smart goals that are clearly communicated. Involve the users in defining the goal. Ensure all stakeholders buy into it. Be as specific about the deliverable. How will success be measured? Is it achievable given available resources? What is its relevancy to the strategic goal and when will it be completed and delivered? Clearly define formalized change order processes who can ask for a change? Who has to be included in any decisions related to a change. Numerous changes implemented on the fly by casual requests and easy okay result in late and over budget projects. Included in the formal change order process should be running any requests through the project planning tool to see the effect that change might have on the project's three parameters. And if so, negotiate. We would love to add that to our project. Doing so will increase the cost by $30,000 and delay delivery by five days. Do you wish to add it given that? Including the project plan, a design freeze after which no changes will be accepted. If the deadline is the most critical factor, the design freeze should be either on a specific date or after a specific milestone. You would say after x date, no changes to our specifications or processes will be accepted. Or once milestone x is reached, there can be no changes to our spec. For example, once we've built the foundation of the house, no changes in square footage can be made. If budget is the most critical factor, then freeze should be after a certain amount of money is spent. Now you can loosen these a bit if you need, you could say no changes that will affect the critical path or no change that will affect the budget will be accepted. Meaning that you will accept other changes after the freeze. Your project plan cannot be set in stone. If you're in an innovation space, you should expect a highly iterative process. As Pinto and Carbonneau wrote in their article, how to fail in project management without really trying, excessive bureaucracy can harm a project as easily as can a complete lack of planning and control. Planning managers must be able to deal with ambiguity and change while still keeping the team within set boundaries. This is just a small taste of how to assess and prevent project risks. If this intrigues you, I encourage you to study risk management more deeply. This also concludes our discussion of planning and the next video will be about executing.