We know that during planning/desgin phase of a project (project scheduling) CPM/PERT analysis is carried out. But in which phase of a project crashing of CPM/PERT analysis is carried out? Is it planning/design phase or execution phase?
To give a general answer: Crashing can take place any time after the critical path(s) is (are) identified regardless of the stage in the cycle!
This is usually a dynamic process that depends on both internal and external factors often times beyond the predictive ability of project managers!
Crashing is actually project time reducing. By increasing resources or eliminating some tasks, it can be done. So at the period of implementing this can be accomplished. Critical path will definitely change.
its a dynamic process depending on many factors so therefore it can happen at anytime depending on the circumistances/ influencers
Asking the question of what crashing or fast tracking is carried out is one thing, but more importantly is to ask why is it considered necessary to crash or fast track the schedule? If a project is in a mess then fast tracking or crashing will create a bigger mess (e.g., Brooke's law for software projects). So its is really only for well run projects that for some reason there is no spare budget that need to be finished faster - should fast tracking be considered. For projects that are needed to finish faster and for what ever reason given more or have unallocated funds then crashing can be done. In my experience, I have taken over late projects, and instead of adding people I have cut the team down by 60% and kept only the best people and completed them by even better people. When I teach, I run exercises and I have ALWAYS seen that a team of say 5 is faster than a team of 6, and this rule goes down to a team of 2 is faster than larger teams of 3, 4, 5 or 6 (I don't run classes with large teams). What I am trying to say is that applying a technique without understanding the background is very dangerous, especially when lives are at stake...
Can be done anytime you have a schedule that is detailed enough (resource loaded) to get you a reasonable solution for duration reduction. In my experience, you generally keep running scenarios to look for either opportunities or handle expected or actual disruptions. The mistakes that most planner make to crash with schedule that are too granular for getting to a good solution.
- Badges
- Science topic
- Similar topics
- Computer Communications (Networks)
- Simulators