Managing a Stochastic Constrained Project. In this lecture, we will develop a plan for the medium writer development project. Reason why I use stochastic as activity duration is not known for sure and the short probability is less than 100 percent for all types of resources. The focus in this scenario is on planning and control, the plan is based on the trade-off between cost schedule value and risk. We will try to develop a project plan that maximizes the value of the project while satisfying the unit constraint, the cost constraint, and is protected against uncertainty and risk. During project execution, we will see how monitoring and control is used not only to adjust the level of resources as in the deterministic unconstrained project, but also to identify deviations from the project plan to analyze such deviations and to take corrective actions when needed. We really all speak to be the project team builder to manage a project under uncertainty. Go to Run It, select PTB Training Simulator, and then click on the PTB Training Simulator. When prompted for the username and password, please enter the data and click okay. Under Use Cases, select the Medium Radar Development Project. In these project, we have five tasks and the first view is a Network View where we can see the five tasks or activities and the president's relations among them. The same information is available under tasks, where we can see the five tasks and the predecessor of each task. We can see some information about this scenario, we have five tasks, there is a due date of 15 periods. We start with $100,000, the target cost is 41,000. There is a bonus per period of 10,000 and a penalty of 20,000. Next thing we want to do, is to look at the upper right corner, where we can see a summary of this scenario information. The due date is 15 periods, the target cost is 41, we start with $100,000 in cash. So, let's see the plan that is created by plan default. This plan takes 18 periods, which is longer than the required time cost 80,000, which is more than the required cost, has a value of 76.67, which is rather low. There is an important point to consider, if you look at a current modes, you can see that we are not certain about the duration of each activity. For example, systems engineering in the current mode, which is a small team can take between five and 10. The current project duration of a team is based on the most likely duration of seven, but there is a risk that the activity will take longer. There is another source of risk, which is the availability of resources. For example, the engineers are showing up only 80 percent of the time, which means that in every period there is a 20 percent probability that an engineer will not show up. This is another source of risk that we have to take into account when planning and managing this project. Let's look at the Gantt chart and focus on the critical activities. We see that the current project duration is 18, if we want to reduce the project duration, we will change the first activity to large team, and we'll use plan early. And now, the project duration is 15 which is less than the required duration. However, the benefit is still low and we will change the activity antenna design into the new design mode. Consequently, the project benefit will go up to 100, and still the duration is 15 periods, the cost is 26,000 much less than the required cost. Now we have a plan, and the question is, can we improve on this plan? Let's look at the last activity integration and testing. Integration and testing is currently done in-house. We can use subcontractors, but the most likely duration will not change and even worse, the pessimistic duration will be six, which increase the probability that the project will be late compared with the pessimistic duration of five that we currently have. So we will stick with the modes already selected and we will adjust the resources next. Let's look at the resource chart for engineers. We see that we have 20 engineers available, however, we need only three. If we will adjust the number of engineers to exactly three by releasing 17 engineers, we take the chance of the risk that one or more of the engineers will not show up and then we will not be able to continue with our plan. Let's ignore the risk for a while, and therefore, we'll be the same for the technicians and we'll change the number of technicians from 20 to the minimum possible which is two. So we want to release 18 of the technicians. Now we'll start running the project look at the Gantt chart. Let's execute the project one period, and you can see that the first activity is started. We'll do it again, and we are now two periods into the activity next period, we'll have to hire more resources. However, when we click on Run, we see that there are not enough engineers. Why? Because somebody probably did not show up. So what do we do? We took the risk and now we have to pay the penalty, and the penalty is that we have to split the first activity. We have to split it in the current time which is time two, and we can continue in times three. We apply the split, the project will take longer and you can see that between two and three, nothing is done on this activity. But now we are smarter and we are going to buffer against uncertainty. We'll do it by adding two more engineers, and one more technician. This buffering is actually mitigation against uncertainty. And you can see, that we have the buffer of two engineers and also the buffer of two technicians to protect us against the possibilities that one of the engineers or one of the technicians or even two of them will not show up. Let's continue the execution. And now, it's time to adjust the resources. We have three engineers- three technicians, excuse me. We have three technicians, we need four, we want to buffer, so we will add three more. In a similar way, if we look at the engineers, we currently have five engineers, we need nine, so we will add six more engineers. Again, we created a buffer of two engineers. We'll continue to execute the project. And two was not enough, apparently we still have a problem, we need to increase our buffer. But what do we do that we don't have enough resources yet? Well, we could delay one of the non-critical activities, so we have two critical activities. These are the transmitter design and the receiver design. If we look at the resource charts for engineer, we see that the transmitter design and the receiver design require two engineers each. If we look at the technicians, we see that the transmitter design and the receiver design require one technician each. So we will delay one of these activities simply by dragging it and we'll check the resource charts. Of course, now we have a higher buffer and therefore, we'll probably be able to run the project. And yes we did. What we want to do is maybe to increase the buffer for technicians from two to three. And also, increase the buffer for engineers from two to three. And now, we'll continue to run until period nine. Unfortunately, the buffer is still not enough. We have eight engineers available we need nine. So again, we'll have to delay one of the activities, we look at the Gantt chart and we can delay this activity which will make it critical or we can split this activity and it will not be critical. We prefer to split, so we'll split at period six, continue at period seven. And also we will increase our buffers to protect our project better. So we lead another engineer and another technician. We did not apply the split so let's do it again. Split at period six, continue at period seven, apply the split, and now we should be okay. So let's execute the project. Yes we are fine, we'll continue to run until period 10. And at that time, we can check the resource requirements. And for engineers, we will need two less, so we can reduce the number of engineers by two. And for the technicians, we will need one less. So we can reduce the number of technicians by one, but then we will need it again and the hiring and firing cost will compensate for the idle time cost. So we will just continue to execute the project. Let's look at the Gantt chart, and we see, that the actual duration of the project was 16, it's total cost 59,130. And it's benefit 100. This is not a good result and the reason is that we did not buffer against uncertainty when we started the project. You can try to rerun the project buffering against uncertainty from time zero and see if you can get a better result.
