[MUSIC] In this session, we will look at the qualitative aspects of risk management. And in the next module, we'll get into what is called PERT Simulation, which is an extension of the critical part matter. First, some definitions and then we will look at some of the benefits of being prior to in terms of risk management processes. What is risk? Risk is an uncertain event that if it occurs it can be beneficial or it can be adverse. We always think of risk in terms of adverse effect. But if it is beneficial to us we would not mind the risky event happening. Essentially, you can not avoid all this and you may not even be able to predict all the risky events that make up and when they make up. The risk management process starts with identifying the type of risky events that are likely to occur. And assisting them in terms of the impact that they may have on the project in case the risky event occurs. You need to plan ahead your response in case the risky event occurs. You have to constantly monitor the environment to find out if the risky event is likely to occur. You must have a change management process, which is essentially in order to understand how the risk can be handled. The main idea behind the risk management process is that if we are able to proactively think through before the risky event occurs, you'll be able to manage them better. And the risky event occurs, you're likely to be under pressure and trying to decide what should be done, will be difficult. Unless you have earlier considered all possible responses and arrived at the best possible course of action. You have to consider the likely impact of the risky event and how it may be reduced by your response. You should also look at possible actions before the risky event occurs so that it can be made less likely to happen. You must, however, be aware that some risk will happen in spite of all the precautions you take. The first step in the risk management process is risk identification. You have to do an analysis of the project to understand the different sources of risk. Then, you have to assess the severity of impact of the risk event in terms of cost, completion date of the project, and the quality of the output. You then have to arrive at the desirable response in case the risky event occurs. You also have to arrive at an implementable strategy to adjust the plans. As the project progresses, new risks may crop up, and you have to decide upon the course of action before the risky event happens. Next, we will look at the process of risk identification. You first generate a list of possible risks by brainstorming with those involved in the project, and individuals who are knowledgeable. During the process of brainstorming, you should not criticize any of the solutions. Even though the risky event identified is highly unlikely to occur. Risk identification is best done through what is called risk breakdown structure. You need to look at the profile of the project. Not only in terms of technical and external factors but also in terms of organization and project management factors. For instance, on the technical factors, you need to know whether the requirements have been well specified or not, and whether the requirements are likely to be stable or not. Under external factors, for instance, you should assess that a liability of the suppliers and subcontractors. And the organizational factors, for instance, you should look into whether resources including finance are readily available or not. In a risk breakdown structure, under each of the factors, you ask questions that address the various areas of uncertainty. These questions may be developed from past experience and should be tailored to the particular project. The answers to these questions identify the risk involved. I recall one instance where one of the students are graduating, joined a software company. And his first task was to identify the source of risk in an ongoing software project management. Believe it or not, he came up with 160 possible sources of risk, of course, not all of them will have substantial impact and some of them may have substantial impact, but low probability of occurrence. But one has to still go through the list and see what action you would want to take, depending upon the cost benefit analysis that you do. Next, you look at the impact level. This may be high but the chances or the risky event happening maybe so low that you may choose to ignore it. Furthermore, the cost for taking precautions may be so high that you may decide not to do anything about it. For risk assessment, you have to do scenario analysis. And in this scenario, you look at which risky events are likely to happen. And the likely impacts separately on the 3 parameters namely, cost, time and performance. You have tested the likelihood of your risky event happening. For assessing the impact separately on cost, time and performance, you may use a five point scale. Such as very low impact, low impact, moderate impact, high, and very high impact. The likelihood of a risky event is low and the impact of the 3 parameters also low. You would not worry about that particular risky event. The likelihood of the risky event happening is high and the impact on one or more of the parameters is also high. You have to take appropriate action to reduce the likelihood of this risky event happening and or reduce impact on the 3 parameters of interest. In other situations, you have to plan ahead the course of action to be taken if the risky event does occur. Probability analysis also may be done if the necessary information is available. A decision tree approach is possible if the required probabilities can be estimated. Assimilation of the project may be done to study the impact of the risky event if and when a possible course of action is undertaken. Essentially, for risk management there are three aspects to consider. First, of course, is identifying the risky event and the likelihood the risky of it happening. Then, you have to assess the impact the risky event would have on the budget, schedule and scope. You also have to look at the cost of taking remedial action now or, if possible, the cost of trying to prevent the risk event happening. Finally, based on this analysis, you have to take some appropriate action. In many instances, as the project processes, you may have more information, as to the likelihood of the risky event happening. A importance is how much in advance you can predict the risky event is most likely to occur. If you have adequate to respond to the risky event, you may then postpone any action until you have more information. Let us next look at mitigating risk. You may not be able to emulate the risk completely but you maybe able to reduce the likelihood of that doers assuming. Prototyping and testing will reduce the likelihood of something going wrong. Some lenders may be good at supplying on time while some others may not be supplying on time. In that case, you can have a vendor development process. You constantly interact with vendors and ensure that the supplies come on time and have good quality. Essentially, you reduce the risk of the vendors delaying supply and are the supply of poor quality. Similarly safety training may be given to mitigate the risk of accidents. You can also reduce the risk by having two separate teams working on the same project and see which team comes up with the good product first. This is, in essence, parallel processing of the same project, or the sub project, and may be a costly option. But it may be very important that you turn up a good product in quick time. Apparently, Microsoft uses this approach for some modules in the development of the system software. In R and D projects you may have some projects that may be undertaken by two teams in parallel. Apparently this approach is sometimes used in the aircraft industry. You can transfer to this by having fixed price contracts. Another possibility is the use of options for transferring risk. You have to pay a premium to purchase the option. For instance, supposing a project, you need to purchase some raw material in future from abroad, and you may be concerned that the rupee may depreciate a lot by the time you require the raw material. Here, you can is the rupee, depreciating too much, by purchasing the call option, to buy the required currency at a predetermined rate, referred to as the strike rate. At the time when the payment is due, if the exchange rate is unfavorable compared to the strike rate, you would exercise the call option and get the foreign exchange at the strike rate. If, on the other hand, the exchange rate is favorable compared to the strike rate, you will simply throw away the option that purchased for a premium. The use of the call option is like purchasing insurance against the exchange rate depreciating too much. You can also share your risk by partnering with other organizations, this way you will share the risks in terms of the cost but you may have to give up some profits that may be derived from the output of the project. For instance, Airbus 8340 was designed and commissioned by a consortium of companies. You have sharing of risks and build, own, operate, and transfer type of contracts. These contracts are a way of sharing risk between the government and the private organizations. You may also try to avoid risk by using proven technology, although it may be more expensive then some new technology that has been developed recently. But you're not sure how reliable it is. Similarly in my true suppliers from stable regions, that there are no political upheavals because you're not sure whether you will in deed get the supply from regions where there is lot of instability. There may be technical risks also. These are resources related with scope, are performance of the product which is an outcome of the project. This would, of course, depend upon the particular project. Schedule risk is the risk associated with the schedule. For instance, if you delay the completion of some activities, especially the critical activities. The project may get delayed. For non-critical activities you have some slack. During the early part of the project for non-critical activities, if you start using the slack you may have too many critical activities to manage and run into difficulty during the latter part of the project when some of the activities may take more time than the estimated time. Provides some rough bulletin terms of time and cost to avoid the consequences of the project getting delayed by the consequences of project over run. One problem of the is that the people may behave as though the extra time and the budget are available to them In the normal course of executing the project. It should be made clear that the extra time and budget are to be used sparingly, and only when there is no other choice. One problem that in some other projects in India, is that the contractor works on a shoestring budget, in the sense that he or she does some work, and expects to be paid immediately so that the funds can be used for the next phase of the project that is the next set of activities. But in many organizations that sponsor the project, payments to the contract can be made only after some measurements are completed to ensure that the work done is as specifications. In this process, if there's a delay in payment to the contractor, further work on the project gets delayed. Finally, is you understand that they will always have some risk in the project. And you have to retain that risk. So your contingency plan is important as mentioned earlier. In order to monitor and control the risk, you need to establish and change management system. Before a risky event occurs, you have to assign the responsibility to one or more persons to take the necessary actions when the risky event actually happens. You need to document this and those involved in the project should be aware of their as well as others responsibilities. Risk monitoring and control starts with the risk response matrix. In the first column of this matrix, you have all the risky events identified. In the second column, you identify the possible immediate response. The contingency plan is recorded in the third column. The fourth column identifies the trigger that would escalate the problem to a higher authority. The last column gives the name of the person responsible to handle the risky event when it happens. A change control process is essential to control and communicate the changes. The sources of changes, including the project scope changes, improvement changes, etc., should be identified and recorded. A scope change may be difficult to accept and manage. This is often referred to as scope creep. The customer may want some changes in scope. Before accepting a scope change, a thorough analysis of the implications of accepting the change should be done. Important implications, especially with regard to the time of completion of the project. And the cause should be communicated to the client. Sometimes some negotiations maybe required before the scope changes accepted. An individual wanting some change should submit a request which is to be reviewed by an authorized person perhaps the project manager. If the request is not accepted, the person who will requested the change would be informed of the reasons for not accepting the change. If the request is accepted, appropriate action needs to be initiated. The project plan should be updated and communicated to all for information and necessary action if any, while it is desirable to keep the changes to a minimum, sometimes it may be desirable or even essential to make the changes. In this module, we have looked at various aspects of risk management. Sometimes it may be desirable not to give only one possible project completion time, but instead arrive at various possible project completion times and their associated probabilities. In the next module, we'll see how simulation with program evaluation review technique, also called PERT, may be used to identify the distribution of project completion time. [MUSIC]
