Revision as of 13:21, 28 February 2019

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 and 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 will most likely 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 brought in externally. By smoothing out the resource requirement over the life cycle of the project, the PM ensures that the fluctuation of resources between periods are minimized. This then 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. By spending some time to do resource allocation in the beginning of a project, the PM will be less likely to sit with the headache of having to deal with such problems in the end.

Resource loading

"Resource loading describes the amounts of individual resources an existing schedule requires during specific time periods." ^[1] Resource loading builds upon an intial CPM/PERT analysis where the critical path has been well identified, meaning that slack for each activity, early start time, late start time, early finish time and late finish time have been established. The CPM assumes that there is access to an infinite amount of resources ^[2] Refinery Flare Header Replacement Project (https://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?referer=https://www.google.com/&httpsredir=1&article=1076&context=cmsp </ref>., which is a major simplification to any project. A realistic project schedule should carefully describe how many, which and when specific resources are available to the project. 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, in specific time periods. 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 A-B-F-I. Without taking resource loading into account, this might be enough to say that A-B-F-I is the critical path, but by taking into account the amount of workers needed for each activity, the PM gets more insight into the resources required at a given point in time.

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 PERT/CPM

Resource leveling

Resource leveling has been investigated since the early 1960s ^[3] and can be defined as "Aiming to minimize period-by-period variations in resource loading, by shifting tasks within their slack allowances." ^[4] 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. ^[5]

Figure 4: Steps of resource leveling in project X

Revisiting 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. ^[6] 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

"Schedule compression techniques are used to shorten or accelerate the schedule duration without reducing the project scope in order to meet schedule constraints, imposed dates, or other schedule objectives" ^[5] One of these schedule compression techniques are crashing. 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 creates 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. In order to best illustrate

Steps

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

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

Figure 6: Time-cost curve ^[7]

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.

Crashing of a project is not always the best option and might even lead to increased risks. Therefore it is of utmost importance that the PM has thoroughly weighed up the negative effects against the gains when deciding to crash a project.

Limitations

As the project manager it is important to take into account the limitations that come with using the above mentioned strategies. When doing resource loading most projects will have more than just one resource to allocate. This makes it more complicated than what is described in this article. However the principle is the same, but for simplification the example in this article just has one type of resource. To get a more comprehensive explanation of what it means to have a project with more than one resource to manage, it is recommended to check out source number 6. Crashing a project is a great way to save valuable time if unforeseen events have delayed to project, but it comes at a cost and certain risks. The same amount of tasks are condensed into a shorter time period and therefore need more resources. The risks involved are that crashing initially focuses on the critical path. Crashing of this critical path might result in affecting non-critical path. Thus by solving one problem, another one might arise and need attending. Another risk is the fact that the new resources that are added into crashing an activity are often not as efficient as the existing resources being used on that activity. For example, allocating more people to a task that they are not familiar with will not be as effective as the people that have already worked on the project. As mentioned in the article “Allocating twice as many people to an activity will not cut the time it takes to complete in half” This poses a challenge for the PM and might be time consuming. However, done right there are plenty of time and money to save by crashing a project.

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, ^[8] 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.

Annotated bibliography

• Project management a managerial approach 7th Edition - A comprehensive book covering most aspects of basic project management. It consists of a lot of examples giving the reader a very good understanding of how to apply the theories and methods presented in the book.
• https://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?referer=https://www.google.com/&httpsredir=1&article=1076&context=cmsp An article comprehensively describing the differences between using the CPM method and the resource loaded scheduling method. It highlights the problems with only relying on CPM and why one should supply it with a resource loaded scheduling method.
• Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition) Chapter 6 A book briefly but concretely describing most relevant terms used in this article, such as crashing, resource leveling, CPM etc. Great for looking up a quick description of a theory or model.

References

1. ↑ Meredith, Jack and Mantel, Samuel (2009) "Project management a managerial approach 7th Edition
2. ↑ Carone, Conor, California Polytechnic State University The Differences Between CPM and Resource-Loaded Scheduling and How They Applied to The Martinez Tesoro
3. ↑ https://link-springer-com.proxy.findit.dtu.dk/content/pdf/10.1007%2F3-540-27852-4.pdf
4. ↑ dr. ir. Broekmeulen. Rob "Slides from course 1CM900 Project Management at Eindhoven University of Technology"
5. ↑ ^{5.0 5.1} Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition) Chapter 6
6. ↑ https://www.sciencedirect.com/science/article/pii/S0377221799004907
7. ↑ ^{7.0 7.1} Kelly, É. V. (2009). Crash with confidence. Paper presented at PMI Global Congress 2009 - North America, Orlando, FL. Newton Square, PA: Project Management Institute.
8. ↑ https://project-management.com/pmo-and-project-management-dictionary/