Resource allocation and crashing

Created by Jesper Antonius Wolters

Abstract

Common to all projects is the need to allocate available resources in the best possible manner. Resources are not infinite and in order to obtain the most optimal result, they have to be allocated thoughtfully. If done correctly by the project manager, she can optimize the way the project uses it resources and minimize the negative effect of unforeseen events. However, if done casually, this might result in delays, penalty fees, using unnecessarily many resources on wrong events and not on critical events. From this article, the PM will learn techniques to help allocate resources efficiently in order to avoid the situations described above. In addition, by analyzing the possibility of crashing the project, the project manager might be able to find a more optimal solution than would be possible by the simple PERT/CPM analysis, this analysis thus builds upon a PERT/CPM analysis. This article aims at giving the reader a greater understanding of how to allocate resources to a project as well as presenting an example of how a project could be crashed. Three different techniques to resource allocation will be presented and explained in depth. Furthermore, in order to give the reader a greater understanding of how resource allocation can effect a project, positively as well as negatively, two examples using CPM crash heuristics will be presented.

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

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.

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

1. 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.
2. Update the critical path
   As mentioned earlier, crashing of the existing critical path will lead to another path eventually becoming the critical path. The PM has to check which path is the critical after each partial crash.

Figure 6: Time-cost curve

Annotated bibliography

Fast tracked project Calculate