How sensitive are your project resources? I'm not asking whether your team members cried at their best friend's wedding, I'm asking if you know how different resources affect your overall schedule.
The conventional approaches to resource scheduling are called resource levelling and resource smoothing. The first has the objective of keeping resource usage below your stipulated limits regardless of the effect this has on the time schedule. The second maintains the finish date calculated by a critical path calculation and smooths out the use of resources as much as possible.
The shortcoming of these two methods, as usually implemented in project scheduling software, is that they only give two possible solutions to the issue of juggling time and resource. There is actually a wide range of potential compromises between finishing the project by a specific date and performing it with specific levels of resource.
Iterations of project completion date, resource availability and resources can provide a much more accurate picture of what are the key resources and how their availability affects the completion date.
This is sensitivity analysis applied to resource scheduling.
A normal resource levelling calculation will calculate the completion date of a project taking into account defined limits on all project resources. If this results in (say) a 10 week delay in the completion date (past the critical path analysis result) there is a significant probability that the delay is substantially due to one resource rather than a combination of all resources.
Resource iterations can be performed by initially levelling on one resource only, then adding the next, levelling again and so on.
The diagram above shows a typical result of plotting the delay of the project completion date against the resources levelled. In this example a major increase in delay occurs when resource C is added to the levelling process; clearly it is this resource that is causing most of the delay in the completion date.
Having identified the ‘critical resource’ you can take a much more educated view of how to solve the problem than before.
The vast majority of project scheduling packages allow individual resources to be selected for resource scheduling and so working through these iterations is not too onerous.
Having identified which resource is causing the problem, there are two possible further iterations. These two approaches are based on the premise that neither the resource limit nor the completion date, is rigidly fixed. These iterations are designed to identify the optimum compromise between providing extra resources and an acceptable completion date.
First are the resource limit iterations, which increase the resource limit incrementally to assess the effect on the completion date. The relationship between increases in the resource limit and the resultant reductions in project duration are rarely linear. This process helps indicate the minimum increase in resource limit to achieve an acceptable completion date.
In this series of calculations, we have initially applied a limit of 5 people to resource C. When resource C is levelled there is a 11 week delay. If another person is added, the project completion is only delayed by 10 weeks. Having 7 people gets the delay down to 9 weeks.
The big difference comes when we have a total 8 people available. The delay then comes back to only 3 weeks. Applying another 3 people (from 8 to 11) only saves a further 2 weeks, and that may not be worth the cost.
Clearly, weighing up the costs versus the benefits, the optimum resource limit, for resource C, is 8.
The second approach is that of time iterations. This allows the effect of different completion dates to be assessed on many resources at once. In this approach an imposed finish date is applied to the last activity in the network. Initially, this date is the same as the critical path analysis completion date.
The imposed date is incrementally moved later and later and each time a resource smoothing calculation is performed. Resource smoothing evens out the usage of resources as much as possible without extending the completion date. Most software will highlight the amount of resource overload. Each time you move the completion date out, you note the resulting resource overload.
Once again, the relationship is not linear and the best compromise can be easily identified. In this case, accepting a
three week delay gives an overload of 40 man-days. Accepting a five week delay results in an overload of only 10 man days.
The five week delay would, therefore, seem like a good compromise. Refusing to accept the need for an extra 10 man-days will disproportionately delay the project for another five weeks.
The value of these iterations depends upon the importance of resource and time on your project. If you have limited resources but no time constraints – go for standard resource levelling. If you have a fixed end date and unlimited resource – use resource smoothing. Where you need a compromise between the two – try using this iterative approach to find the optimum combination of finish date and resources.
Unfortunately, there is no simple method to deal with the most common situation, i.e. fixed end date and fixed limits on resources!
