Tagged: Hammock or constraints?
I have a schedule with that has tasks driven by when we can access a facility. That date is unknown. So I created a milestone to drive out the start of certain tasks. On tasks that are in work but being held up by access, I created a FF to the milestone with additional lag to push out the end date for the needed work to complete. Works fine going forward, however, if I move the milestone back and forth to see the what-if scenario, once I move it out the durations expand, but don’t reduce if the milestone is pulled back.
I thought about using a hammock for the end dates only on the in-work tasks. But once again the duration doesn’t change when reducing. I’ve gone from fixed duration to fixed work and that helps on some tasks, but not all, especially ones that had just begun but now on hold.
Hi Paul. You have a lot going on with your question so I’m not sure how to answer with confidence, but I’ll give you some thoughts. It is standard behavior that once a task starts, the start date and % complete is locked. Actual work doesn’t move). When you update a task, make sure you set the Actual Start date first, then set % Complete or however you are updating actual work. My assumption is that you aren’t trying to move the part of tasks that are already started/completed. Changing predecessors after that will only change the remaining work. I also prefer using Fixed Work or Fixed Units as a default task type than Fixed Duration.
Hope that helps…
Thanks Larry it does. Where I work we have technicians that were working in a facility that is now on stand down. Once given the go ahead, work will resume. But that is unknown unknown at this time. So do what-ifs, looking how to move the remaining duration effectively on all tasks based on a resume date.