In my world crashing and change of logic usually are last resort options.  

At times we add shifts and whole crews that will work at similar productivity.  Usually we start by adding a shift during weekends, we add crews to work during the added shifts avoiding overtime, this also results in more efficient use of rented equipment, so there is a saving.  This does not require a change in logic and there is no crashing involved. 

At times it is enough to add some crews without need to use additional shifts, activities duration remains the same, just that the number of activities in parallel are increased.  We do not use "soft logic" so for us this is not a change in logic just an increase in available resources and available work time within same calendar duration. Of course at some point the above cannot shorten anymore the schedule and then other options must come into play.

Crashing might be a change in crew composition like using more productive equipment though more expensive, also might mean change of materials like using fast setting concrete to allow for early stripping. 

If you used soft logic to force resource leveling or adhered to unnecessary FS logic only that prevented overlapping change in logic can be of value because poor and inefficient plans in which logic can be changed as if underwear have room to improve. In most jobs there is some preferential logic here is where most changes in logic can be done. 

The alternatives might be endless.

The key is to brainstorm the ideas with the people who will do the actual implementation, brainstorming will get them on board to commit to the revised plan. Do not rule out possible alternatives because at first sight you believe they will not make it, at times these comes out as the only possible alternative or provide the inspiration for other ideas. Do not even rule out last resort options such as crashing and change of logic.

Good Luck

take the current schedule and start from there this means that you already have actual start and finish of the latest updated schedule. 

The 1st thing that you have to do is to determine who caused the originial schedule to slip or who forced the need for a recovey schedule. Questions that you need to ask is who is responsible for the slippage, who is going to pay for the recovery, how much time do you need to recover.

you have two options you can either fast track the schedule or you can crash the schedule

1. Fast Tracking the schedule means to Revise the logic and do thing concurrently or in parallel which means that your manpower peak will be higher but it will be the same number of man-hours except for additional supervision.
A good rule of thumb is that sequential activities can sometimes be fast-tracked by up to 33%. In other words, if you’re fast-tracking, you can start the second of two sequential activities when the first activity is 66% complete. So when you are 66% complete with the first conduit activity you can start the wire pulling activity.


2. Crashing the schedule means to reduce your durations but you will have to increase your man-hours because you need more men to do it in a shorter amount of time. You would shorten the duration of the activities on the critical path by throwing additional resources to the critical path without necessarily getting the highest level of efficiency. You might have to do several iterations because you crash one critical path then something else becomes critical. You will have increased cost with this option 

Also include a narrative

Hi, Anwar.

The most important information in order to recover a slipped schedule is the drag of each critical path activity based on remaining durations. You should target the CP activities in descending order of the most drag, through increasing resources, doing more work in parallel, or reducing scope.  When the critical path changes, the activities and their drags will change. Repeat the process over and over again, targeting the new high drag activities every time the CP changes until you have an acceptable schedule.

This is all very easy to do in Spider Project. Unfortunately, Primavera does not have the functionality to compute critical path drag. Therefore your best bet is either to get a copy of Spider or to print out the network diagrams from Primavera and do the computations each time "manually".

Here are some sites/articles/exercises that might help:

http://www.dau.mil/pubscats/ATL%20Docs/Jan_Feb_2012/Devaux.pdf

http://en.wikipedia.org/wiki/Critical_path_drag

http://www.totalprojectcontrol.com/exercise.html

I hope this helps. If it does, send an email to Primavera telling them that they need to start including this basic and crucial CPM functionality.

Fraternally in project management,

Steve the Bajan