Mike is completely right -- the simplest way to pull in your schedule is by increasing work hours on your critical path ("crashing the critical path"). A second way is by scheduling critical path activities to be performed in parallel ("fast tracking", or as Kashif Khan said, altering the logic), but that is often more complex and can increase risk.
Unfortunately, not all critical path tasks offer equal "bang for the buck": you can have a CP task with a duration of 30 days that you think is nice and juicy for compression -- but when you triple the resources and reduce it to about ten days, the end of the project is only pulled in by one day. Conversely, you could have a CP task of 15 days which if you reduce it to eight days will pull in the end of the project by seven times as much!
The issue is to compute and address each activity's critical path drag: the amount of time it is adding to the project duration. As you compress the longest path, the critical path will migrate elsewhere and you will get new CP activities with new drag amounts. As Mike says, keep changing how you are planning to do the project and see what the impact of each change is on the project duration. After a bit of practice with drag, you will be able to see what the impact of any change would be without even actually making it. For a recent article on critical path drag, check out "The Drag Efficient: The Missing Quantification of Time on the Critical Path" in the Jan/Feb issue of Defense AT&L Magazine.
Finally, what software are you using? The only two software packages that compute drag are Spider Project (you can ask about it right in the Spider Project forum on this site) and the Sumatra Project Optimizer, an add-on to MS Project. I believe you can still download a free trial copy that works at the linked Sumatra website.
Just adjusting the programme will not recover the delay - only changes that you make to the way you are working on site will do that.
The changes to your programme must then reflect the decisions that have been made by the management team.
But before you do anything check that the actual progress on your revised programme shows any delay.
The simplest method to recover lost time is to increase the work hours on the CRITICAL items so if that is the decided way forward then that is how you adjust your programme.
Member for
13 years 11 months.
.
Member for
15 yearsHi Steve, Thanks for your
Hi Steve,
Thanks for your reply..
Regards.
Sunil
Member for
15 yearsHi Mike, Thanks for your
Hi Mike,
Thanks for your reply..
Regards
Sunil.
Member for
20 years 7 monthsHi, Sunil.Mike is completely
Hi, Sunil.
Mike is completely right -- the simplest way to pull in your schedule is by increasing work hours on your critical path ("crashing the critical path"). A second way is by scheduling critical path activities to be performed in parallel ("fast tracking", or as Kashif Khan said, altering the logic), but that is often more complex and can increase risk.
Unfortunately, not all critical path tasks offer equal "bang for the buck": you can have a CP task with a duration of 30 days that you think is nice and juicy for compression -- but when you triple the resources and reduce it to about ten days, the end of the project is only pulled in by one day. Conversely, you could have a CP task of 15 days which if you reduce it to eight days will pull in the end of the project by seven times as much!
The issue is to compute and address each activity's critical path drag: the amount of time it is adding to the project duration. As you compress the longest path, the critical path will migrate elsewhere and you will get new CP activities with new drag amounts. As Mike says, keep changing how you are planning to do the project and see what the impact of each change is on the project duration. After a bit of practice with drag, you will be able to see what the impact of any change would be without even actually making it. For a recent article on critical path drag, check out "The Drag Efficient: The Missing Quantification of Time on the Critical Path" in the Jan/Feb issue of Defense AT&L Magazine.
Finally, what software are you using? The only two software packages that compute drag are Spider Project (you can ask about it right in the Spider Project forum on this site) and the Sumatra Project Optimizer, an add-on to MS Project. I believe you can still download a free trial copy that works at the linked Sumatra website.
Good luck.
Fraternally in project management,
Steve the Bajan
Member for
19 years 10 monthsHi Sunil Just adjusting the
Hi Sunil
Just adjusting the programme will not recover the delay - only changes that you make to the way you are working on site will do that.
The changes to your programme must then reflect the decisions that have been made by the management team.
But before you do anything check that the actual progress on your revised programme shows any delay.
The simplest method to recover lost time is to increase the work hours on the CRITICAL items so if that is the decided way forward then that is how you adjust your programme.
Best regards
Mike Testro