sábado, 19 de enero de 2013

NEW COMPRESSION SCHEDULE TECHNIQUE: BREAKING


The most used Schedule compression techniques are Crashing and Fast track, which are very effective in order to reduce activities time and shorten Project duration. This Paper consider a new technique called “Breaking” which makes up an additional way for compressing schedules.

Introduction


-          Crashing.- This technique reduces duration of critical path by allocating more resources to involved activities, see Sketch 01.


Sketch 01: Crashing

-          Fast track.- This technique reduces duration of critical path by overlaping (either total or partially) involved activities which were planned one next to another, see Sketch 02.


Sketch 02: Fast track

Breaking

This new method for Schedule compression proposses to shorten Project duration by either eliminating or modifying relations among activities on critical path. It is compounded by three stages:

-          Dependency determination

-          Dependencies and overcosts analysis

-          Displaying options

Dependency determinación

First step is to group dependencies among activities according to PMI’s reccomendations, it means:

-          Mandatory dependencies.- They are relations that can not be changed. For instance Formwork -> Concrete Pouring is a mandatory dependency because isn’t possible concrete pouring without fixing formwork before.

-          Discretionary dependencies.- They are relations that can be changed but were chosen from a group of alternatives because represented the cheapest path to complete the Project.

Dependencies and overcosts analysis

The next step is to find the Project critical path.

We will use Turbine – Generator Erection Project as example to clarify each step. This Project will last 425 days, the deadline is on June 20th 2014 and the red activities form the critical path, according to Chart 01.


Chart 01: Project critical path

 
Then it is required to sort dependencies in two groups: mandatory dependencies and discretionary dependencies as explained before.
Filtering critical path activities would be very advisable, see Chart 02, as well as to make a difference between both types of dependencies, for exambpe by painting green all the mandatory dependencies and, in contrast, painting orange all discretionary dependencies.

Chart 02: Sorting dependencies

Then it is possible to address each discretionary dependency (orange colored) looking for either eliminate them (first option) or modify them (second option) until there is no discretionary dependency on critical path or, at least, we have optimized those left in order to shorten Project duration.
On the example, successors of activity ID14: Bridge Crane Installation belong the same construction process: first we install Bridge Crane and next we use it to install Draft Tube (successor ID15), Spiral Case (successor ID16), Turbine (successor ID17) and Generator (ID18). It is supposed this installation was chosen for being the least expensive option, because you can take the chance of using a Project Bridge Crane to lift and install other components. Neverthless we can eliminate this dependency if considering to hire a Crane which help us to install these other components, at least before Project Bridge Crane is finished up and working. There would be US$ 1 500 000.00 as additional costs for hiring this Crane.
If this decision is made, Decision 1, Draft Tube, Spiral Case, Turbine and Generator wouldn’t depend on Bridge Crane, so we could eliminate these dependencies from ID14: Bridge Crane Installation successors activities, as shown in Chart 03.

Chart 03: Eliminating ID14: Bridge Crane Installation successors

In Chart 03 there is a new critical path, 18th April 2014 is new deadline and 380 days is new Project duration, which means this decision would shorten Project schedule in 45 days (425 - 380 = 45 days)
Now the process is repeated again on the new critical path.
 
As above, critical path activities are filtered and painted green (mandatory dependencies) and orange (discretionary dependencies) as shown in Chart 04.

Chart 04: New critical path



There is only one discretionary dependency (orange color) we can address to, it is located in successor activities of ID17: Turbine Erection and corresponds to the usual installation process that considers first placing Turbine into the pit and after that installing Generator which is located above. Precasting the Generator and placing Turbine can be made at the same time, so once Turbine is finished, Generator could be just lifted en connected in its final location. This decision involves U$ 200 000.00 as additional costs for moving more people and equipment to site, in order to work in parallel both activities.
If this decision is made, Decision 2, we can turn the link involved into a start-start dependency now because Turbine and Generator would be parallel activities, as shown in Chart 05.

Chart 05: Eliminating ID17: Turbine Erection successor

As well in Chart 05 it is shown a new critical path, 13th December 2013 as new deadline and 290 days as new Project duration, which means this decision would shorten Project schedule in 90 more days (380 – 290 = 90 days), keeping in mind 380 days as current duration.
Again the process is repeated on the new critical path.

As above, critical path activities are filtered and painted green (mandatory dependencies) and blue (optimized discretionary dependencies) as shown in Chart 06.

Chart 06: New critical path

On new critical path, there is only mandatory dependencies (green dependencies) or optimized discretionary dependencies (blue dependencies), and there is no simple discretionary dependencies (orange dependencies), so it is not possible shorten project duration any longer, Breaking process has finished.
Displaying options
It is very useful to elaborate a decisions tree for displaying options.
Number of branches in decisions tree depends on how many decisions are possible, according the next formula:
Number of branches = 2n
Where:
n = Number of decisions we can make
For better understanding see Graphic 01.
Graphic 01: Decisions tree

In our example, there are 2 possible decisions, therefore:
            Number of branches = 2n = 22 = 4
Taking apart each decision:
-          Decision 1
Additional costs by Decision 1 = $ 1 500 000.00 (see above-mentioned)
Cut days by Decision 1 = 45 days (see above-mentioned)
Project Duration by making only Decision 1 = Project duration - Cut days by Decision 1 = 425 – 45 = 380 days
-          Decision 2
Additional costs by Decision 2 = $ 200 000.00 (see above mentioned)
Cut days by Decision 2 = 90 days (see above mentioned)
Project Duration by making only Decision 2 = Project duration - Cut days by Decision 2 = 425 – 90 = 335 days
Combined effect:
-          Decision 1 + Decision 2
Additional costs by Decision 1 + Decision 2 = Additional costs by Decision 1 + Additional costs by Decision 2 = 1 500 000.00 + 200 000.00 = $ 1 700 000.00
Cut days by Decision 1 + Decision 2 = Cut days by Decision 1 + Cut days by Decision 2 = 45 + 90 = 135 days (check this, it is not always arithmetic addition, but it happens that way in our example)
Project Duration by making Decision 1 + Decision 2 = Project duration - Cut days by Decision 1 + Decision 2 = 425 – 135 = 290 days
Finally our decision tree would be like Graphic 02:
Graphic 02: Displaying options in decisions tree

Conclusions
 
-        If “Crashing” is not applicable because physical limitations, as usual in construction business, and “Fast track” turns into a very risky alternative keeping in mind quality and other features affected by; we can use “Breaking” in order to shorten Project duration.
-        While “Crashing” deals with resources and “Fast track” deals with leads and lags; “Breaking” is looking for eliminating or modifying construction processes, which means “Breaking” deals with innovation and could give us important advantages over competence. (In following posts I will show you how Chinese builders applied “Breaking” on traditional build construction process to get “30 story building in 15 days”.)
Reccomendations
 
-        Comparing additional costs related to Breaking with economic benefits by finishing before deadline, would complete the analysis and help us to make best decisions.
-        Applying Breaking does not exclude neither Crashing nor Fast track, so these techniques could be perfectly combined.
-        Breaking would be easier if Planning softwares (MS Project, Primavera, etc.) have an option to sort dependencies: mandatory dependencies (green in our example), non optimized discretionary dependencies (orange in our example) and optimized discretionary dependencies (blue in our example), so far they don’t have one.