• No results found

CORRECTIVE ACTIONS FOR DELAYED ACTIVITIES

When the project schedule is delayed, schedulers should try to reduce or remove any lag in the schedule prior to performing corrective actions, as these actions may cause issues in terms of project cost, or interferences between predecessor and successor activities. Therefore, schedulers should add buffers to the project schedule to mitigate activity delays.

The corrective actions in schedule management are techniques by which to recover the delayed activities so as to adhere to the project completion date. For efficiency, the corrective actions should be performed on critical activities first. There are two types of corrective actions for recovering delayed activities: crashing and fast-track. Crashing is a technique for reducing the durations of remaining activities by adding more resources based on Minimum cost expediting (MCE); fast-track is a technique for performing the remaining activities in parallel to compress the schedule.

Figure 117 – Calculation of acceleration cost per day

To implement the crashing technique, costs for crashing should be analysed, as shown in Figure 117. If all activities on the table are on the same critical path, Activity E should be crashed first because its acceleration cost per day is the lowest ($10); this is the MCE technique. The acceleration cost per day is calculated as (Crash cost – Normal cost) / (Normal time – Crash time). Below are crashing methods for recovering delayed critical activities:

• Conduct overtime – Change calendar work hours/day from 8 hours to 12 hours per day, for example.

• Enlarge working days – Change calendar working days from 5 days to 6 days per week, for instance.

According to schedule management theory, the fast-track technique does not increase costs to implement; however, rework can arise due to communication failure between predecessor activities and successor activities. Fast-tracking methods used in Primavera P6 change relationships from FS to SS with lag, as shown in Figure 118.

EXAMPLE

OF

CRASHING

BASED

ON

MINIMUM

COST

EXPEDITING

In Figure 119, a project has been delayed 10 days and a scheduler has to crash 10 days to meet the original project completion date. The blue boxes in the network schedule above the table are activities, and each of them has a letter and a number as its name and duration. The table below the schedule shows acceleration cost per day and remaining crash-able days.

The critical path of the project is A-E-G-H, which will be reviewed first to apply the crashing technique. It is reasonable to reduce the duration of the critical activities because the project duration is dependent upon them. Activity E is the best one to reduce since it has the smallest acceleration cost ($10) among the four options (A, E, G, and H). Schedulers should minimise the increased cost when reducing durations.

Figure 119 – Original schedule

The duration of Activity E can be reduced by only one day because the path A-B-C-D-H has also become a critical path, due to the reduced duration of Activity E. If Activity E is reduced by two days or more, the path A-E-G-H will become a non-critical path. Reducing a non-critical activity is not efficient. Now the total crashed duration is one day and the total cost for crashing is $10 in the first crashing, as shown in the table of Figure 120.

Since there are two critical paths in the project, two paths should be reduced at the same time. If only one of them is reduced, the project duration will not change. In the schedule, Activities A and H are the critical activities, and they are linked with the two critical paths. In this case, reducing only one can reduce the project duration. After review, it has been found that Activity H has the smallest crashing cost ($20 per day); two days of its duration can be reduced. In the second crashing, the total crashed duration is three days, and $50 is the total cost for crashing. Figure 121 – Second crashing The combination of Activities C and E has the smallest crashing cost ($35 per day); they can be reduced by two days. Figure 122 – Third crashing

Now Activity A is the best option; thus, its duration is reduced by three days, at an additional cost of $150. Figure 123 – Fourth crashing Finally, the durations of Activities D and E have been reduced by two days, at a cost of $100. The total crashed duration is now ten days, and the total cost for crashing is $370. Thus, the average crashing cost per day is $37. Figure 124 – Fifth crashing

Even though crashing has been introduced here to demonstrate how to apply the technique, engineers should take into account the circumstances of field sites before

accelerating work. Typically, the crashing cost increases geometrically over the duration. To put it simply, if the crashing cost is $10,000 for 10 days for a project, the crashing cost for 20 days may be $30,000 or more, as shown in Figure 125. Figure 125 – Crashing and cost increase

PROCESS FOR REVISING THE PROJECT SCHEDULE

It used to be that the project schedule was modified due to schedule delay, and rarely due to early-project-completion. No matter what the reasons for the schedule revision, schedulers should document the causes of the revision. If the reason comes from the client, the contractor will use the documentation for issuing claims; it can also be used as evidence in the dispute resolution phase later. Below are the steps for revising the project schedule: • Document the grounds for the schedule revision. • Prepare a draft proposal of the revised schedule. • Analyse the impacts of the revised schedule in terms of time and cost. • Finalise the proposal and submit it to the client. • Get approval for the proposal from the client. • Publish and distribute the revised schedule with a revision number to the counterparts and stakeholders. Dos and don’ts for revising the schedule:

• Do not delete any activities to be erased in Primavera P6; instead, delete all relationships of an activity to be deleted and make its duration zero (0) in order to prevent reusing erased activities’ numbers.

• Review resource constraints (Max units/time) again since resource allocation is also affected by delayed activities. Over-allocation can cause further delay.

Reporting