When Fast Tracking a project to make up for lost time; which is better, (all other things being equal):
to move an activity (H) to a New position on the Network diagram so as to increase divergence at the new Predecessor activity (F)
or
to move an activity (H) to a New position on the Network diagram so as to increase convergence at the new Successor activity (L).
In both cases, often, the divergence and convergence increase for each situation. However, which is better, ‘3 Divergence and 2 Convergence’ OR ‘3 Convergence and 2 Divergence’.
Assuming a Discretionary dependencies, Project Starts with Activity F; Activities G and B preceded by F; Activity H preceded by G, Activity C preceded by H, Activity L preceded by C and B; project ends after Activity is L completed.
The need for compressing a schedule calls on various techniques, such as fast-tracing and crashing. Bypassing your example of Activity H because the caffeine just hasn't hit yet, naturally the approach when fast-tracking to reduce the risk as much as possible while compressing the schedule, and for crashing it is reducing the cost as much as possible while compressing the schedule. So when you play ABC with the network diagram, keep these in mind and you should be fine.
A network diagram is drawn based on dependencies, so most of the time, I like to use crashing to make up for lost time.
Fast tracking is seldom used when an activity's preconditions are basically ready for it to run.
...
1 reply by OPEOLUWA AJAYI
Mar 21, 2018 1:37 PM
OPEOLUWA AJAYI
...
ok
Saving Changes...
Christian Sanabria JiménezMBA, MSc, PMP, IT Professional / Scrum Master / ITIL / Web Application Developer| Costa Rica Institute of TechnologyCartago, Cartago, Costa Rica
It depends on the availability of resources and the relationship among the tasks you move. It can make impossible to move the tasks. There is no recipe for crashing/fast tracking, because one task may have requirements from its predecessors or may have outputs required by it's succesors...
You can't have a "one size fits all" answer to your question as I see it.
The need for compressing a schedule calls on various techniques, such as fast-tracing and crashing. Bypassing your example of Activity H because the caffeine just hasn't hit yet, naturally the approach when fast-tracking to reduce the risk as much as possible while compressing the schedule, and for crashing it is reducing the cost as much as possible while compressing the schedule. So when you play ABC with the network diagram, keep these in mind and you should be fine.
It depends on the availability of resources and the relationship among the tasks you move. It can make impossible to move the tasks. There is no recipe for crashing/fast tracking, because one task may have requirements from its predecessors or may have outputs required by it's succesors...
You can't have a "one size fits all" answer to your question as I see it.
A network diagram is drawn based on dependencies, so most of the time, I like to use crashing to make up for lost time.
Fast tracking is seldom used when an activity's preconditions are basically ready for it to run.
