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.