Resource-driven scheduling refers to the MS Project feature whereby if, once resources have been assigned to a task, the resource assignment is changed, then the task’s duration will be recalculated. Resource-driven scheduling applies only to auto-scheduled tasks.
Resource-Driven Scheduling Example
Consider the following simple project:
Preparation currently has two resources assigned to it, Fred and Laura. It is of 6 days duration.
When a task’s duration is entered then, if the units are not either minutes or hours, Project will convert the duration to hours using the following settings:
File>Options>Schedule >Calendar Options:
The default values are as shown above. Hence for this 6-day task, the duration would be calculated as 48 hours. Project then takes this hours duration and matches it up on a day-to-day basis with the project’s calendar. It does not simply check whether a particular day is working or not; it will count the number of working hours in each day, as given by its working times. For each day, it will subtract the number of working hours from the task’s duration until zero is reached. This then sets the end date. If some days are, say, half-days with 4 rather than 8 hours, then the end date will be later than expected.
It is most important, therefore, to treat the duration, when first entered, as a measure of the total work expected to complete the task rather than necessarily just an estimate of its length.
If changes are made to the default working times, then it must be ensured that these options match the default times in the calendar. If, say, the calendar has been set to 7 hrs/day but the options are still 8 hrs/day, then the dates will be significantly out. The following will happen:
Suppose the user enters a task with a duration of 10 days. They mean 10 7-hour days, hence 70 hours total. However, Project will use the options to calculate an inflated figure of 80 hours. It will then start matching this figure to the calendar. At the end of the first day, 7 hours out of the total will have been used up, leaving 73 hours; at the end of the second day a further 7, leaving 66 hours and so on. It will actually take about 11.5 of the calendar’s 7-hour days, rather than 10, to use up the 80 hours figure, and the end date will be about 1.5 days late. This will be the case throughout the project.
If the task has resources assigned, then Project will use the task’s duration to calculate a total work figure for the resource based on:
Work per resource=Duration(hrs)*Units assignment(%)
If one of these three quantities is changed, one of the other two will be recalculated proportionately, while the third remains unchanged.
So in the resource-driven scheduling example shown, where Fred and Laura have been assigned to work full-time on the 6-day task of Preparation, Project would have calculated that each have 48 hours of work to complete. Rather than matching the hours duration to the project calendar, it matches each resource’s work to the resource’s calendar using the same mechanism as described above. Since resources may have calendars very different to that of the project, this may result in a change in the finish date and duration; for example if Fred takes time off during this task, then he will finish his share of the work later than Laura, and the task’s end date will be delayed accordingly. So in resource-driven scheduling Project would increase the duration, even though the total amount of work is the same.
A task may also be effort-driven. When resources are assigned to a task, Project also calculates the total effort, which is simply the total work. So here, the total effort for Preparation is 96 hours. Suppose that a further resource is assigned. If the task is effort-driven, then Project will assume that the total effort is still 96 hours, but is now shared between three resources. Hence the work per resource drops to 32 hours and the task’s duration is reduced to four days. Conversely, if either resource is removed, the duration would double to 12 days, as now a single resource has to do all the work! If not effort-driven, then the duration would remain at 6 days, and the total effort would be recalculated.
To edit the effort driven setting, select the task, and click Task>Properties>Information to display the Information dialogue box for the task. Select the Advanced tab to locate the effort-driven option:
To set the default for tasks added to a new Project, select File>Options>Scheduling options for this project:
By default, in Project versions 2010 and 2013, new tasks are not effort-driven.
A Project may have a mixture of effort-driven and non-effort-driven tasks. Whether this is appropriate or not for a particular task will depend on the task itself and the extra resources being assigned.
Resource assignment may also be changed by changing the Units assignment for a particular task, rather than adding or removing resources. Note that Implementation, a three-week task, has four implementors assigned to it (a total of 3 weeks*40h per week *400% = 360h work).
Suppose that two of these were required elsewhere, and the assignment was changed to 200%. If the task type is Fixed Units, then it would be assumed that the remaining two still have the same amount of work to do, thus resulting in the task’s duration increasing to 6 weeks. Similarly, an increase in the Units assignment would result in a proportionate decrease in the duration.
The Task Type field may be accessed in the same way as the effort-driven option, via the Advanced tab of the Task Information dialogue box:
To switch this off, and hence ensure that the duration remains the same and the resource’s work is recalculated instead, set the task type to Fixed Duration. The default task type for new tasks may also be set from the Options dialogue:
This is normally set to Fixed Units.
To learn more about Resource-Driven Scheduling Systematix offers a range of Microsoft Project training courses.
Microsoft Project Resource-Driven Scheduling Related Links
25 May 2016