Reduce duration

[BGNS]

Hi,
I'm new to this field and still study PM. So can you tell me how to reduce the project duration by 4 weeks (5 option).

These are my task and duration(weeks),Crash time(weeks) and Predecessor

1. Planning- Duration 2 weeks- Crash time 1 week -Predecessor None
2. Requirement Study - Duration 3 weeks- Crash time 2 weeks -Predecessor 1
3. Feaibility Study - Duration 2 weeks- Crash time 1 week - Predecessor 1
4. Risk Analysis - Duration 4 weeks- Crash time 2 weeks- Predecessor 1
5. Design & Development - Duration 5 weeks- Crash time 2 weeks- Predecessor 2,3
6. Testing- Duration 2 weeks- Crash time 1 week -Predecessor 4
7. Implementation - Duration 3 weeks- Crash time 1 week- Predecessor 4
8. Review of System - Duration 3 weeks- Crash time 2 weeks- Predecessor5,6,7
9. Sign off- Duration 2 weeks- Crash time 1 week- Predecessor 8

thank

[davilara]

Criteria for Selecting Activities to Crash:

There are several characteristics that mark or highlight an activity that exists on the Critical Path as a better candidate for crashing.
1. Must be on the Critical Path. Crashing noncritical activities that already have slack only buys more slack and doesn’t shorten the project duration. Only critical path activities drive the project and crashing them will shorten the project duration.
2. Precedes multiple activities. When an activity bottlenecks numerous succeeding activities, it is a great candidate to shorten. Once this activity is shortened, it allows the multiple activities to begin.
3. Long duration. An activity that has a long duration offers more potential time gain from crashing it.
4. Lower cost per period gained. Activities that cost less to crash are preferred. These include those requiring lower paid, lower skilled workers or other resources that are otherwise sitting idle.
5. Early in the project (the Sunshine Rule). If you fail in crashing the activity and it takes longer than planned, it is still early in the project. Thus you still have recovery time. Also, typically demand on resources early in the project is lower than other times, and they should be readily available.
6. Labor-intensive. When an activity is low skill labor intensive, it is easy to add people to help complete the project early. When an activity requires high skills to complete, it may be hard to find qualified individuals who are capable of completing the task.
7. Subject to common problems. Try to pick activities that are subject to higher probability of common problems. Shortening the duration lowers the exposure time and lessens the chances of having a problem.

Steps in Project Crashing:

1. Compute the crash cost per time period. If crash costs are linear over time:
Crash cost per period = (Crash cost – Normal cost) / (Normal time – Crash time)
2. Using current activity times find the critical path and identify the critical activities
3. If there is only one critical path, then select the activity on this critical path that (a) can still be crashed, and (b) has the smallest crash cost per period. If there is more than one critical path, then select one activity from each critical path such that
(a) Each selected activity can still be crashed, and
(b) The total crash cost of all selected activities is the smallest. Note that a single activity may be common to more than one critical path.
4. Update all activity times.
5. Cease crashing when
– The target completion time is reached
– The crash cost exceeds the penalty cost
If not, return to Step 2.

If optimum crashing results in crashing late activities you can factor late activities cost to crash as to artificially increase the crash cost and use this factored value on the above procedure as to obtain alternate crashing strategy. Then compare true costs to determine if higher cost of early crashing is justified.

Just remember you do not necesarily can crash an activity before other activities become critical, DRAG is a metrics that can be of help, is not the answer to all issues, but very good to know and understand. The software I use can compute DRAG but not under resource leveling. Crashing a schedule under resource leveling is exponentially complicated, even the calculation of float is missed by most software under resource constraining. Fortunately my software choice is among the very few that can correctly determine resource critical float.

DRAG: It is a simple concept: how much can we shorten this critical path activity before some other path becomes the critical
path?

[url]http://www.asapm.org/asapmag/articles/DRAG.pdf[/url]

Do not rule out other techniques that can yield better results. At times (shall I say usually?) a change in logic, a change in available calendar days, additional crews, subcontracting a portion of work and many others can provide a better solution than the traditional "Time-Cost Trade-off" algorithms.