The unreasonable boss problem in Chapter 5, Section 5.2 could be used as our example here, but a smaller problem will help avoid unnecessary arithmetic. Our problem is set in a deterministic world rather than in a probabilistic one, for the same reason. (Please remember that in reality all projects are carried out under conditions of uncertainty.) Finally, we must also take note of an assumption usually adopted when activities are scheduled, as we did in Chapter 5. That assumption is that all estimates of task duration, whether deterministic or probabilistic, are based on normal or standard resource loadings.
1. The Critical Path Method
In traditional PERT/CPM, the rules of “standard practice” apply and the normal task duration estimate is made with the normal or standard-practice resource usage. Then a second estimate, referred to as the crash duration, is made based on the resources required to expedite the task. More resources of the type already used might be added; more workers and shovels if there is a ditch to be dug. On the other hand, the technology used to dig the ditch might be totally altered, utilizing a backhoe or a Ditch Witch®, for example. When making estimates for crashing, it is important to make sure that the resources required to crash the project are, in fact, available. Using a machine to dig the ditch in three hours instead of the 3 days required for a worker with a shovel is dependent on the fact that the machine is available and can be on site when needed. (Of course, the warning about resource availability applies equally to normal resource requirements as well as to crash requirements.) There are times when the PM may expedite activities that have little or no impact on the network’s critical time, such as when the resources used must be made available to another project. It is important to remember that when we change technology, we may also be changing the level of risk in carrying out the activity. Finally, we must remind ourselves that some tasks cannot be crashed. One must not assume that because it takes one woman 9 months to carry and bear a child that nine women can accomplish the same result in 1 month.
Consider the project described in Table 6-1. There is a set of activities, predecessors, normal task duration estimates, crash duration estimates, and estimates for normal cost and crash cost. One crash duration is marked with a single asterisk. For this activity, the task may be carried out in normal time or crashed 1 day at a time. Another activity is marked with a double asterisk. In this case, the duration must be one or the other; it cannot be broken down to 1-day segments. Activities are charged at the “cost per day” (activity slope) increments shown in the last column. A given activity may have only two or three technically feasible durations. If an activity cannot be split into 1-day segments, the cost is as indicated. The “slope” information for non-or-partially segmented activities is normally given in the slope chart. Activity slope is computed as follows:
When crashing a project, starting with the normal schedule for all project activities, crash selected activities, one at a time, to decrease project duration at the minimum additional cost. To crash a project, follow two simple principles: First, focus on the critical path(s) when trying to shorten the duration of a project. Crashing a noncritical activity will not influence project duration. Second, when shortening a project’s duration, select the least expensive way to do it.
Given these guides, consider the network shown in Figure 6-1 (a) that was constructed from the data in Table 6-1. It is easier to illustrate the impact of crashing on an activity-on-arrow (AOA) network than on an activity-on-node (AON) network, so we use that approach here. Also, we use dummy activities in this case not to illustrate precedence but to show time durations and slack on the time axis.
As indicated in Table 6-1, activity d can be partially crashed for $30, but it is not on the critical path and will not shorten the project. Activity e involves a technological discontinuity and must take either 3 days to complete at $10 or 1 day at $80. In general, the impact of having such a technological discontinuity is that the best solution for crashing n days might not be part of the best solution for crashing n + 1 days. Rather, it may be best to crash the activity with the technological discontinuity at n + 1 days and not crash another activity that could be crashed for n days. This situation is illustrated in the discussion that follows.
The network’s critical path is a-b-e, the project duration is 8 days, and the normal total cost is $120, as illustrated in the network of Figure 6-1(a). The decision about which activities to crash depends on how much we need to reduce the duration of the project. To reduce the total network duration by 1 day, we must reduce the time required by one of the activities along the critical path. Inspecting Table 6-1 to see which critical activity can be reduced at the least cost, we find it is activity a, which adds $40 to the project’s current cost of $120. Activity b could be crashed at an added cost of $60 or we could even crash e 2 days for an additional cost of $70. Of course, crashing e would only shorten the project duration by 1 day because when e is shortened, the path a-d-dummy, 7 days long, becomes the critical path and does not allow the project to be shortened to 6 days. Of the three options, crashing a is the lowest cost and therefore preferable, see Figure 6-1(b). Notice that crashing a also shortens a-d-dummy and a-c-dummy by 1 day.
Suppose the project must be crashed by 2 days. What are the options? Reconsidering Table 6-1 and Figure 6-1(a), we see that we could crash activity e for 2 days ($70), but path a-d-dummy (7-days’ duration) must also be crashed at least 1 day. We choose d ($30/day) because it is cheaper than a ($40). The total cost of crashing is $100, and the total project cost is $120 + $100 = $220. Alternatively, we could crash a and b, also for a cost of $100 ($40 + $60). Arbitrarily, we choose the latter option [Figure 6-1(c)].
Now suppose we wanted to crash the project by 3 days, from the original 8 days down to 5 days. Clearly e must be crashed by 2 days, costing $70, and a or b by a day. We choose a, the cheapest, for an additional $40. This leaves d to be crashed by 1 day for another $30, resulting in a total crashing cost of $140 and a project cost of $120 + $140 = $260 [Figure 6-1(d)]. Note that we did not crash b this time, as we did for 6 days. This is due to the technological discontinuity in activity e.
Last, let us consider crashing the project by 4 days down to a project duration of 4 days. Since we crashed e, the technological discontinuity, to reach a 5-day duration, all the remaining activities can be incrementally crashed. Thus, we can simply inspect Figure 6-1(d) to see what else needs incremental crashing to reduce the project by another day. Notice in Figure 6-1(d) that a-b-e and a-d-dummy are both critical paths. Only b and d can still be crashed so we crash each by 1 day for an additional cost beyond the 5-day schedule of Figure 6-1(d) of $60 + $30 = $90 for a total project cost of $260 + $90 = $350 [Figure 6-1(e)]. Note that c is now critical; therefore, all paths are critical. Since the critical paths a-b-e and a-c are at their full extent of crashing, the project duration cannot be further reduced, even though activity d could be crashed another day. Thus, Figure 6-1(e) is not the all-crash network, although it equals the all-crash time schedule of 4 days.
Whether all this crashing is worthwhile is another matter. On the cost side, Figure 6-2 shows the time/cost relationship of crashing the project. On the benefit side, some projects have penalty clauses that make the parent organization liable for late delivery—and sometimes bonuses for early delivery. Starting at the right (all-normal) side of Figure 6-2, note that it becomes increasingly costly to squeeze additional time out of the project. Charts such as the one shown in Figure 6-2 are useful to the PM in exercising control over project duration and cost. They are particularly helpful in dealing with senior managers who may argue for early project completion dates with little understanding of the costs involved. Similarly, such data are of great benefit when clients plead for early delivery. If the client is willing to pay the cost of crashing, or if the firm is willing to subsidize the client, the PM can afford to listen with a sympathetic ear. (While we advise the PM to ignore overhead costs over which he or she has no control, it should be noted that indirect costs are often altered when a project is crashed.)
One final note on crashing projects. The same method is used when the task durations are probabilistic, that is, using three-time estimates. In this case, optimistic, most likely, and pessimistic activity duration estimates are made for the “normal” resource loading and new optimistic, most likely, and pessimistic duration estimates must be made for crash resource loading. The PM should remember that the variance of both the normal and crash activity times largely depends on the technology used to accomplish the activity in question. Thus the variance of the normal activity time may be quite different from the variance of the crash time. The project budget can be determined in exactly the same way. The solution to project duration and resource cost levels can be reached by using the standard analytical method used in the last chapter, or by simulation, also described in Chapter 5.
2. Crashing a Project with Excel
In this section we demonstrate how spreadsheets can greatly facilitate the task of choosing which activities to crash such that the project can be completed by a specified time. To illustrate this, we use the previous example with one minor change. Namely, we assume that partial crashing is allowed for all activities that can be crashed. The network for the example and the spreadsheet developed to solve the problem are shown in Figures 6-3 and 6-4, respectively.
At the top of the spreadsheet shown in Figure 6-4, columns A through F contain the information given in the problem. In column G, the crash cost per day (slope) is calculated by dividing the incremental cost of crashing the activity as much as possible by the maximum number of days the activity can be shortened. For example, the formula =(E2- F2)/(C2-D2) was entered in cell G2 and then copied to other cells in column G (except for activity c which cannot be shortened).
Column H contains a formula to calculate the maximum number of days an activity can be crashed by subtracting the crash time from the normal time. For example, the formula =C2-D2 was entered in cell H2 and then copied to the other cells in column H.
Column I corresponds to one of our decision variables, namely, the amount to crash each activity. In column J, the cost of partially crashing an activity is calculated on the basis of the amount of time the activity is to be crashed as determined in column I. For example, the formula =I2*G2 was entered in cell J2 and copied to the other cells in column J. The total crashing cost is calculated in cell J7 as the sum of the cost of crashing the individual activities in cells J2:J6.
In column K, the actual time to complete each activity is calculated by subtracting the amount the activity is crashed (column I) from its normal time (column C). For example, the formula =C2-I2 was entered in cell K2 and then copied to the other cells in the column.
The middle of the spreadsheet shown in Figure 6-4 (cells B11:B14) are for the other decision variables needed. More specifically, cells B11:B14 correspond to the event times for each of the nodes in the network diagram. (Node 1 is excluded because we assume it occurs at time zero.) As you will see, we need these decision variables to preserve the precedence relationships shown in the network. For example, we need to make sure that node 4 does not occur until after node 2 occurs, plus the time it take to complete activity d.
We now demonstrate how Excel’s Solver can be used to determine which activities to crash so that the entire project is completed with 5 days at the minimum cost. To begin, we select Solver from the Data ribbon (note that Solver is an Excel add-in and must be added before it can be used). The Solver Parameters dialog box is now displayed (see Figure 6-5). Our objective is to minimize the total crash cost which is calculated in cell J7. To specify this, we enter cell J7 in the Target Cell box and then select the Min option button. Next, we tell Excel which cells it can change in order to find the solution with the least total crashing cost. In the spreadsheet shown in Figure 6-4, the values that can be changed are the amount of time each activity is crashed (cells I2:I6) and the time when each event occurs (cells B11:B14). Thus, these ranges are entered in the By Changing Variable Cells box. Note that these two separate ranges are separated by a comma in the By Changing Variable Cells box (see Figure 6-5).
The last task is to enter the constraints for the problem. Perhaps the most obvious constraint is that we want to complete the project within 5 days. Since node 5 (cell B14) corresponds to the event of the project being completed, we can specify this constraint as follows:
B14<=5
Another important set of constrains that needed is to make sure that we don’t crash an activity more than the maximum number of days that is can be crashed. For example, to ensure activity a is not crashed more than it can be physically crashed, we could enter the constraint I2 <= H2. Taking advantage of Excel’s ability to work with ranges, the constraints to ensure all activities are not crashed more than their crash limit can be entered as:
I2:I6<=H2:H6
Another set of constraints are needed to make sure that the precedence relationships specified in the network are not violated. We do this by keeping track of the event times of the nodes. For example, the event time of node 2 cannot occur until after activity a has been completed (assuming the project begins at time zero). The time to complete activity a is its normal time less the amount of time it is crashed (which is calculated in column K). Since cell B11 corresponds to the event time for node 2, mathematically we could enter this constraint as follows:
B11>= K2
This constraint says that the event corresponding to node 2 cannot occur until after activity a has been completed.
Constraints for the other nodes are developed in a similar fashion. For example, the constraints for nodes 3 and 4 would be:
B12>=B11 + K3
B13>=B11 + K5
Moving on to node 5, note that this node has three arrows leading to it. A node with more than one arrow pointing to it will need a separate constraint for each such arrow. Thus, we need the following three constraints for node 5:
B14>=B12 + K6
B14>=B11 + K4
B14 >=B13
The entire set of constraints as well as the other information entered into the Parameters Dialog box is shown in Figure 6-5. Note by checking the checkbox Make Unconstrained Variables Non-Negative, we do not need to add constraints to ensure each decision variable is greater-than-or-equal-to zero.
After filling in the Solver Parameters dialog box as shown in Figure 6-5, the lowest cost plan to complete the project in 5 days can be found by clicking on the Solve button. This plan is shown in Figure 6-6. According to the plan activities a and b are crashed 1 day, activity d 3 days, and activity e 2 days (refer to column I). The extra cost of reducing the project to 5 days is $260 (cell J7).
3. Fast-Tracking a Project
In addition to crashing a project in order to expedite it, a project may also be fast-tracked. Used primarily in the construction industry, the term refers to an expediting technique in which the design and planning phases of a project are not actually completed before the building phase is started. Usually design and plan are finished before the building is started (referred to as the “waterfall” approach), so letting them overlap reduces project duration—if the fact that design and planning are incomplete does not result in a significant amount of rework and change orders during the building phase.
For many projects in construction, maintenance, and similar areas, a large proportion of the work is routine. In these cases, fast-tracking rarely causes serious problems. The number of change orders in fast-tracked construction projects is not significantly different from that for similar projects that were not fast-tracked (Kurtulus and Narula, 1985).
4. Project Expediting in Practice
Expediting can occur in three different ways. First, the PM may know ahead of time that this is a time-critical project and will need to take steps to finish the project as early as possible. Second, the PM may get the word during the execution of the project that the due date has had to be moved up. Or finally, something happens during the project to delay some activities so that the due date is going to be missed. In all cases, the sooner the PM knows that the project needs to be expedited, the more opportunities there will be to bring the project in ahead of time, or on time if a delay occurred. Whenever it appears that the project may be later than the stakeholders expected, it is imperative that the stakeholders be informed immediately and kept apprised of the follow-on developments as they occur. We can divide the opportunities for expediting a project into those that occur before the project begins and those that are available once the project is under way.
Opportunities Before the Project Begins First, it is worth noting that most of the time in practice, projects are not planned using the three-time method of estimating (i.e., optimistic, most likely, pessimistic). Instead, PMs simply try to get a reasonably accurate estimate of each activity time from those who will be responsible for the activity or, failing that, estimate the time themselves. Then, after they determine the critical path, they often add a cushion or “buffer” to the critical activities’ times in case they turn out to be too optimistic (i.e., short). Next, to account for the possibility that other paths may turn out to be critical instead, a project time contingency, which is noted as such, is added as well.
Also, they may try to identify the “key” activities and deliverables (that is, those that have the biggest effect on the schedule or success) and plan to monitor those especially closely. To be safe, they may even order the long-lead time items early, or arrange for possible airlifting of those items if expediting is later deemed necessary.
Opportunities When the Project Is Underway If the need to expedite occurs once the project is underway, there are many actions PMs may try in order to expedite the project, as follows:
- First, they will focus on the critical path and see if there is any way to shorten it. If they haven’t already, they will identify the key activities that would help expedite the project and manage those extremely closely, making sure that they don’t use up their activity time cushions/buffers.
- In a similar vein, they may request permission to use some of the contingency time they budgeted for the project.
- They may pull resources from less critical activities, activities with a surplus, or just chronologically later activities, to apply to more critical, earlier activities.
- Similarly, they may move later activity time cushions/buffers up to earlier, more critical activities.
- They may try to shorten, or even skip, certain steps like testing, documentation, or training.
- They may postpone activities that involve non-core team members, or other stakeholders.
- They may move some activities to a post-project phase, such as installation, implementation, or service.
- They may see what activities they can “fast-track” (run in parallel), or even what activities can be done early or ahead of time (e.g., on weekends), which most commonly are those that do not involve the user or other stakeholders.
- They will try various forms of “compression” such as pressuring the team to work harder or faster, or get permission for overtime.
- They may attempt to get additional resources, either money for overtime or additional people to work on the project.
- They may seek permission to reduce the scope of the project, so the critical deliverables can occur on time.
- Finally, for PMs with lots of experience with projects such as these, they may simply choose to wait and see if something comes up later that allows them to make up the time. (Less-experienced or younger PMs are typically too risk averse and have less self-confidence to try this.)
When task durations are estimated, an assumption is made that task resources are set at “normal” levels. This is the “standard practice” assumption. Traditionally, CPM project duration estimates also include a “crash” estimate together with estimates of the crash time and the resources required to shorten the duration of project activities. By selectively choosing which activities to crash and by how much, we can determine the minimum cost for all possible project completion times.
Source: Meredith Jack R., Mantel Jr. Samuel J., Shafer Scott M., Sutton Margaret M. (2017), Project Management in Practice, John Wiley & Sons, Inc. 3th Edition.
I waѕ able to find good information from your bloց posts.