creating task dependencies at the summary task level

[anovak]

Is this a "no-no" or something that is advantageous? I've known of
some folks who have a habit of doing this, but they may not realize
that all subtasks will start at the same time in the successor
summary, right? I tend to shy away from this approach myself.

Please comment.

Thanks,
Andy

 

[Dale Howard [MVP]]

Andy --

On a practical level, setting dependencies on summary tasks can easily lead
to circular reference errors that are troublesome to troubleshoot and
resolve. On a theoretical level, summary tasks are not "real" tasks at all.
Instead, summary tasks are in a project only to give organization to the
project, such as deliniating phases and deliverables, for example. Either
reason, I think, is good enough to forbid setting dependencies on summary
tasks. Instead, we recommend setting dependencies only on regular tasks and
Mileston tasks. Hope this helps.

 

[Jack Dahlgren]

Comments inline:

Is this a "no-no" or something that is advantageous?

It can be advantageous, but it can also cause problems with circular
dependencies, etc. . I think it causes more problems though so I always
recommend against it.

I've known of
some folks who have a habit of doing this, but they may not realize
that all subtasks will start at the same time in the successor
summary, right?

No. The earliest one will generally start at the start of the summary task
and from that time the rest follow normal logical rules unless an earlier
task has an actual start earlier than the precessor of the summary task in
which case the summary task start is the start of the first task and the
first task without an actual start will be scheduled to start when the
summary predecessor is complete. It can be delayed in an almost invisible
fashion.

I tend to shy away from this approach myself.

Please comment.

Just say no.