Resource allocation and crashing

Created by Jesper Antonius Wolters

Abstract

Common to all projects is the need to allocate available resources in the most efficient way possible. Resources are not infinite and in order to obtain the most optimal result, they will have to be allocated thoughtfully. If done correctly by the project manager, she can optimize the way the project uses its resources, minimize the negative effect of unforeseen events. However failure to do so might result in delays, penalty fees, using unnecessarily many resources on wrong events and not on critical events. This article aims to describe how a PM can get an overview and best allocate her resource to a given project, aided by an example. The PM might want to take it a step further and crash the project when the resources have been optimized for the initial plan. Crashing is a way of compressing a projects duration using the minimum amount of extra resources. Most projects will in some way or another experience crashing. Be it because it is running behind and needs to catch up with an already agreed upon deadline, or because the project owner wants the project done faster than the duration which the project manager has presented. This article aims to build upon a PERT/CPM analysis and describe the theory behind crashing a project and how a PM might apply it to her own project.

Resource allocation

In project management, the term resource allocation covers the action of allocating resources to specific activities or people, in order to reach a goal set by the project manager. The project might have a limited amount of resources at any given point in time which challenges the project manager to make sure that resource capacity is neither wasted nor that extra resources need to be bought externally. By smoothing out the resource requirement over the life cycle of the project, it makes it easier to add a buffer, which in turn can help the project manager to avoid delays, expensive penalties for not meeting deadlines, the need for hiring extra personal and avoiding bad work ethic as a result of overtime. "One cannot save time - one can only spend more of less of it."

Resource loading

"Resource loading describes the amounts of individual resources an existing schedule requires during specific time periods." As described in the abstract, the resource loading builds upon a CPM/PERT analysis. The resource loading technique includes the problem of resources whereas a CPM/PERT analysis assumes that there are infinite resources. . This is the main problem with just doing a CPM analysis, projects do not have infinite resources! Assuming that a CPM analysis has been made and a Critical Path established, the first step of resource loading is to identify the types and quantities of resources, and spread them by a schedule across specific time periods. The aim is to identify and reduce excess demands on a company's resources. It is important to mention that by allocating twice as many resources to one activity does not mean that it will be completed in half the time originally planned. In order to better illustrate the challenges arising when including resource loading to a CPM/PERT analysis, a short example, project X, is presented. From figure 1, a simple project is presented and from the AON network created on figure 2, the critical path is found to be ABFI Without taking resource loading into account, this might be enough to say that ABFI is the critical path, but by taking into account the amount of workers needed for each activity, the PM gets more insight into the resource required at a given point in time.

• 

  

  Figure 1: Project X
• 

  

  Figure 2: Activity on Node network
• 

  

  Figure 3: Resource loading graph

From this simple example it is clear that the simple CPM/PERT analysis using early start times will result in a congestion of required workers in the beginning of the project, whereas the end of the project requires very few workers in comparison. It can also be seen from figure 3 that there are opportunities for the PM to utilize the slack, or late starting times, of each activity in order to try and even out the workers required over the duration of the project. The author will not go into detail about slack and late start times, but refers to the article on REF CPM/PERT.

Resource leveling

Resource leveling has been investigated since the early 1960s and can be defined as "Aiming to minimize period-by-period variations in resource loading, by shifting tasks within their slack allowances." The technique is applied to projects in order to more evenly distribute the required resources needed from period-to-period. This means aiming for a resource graph that is as smooth as possible while of course simultaneously reaching the required deadline. It takes advantage of the slack of activities and the possibility of starting and ending activities depending on the resources needed for activities running simultaneously. This can often cause the critical path to change.

Figure 4: Steps of resource leveling in project X

Returning to project X from previous chapter, it is obvious that it is possible to apply the theory of resource leveling to this project in order to smooth out the worker requirement over the life cycle of the project. Activity H just has to be completed after C, D and E and before I, and can thus be started later without affecting the critical path of the project. Next, activity G can also be started later. The maximum amount of workers is still the same and occurs in weeks 2 to 5. This can be avoided by starting activity E and D later which will also not affect the critical path. The steps and final result of using resource leveling can be seen on figure 4. By this simple analysis the required amount of workers has been smoothed out and the maximum amount of workers needed at any given time reduced from 22 workers to 13 workers. This has a positive effect on the project in the form of less day to day resource manipulation, better morale and fewer HR problems/costs. It furthermore simplifies costs which in turn simplifies budgeting and funding. This is of course a simple example with just 1 resource, whereas most projects will have several resources, with big project even more. Here the object is to minimize the sum of squares that the resource requires for each resource. The ideal project would then be a perfect square/rectangle using the same amount of resources all the time. However this is rarely possible and most projects will have either idle resources or the need to obtain more resources for specific resource heavy periods at a higher cost.

Crashing a project

The crashing of a project is the act of shortening the duration of a project by tactically and most cost efficiently allocating more resources to activities on the critical path. This can be in the form of using specialized or additional equipment, borrow staff, using temps, get people to work more hours (in the weekend or overtime). This of course comes at an extra cost in many different forms such as money, negative effects on other projects and reduced morale in workforce from overtime. Thus crashing of a project created a ripple effect of potential problems and the PM thus has to try and find the most cost-efficient activities to crash in order to minimize the negative impacts.

Steps

For a project manager to crash a project most efficiently, she can follow the steps shown below

Figure 5: Slope indicating cost per day of crashing a project

Figure 6: Time-cost curve

1. Create a Activity on Node network.
   The Activity on Node network is critical in order for the project manager to get an overview of the project. For an example of a AON network see figure 3 from project X.
2. Define the critical path
   From the AON network the critical path should be found. This is important as it singles out the activities that makes most sense to crash. It does not make sense to crash an activity that isn't critical, as this does not affect the duration of the project. Furthermore it has to be noted that when crashing activities on the critical path, this will eventually lead to another path being the critical path and might even result in multiple critical paths.
3. Calculate the cost/time slope for each activity that can be crashed.
   This step defines the activities that yields most value for money, meaning period for period they cost the least to crash. Figure 5 illustrates the formula.
4. Determine crashing sequence
   With the cheapest crashing options defined, the PM can determine the crashing sequence by crashing activities from cheapest to most expensive. This will result in a time-cost curve as can be seen from figure 6. From the curve it can be seen that the duration of the project will decrease with increasing cost. It can also be seen that the more time is saved, the steeper the curve gets, as the crashing per activity cost increases until it doesn't make sense to crash the project anymore. One aspect to keep in mind when determining the crashing sequence is that of partial crashing. Some activities might not allow partial crashing, meaning that it cannot be crashed on a period to period basis, but rather has to be crashed in e.g. 4 period intervals. This might cause problems if only 2 days are needed to be crashed, as this makes the last 2 days saved useless.
5. Update the critical path
   As mentioned earlier, crashing of the existing critical path will lead to another path eventually becoming the critical path or even lead to multiple critical paths. The PM has to check which path is the critical after each individual crash.

Conclusion

Resource allocation can be described as a scheduling of activities, in this article done by an AON network, and a scheduling of the resources required by those activities, in this article done by resource loading, so that predetermined constraints of availability of resources are not exceeded, in this article done by resource leveling. This results in a project that has an even distribution of resources in the duration of the project. The project manager has to carefully think about how to allocate resources in order to avoid under allocation of resources which may result in delays, and too much over allocation of resources which will result in idle, wasted resources.

Crashing a project is a good way to save time by allocating more resources to activities in order to finish them earlier. There are several steps that a PM has to follow in order to successfully crash a project as efficiently as possible. These include finding the cheapest activities to crash and the critical path. Crashing the cheapest activities on the critical path while continuously updating the critical path as this might change.