[MUSIC] This module is about resource scheduling. By set activities in a project typically requires the use of resource such as people, material, equipment and working capital. The early start and let start schedule for all the activities that we alloted before, assumes there are adequate resources available as are required. The schedule may not be feasible if there's a resource limitation. This is because, although some activities can be technologically done simultaneously it may not be possible to do so because they require the use of the same resources whose availability is limited. In essence, there may not be any present relationship between two or more activities, but there may be resource dependency in the sense they cannot be done simultaneous because of resource limitation. Not possible to show these results dependencies in the network diagram. Except in trivial cases, where two activities, say activity A and B, require the user's same resource, whose availability is limited. In those cases, we can conceptually think of two networks. One in which activity A is a predecessor of activity B And other in which activity B is a predecessor of activity A. But even in the simple example, drawing the two networks is valid only if the activities cannot be split in the sense that if you work on an activity A for sometime with the available and then switch to activity B. After completing B you may then return to activity A to complete it. Even if splitting is not allowed, if there are several such resource dependencies, the number of networks increases exponentially. Splitting the work on a task would typically imply the duration of the task is higher than the normal duration. Because of the additional work involved in stopping and restarting the work. But still it may be advantageous to split one or more activities when resources are limited when one or more activities require the use of the same resource. In general, the requirement of resources for an activity may not be uniform throughout its duration. This further complicates the problem in arriving at a feasible schedule when the availabilities of some of the resources is limited. Even when resources are available as and when required, we want a schedule that smooths the use of resources during the project. Of course, in this case, one needs to define clearly what smoothing means. And how the smoothness or the non-smoothness of a schedule is to be measured. If there's an agreement on this measurement, we may conceptually add average schedule, which minimizes the non-smoothness subject to the project completion time not being extended beyond the time by noting the resource requirements. I recall the assuming the required resources are available as in when required. Alternatively when we want to schedule which minimizes the maximum cost of resources required at any time during the project subject are named to the restriction in the project completion time is not to be extended beyond the time arrived at by ignoring the resources. Even in this case when several types of resources are involved, we need to decide whether equal or differential rate is used to be given for the different resources. There are two types of problems when resources are involved. One is the resource molding problem, which is the problem discussed about. The other problem referred to as a resource limitation is the problem of finding the earliest completion time of the project with specified limits for the availability of the resources at each point of time during the duration of the project. The resource limitation problem may extend the completion time of the project beyond the completion time arrived at by assuming that the required resources are available as and when required. The objective is to minimize the extension of the project, alternatively find the earliest completion of the project with the resource limitations. Both the resource smoothing problem and the resource limitation problem are difficult to solve for optimality. That is, to arrive at best solution given the objective function. Conceptually one can formulate these problems as large optimization problems with integer variables whose values are to be determined. These problems are refered to as integer programing programs. But given the current state of art for solving integer problems It's not possible to find an optimal or best solution in a reasonable amount of time, even with the fastest computers available. So for such problems, one derives good heuristics, or rules of thumb, which will often give good solutions, without any guarantee that it is the best possible solution. To arrive at good heuristics, researchers have try different rules of thumb for solving randomly generated projects with resource requirements. A good rule of thumb seems to be the so-called minimum slack rule, which is described next for the resource limitation problem. Schedule the project day by day or week by week, or any other unit of time, depending upon the unit of measurement for the activity duration. And on any given day, among the activities that need to be started with the resources that are available, give preferences to the activities with least slack. In case of ties, give preference to the activity that has the least duration. If there are still ties, choose the activity which has the least identification number of letter. The assumption is that an activity, once started, will continue until it is completed. That is, there is no splitting of an activity. We'll next describe the use of a minimum slack rule for the software project example that we had considered before. Suppose activities B, C, and D require one senior software engineer and the organization has only one such person. Hence, although conceptually, activities B, C, and D can be done simultaneously, they have to be done sequentially because of the resource limitation. Recall that without resource limitation, the project can be completed in 11 weeks. Now, we apply the minimum slack rule. On day 1, only activity A can be started. On day 2, activity A is still in progress. At the end of day 2, activity A has been completed. And so at the start of day 3, activities B, C and D can be started if adequate resources are available. All the three activities require the same resource of senior software engineer, but we have only one such person. Then, applying the minimal slack rule, we give preference to activity B, since it has the least slack of zero. So B scheduled on day 3, and start of activity C and D are pushed to the beginning of day 7, since activity B requires four days. Now, the revised early start schedule is as given in the table. There's nothing to be done until activity B is completed at the end of day 6. At the beginning of day 7, both activities C and D can be started, provided the resources are available. But since we still have the resource limitation activity c is going preference since it has the least lack of 0. There's nothing to be done further until activity C is completed at the end of day 9. At the beginning of day 10, both activities D and D can be started under revised schedule is arrived as shown in the table. With resource limitation the project completion time is 14 weeks. In this particular example, minimum slack rule gives the best possible solution with resource limitation. But, there is not always the case as illustrated by the following simple contrived example. Suppose a project has three activities that are identified in the table as A, B, and C. The same table gives the duration of these activities and the precedence relationships. Shown in the table, activities A and B require 1 unit of the same resource, of which only one unit is available. Initially applying the minimum slack rule, activity B gets preference over activity A since slack for activity B is zero. That is, it is on the critical part when resources are ignored. While slack for activity A is one. Then the early start and the early finish of activities of A, B, and C are calculated as shown in the table. The project completion time is 4. Clearly if activity is given, that is preference for an activity for the shortest duration, the project completion time will be 3 as shown in the table. These just have tried several heuristics to solve the resource limitation problem. All the heuristics used day by day or week by week, depending upon the initial measurement for the activity durations in terms of scheduling. On any given day, among the activities that can be started with the resources that are available, give preference to the activities according to your specified rule. Tie breaking rules maybe suicide are maybe done randomly. Besides the minimum slot rule, researchers have tried the shortest duration rule, longest duration rule, most successes rule, most immediate successes, and a few other more complicated rules for solving randomly generated projects with resource requirement. The minimum slack rule seems to give good schedule most of the time. In general, how is difficult to know how good is a solution given by a heuristic when compared to the unknown best solution. Of course, one can always compare the project completion time arrived by using the heuristic. With the lower bound on the project completion time arrived at by finding the project completion time without the resource limitations. Commercially available software suggests MS Project, Oracle's prime aware seem to give reasonably good schedules when there are resource limitations. Moreover, the software provides a lot of flexibility in terms of scripting activities, use of different types of resources, non-uniform requirements of resources for the duration of an activity, non-availability of resources during specified periods, etc. But the organizations that sell their software do not reveal the heuristic rules that are used, because it is their unique selling proposition. If one is thinking of purchasing a software, it is better to first get the software on a trial basis and solve for scheduling different projects that were undertaken earlier are likely to be undertaken in the future. Depending upon this somewhat limited experience with the software, one can decide whether to purchase the software or not. This concludes our module on resource scheduling. In the next module we will briefly describe the main features of critical chain project management pioneered by Eliyahu Goldratt. [MUSIC]
