Example 4.24 Resource-Driven Durations and Resource Calendars

This example illustrates the effect of resource-driven durations and resource calendars on the schedule of a project involving multiple resources.

In projects that use manpower as a resource, the same activity may require different amounts of work from different people. Also, the work schedules and vacations may differ for each individual person. All of these factors may cause the schedules for the different resources used by the activity to differ from each other.

Consider a software project requiring two resources: a programmer and a tester. A network diagram displaying the activities and their precedence relationships is shown in Output 4.24.1.

Output 4.24.1 Software Project Network

Some of the activities in this project have a fixed duration, requiring the same length of time from both resources; others require a different number of days from the programmer and the tester. Further, some activities require only a fraction of the resource; for example, 'Documentation' requires only 20 percent of the programmer’s time for a total of two man-days. The activities in the project, their durations (if fixed) in days, the total work required (if resource-driven) in days, the precedence constraints, and the resource requirements are displayed in Output 4.24.2. There are two observations for some of the activities ('Product Design' and 'Documentation') which require different amounts of work from each resource.

The following statements invoke PROC CPM with a WORK= specification on the RESOURCE statement, which identifies (in number of man-days, in this case) the amount of work required from each resource used by an activity. If the WORK variable has a missing value, the activity in that observation is assumed to have a fixed duration. The project is scheduled to start on April 12, 2004, and the activities are assumed to follow a five-day work week. Unlike fixed-duration scheduling, each resource used by an activity could have a different schedule; an activity is assumed to be finished only when all of its resources have finished working on it.

proc cpm data=software out=sftout ressched=rsftout
         date='12apr04'd interval=weekday resout=rout;
   act act;
   succ s1 s2;
   dur dur;
   res Programmer Tester / work=mandays
                        rschedid=Activity;
   id Activity;
run;

The individual resource schedules, as well as each activity’s combined schedule, are saved in a Resource Schedule data set, RSFTOUT, requested by the RESSCHED= option on the CPM statement. This output data set (displayed in Output 4.24.3) is very similar to the Schedule data set and contains the activity variable and all the relevant schedule variables (E_START, E_FINISH, L_START, and so forth).

For each activity in the project, the Resource Schedule data set contains the schedule for the entire activity as well as the schedule for each resource used by the activity. The variable RESOURCE identifies the name of the resource to which the observation refers and has missing values for observations that refer to the entire activity’s schedule. The value of the variable DUR_TYPE indicates whether the resource drives the activity’s duration ('RDRIVEN') or not ('FIXED').

The DURATION variable, dur, indicates the duration of the activity for the resource identified in that observation. For resources that are of the driving type, the WORK variable, mandays, shows the total amount of work (in units of the INTERVAL parameter) required by the resource for the activity in that observation. The variable R_RATE shows the rate of usage of the resource for the relevant activity. For driving resources, the variable dur is computed as (mandays / R_RATE). Thus, for the Activity, 'Documentation', the programmer requires 10 days to complete 2 man-days of work at a rate of 20 percent per day, while the tester works at a rate of 50 percent requiring 2 days to complete 1 man-day of work.

pattern1 c=green v=s;     /* duration of a non-critical activity   */
pattern2 c=green v=e;     /* slack time for a noncrit. activity    */
pattern3 c=red   v=s;     /* duration of a critical activity       */
pattern4 c=magenta v=e;   /* slack time for a supercrit. activity  */
pattern5 c=magenta v=s;   /* duration of a supercrit. activity     */
pattern6 c=cyan v=s;      /* actual duration of an activity        */
pattern7 c=black v=e;     /* break due to a holiday                */
pattern8 c=blue v=s;      /* resource schedule of activity         */
 pattern9 c=brown v=s;     /* baseline schedule of activity         */

title h=2 'Software Development';
title2 h=1.5 'Project Schedule';

A Gantt chart of the schedules for each resource is plotted in Output 4.24.4.

Output 4.24.4 Software Project Schedule

Suppose now that you have only one tester and one programmer. You can determine a resource-constrained schedule using PROC CPM (as in the fixed duration case) by specifying a resource availability data set, RESIN (Output 4.24.6).

proc cpm data=software resin=resin
         out=sftout1 resout=rout1 
         rsched=rsftout1
         date='12apr04'd interval=weekday;
   act act;
   succ s1 s2;
   dur dur;
   res Programmer Tester / work=mandays addcal
                        obstype=otype
                        period=per
                        rschedid=Activity;
   id Activity;
run;

Output 4.24.8 Resource-Constrained Schedule

Now suppose that the tester switches to part-time employment, working only four days a week. Thus, the two resources have different calendars. To determine the effect this change has on the project schedule, define a calendar data set identifying calendar '1' as having a holiday on Friday (see Output 4.24.9). In a new resource availability data set (also displayed in Output 4.24.9), associate calendar '1' with the resource Tester and calendar '0' with the resource Programmer. '0' refers to the default calendar, which is the weekday calendar for this project (since INTERVAL = WEEKDAY).