Tagged: summary tasks
If Task A can’t start until Summary Task B is complete, why not create that dependancy? I keep reading that it is best practice, but I have not heard a good answer as to why. I think it’s a more simple way to represent your schedule.
If you are trying to maintain a critical path, linking to summary tasks can be a mistake. The logic can be confusing enough that you will create circular references because of it. Tasks underneath the summary task will appear to be abandoned in certain views because they don’t have successors. If tasks get added under the summary task or tasks get extended under the summary task and you aren’t re-checking the tasks linked to the summary task with each change, you can inadvertently extend your schedule and cause yourself more work trying to figure out the linkage error. In fact, to maintain a really good networked schedule, I maintain a guideline that all tasks should have a predecessor and successor with the exception of the start and finish task of the project (of course, I do occasionally have external dependencies with hard coded dates). If you are doing this, you will have a very accurate critical path and you will not need to link to summary tasks.
At the planning phase of the project, I consider each task individually and figure out what the entry criteria is to starting that task. Maybe it is a group of tasks…and even if it is, I will add each one as an individual dependency. You will thank yourself in execution of the project if dependencies change.
Can also create circular references. Avod!