Task Dependences Between Summary Task

[Ashok]

Microsoft Project Application, does pop the message saying "the predecessors
of a summary task or predecessors of an inserted project summary task must
have a finish-to-start or start-to-start dependency" while defining task
dependencies (type = start-to-finish or finish-to-finish) between two summary
task.

Can anyone explain me the functional reasoning (with an example) as to why
such a restriction is present.

 

[davegb]

Microsoft Project Application, does pop the message saying "the predecessors
of a summary task or predecessors of an inserted project summary task must
have a finish-to-start or start-to-start dependency" while defining task
dependencies (type = start-to-finish or finish-to-finish) between two summary
task.

Can anyone explain me the functional reasoning (with an example) as to why
such a restriction is present.

I'm not sure why MS put in that restriction. It's a moot point to me,
since I, and most of the other advisors here NEVER link summary tasks.
It will always come around to haunt you later on. Of course, since the
software will allow it, it's up to you.

 

[JackD]

I'm not sure why MS put in that restriction. It's a moot point to me,
since I, and most of the other advisors here NEVER link summary tasks.
It will always come around to haunt you later on. Of course, since the
software will allow it, it's up to you.

That should read "almost never", but you know that.

-Jack

 

[davegb]

That should read "almost never", but you know that.

-Jack

Years ago, when I first learned how to schedule with software, I was
taught "NEVER". When I started consulting, and heard objections, I
softened for a while, and said "almost never". I had to learn it for
myself. When I say "NEVER", I mean "NEVER"! Meaning, under no
circumstances, for no reason, should anyone, ever link Summary tasks in
any scheduling software, no exceptions under any real or imagined
circumstances. Emphasis on "NEVER". If you want to think up exceptions,
I'll be happy to show you how to achieve the same end result without
the complications.

 

[JackD]

Years ago, when I first learned how to schedule with software, I was
taught "NEVER". When I started consulting, and heard objections, I
softened for a while, and said "almost never". I had to learn it for
myself. When I say "NEVER", I mean "NEVER"! Meaning, under no
circumstances, for no reason, should anyone, ever link Summary tasks in
any scheduling software, no exceptions under any real or imagined
circumstances. Emphasis on "NEVER". If you want to think up exceptions,
I'll be happy to show you how to achieve the same end result without
the complications.

Oh, I know how to achieve the same end result, but here is an example:

You have a project schedule with well-defined sequential phases. There are
also some parallel activities grouped into phases.
Each phase is modelled as a summary task with a number of sub-tasks (and
perhaps even sub-summary tasks)
The sub-tasks are modelled correctly and have dependencies from the last
sub-task in a phase to the first sub-task in the next phase. It may even
have such things as a start and finish milestone for each phase.

Now...

Your bosses, bosses, boss wants to see how the project is going. You
collapse the summary tasks. In doing so the dependency lines DISAPPEAR FROM
VIEW and there is no clear relationship between phases. Instead of just
giving up and doing the whole thing in powerpoint, you succumb to temptation
and violate the sacred commandment of DaveGB and throw a few dependencies in
to make the workflow understandable. Why not? You are only going to remove
them later.

I do this more frequently then I'd like to admit.
I also use this approach when sketching out a schedule.

Schedules have multiple uses and have a lifecycle. At first they are used in
an exploratory fashion, then they become a bit analytical, after that they
become operational and serve to track actual progress, finally at the end
they should be archived. All along, they also serve as a communication tool.
Linking summary tasks is a problem in the operational mode but is less so in
some of the other modes.

-Jack

 

[davegb]

Oh, I know how to achieve the same end result, but here is an example:

You have a project schedule with well-defined sequential phases. There are
also some parallel activities grouped into phases.
Each phase is modelled as a summary task with a number of sub-tasks (and
perhaps even sub-summary tasks)
The sub-tasks are modelled correctly and have dependencies from the last
sub-task in a phase to the first sub-task in the next phase. It may even
have such things as a start and finish milestone for each phase.

Now...

Your bosses, bosses, boss wants to see how the project is going. You
collapse the summary tasks. In doing so the dependency lines DISAPPEAR FROM
VIEW and there is no clear relationship between phases. Instead of just
giving up and doing the whole thing in powerpoint, you succumb to temptation
and violate the sacred commandment of DaveGB and throw a few dependencies in
to make the workflow understandable. Why not? You are only going to remove
them later.

I do this more frequently then I'd like to admit.
I also use this approach when sketching out a schedule.

Schedules have multiple uses and have a lifecycle. At first they are used in
an exploratory fashion, then they become a bit analytical, after that they
become operational and serve to track actual progress, finally at the end
they should be archived. All along, they also serve as a communication tool.
Linking summary tasks is a problem in the operational mode but is less so in
some of the other modes.

-Jack

Jack,
I stand corrected. I was thinking about scheduling. You're talking
about
fooling-an-ignorant-manager-so-he-sees-what-he-thinks-he-should-see-in-a-simulated-schedule-when-he-knows-nothing-about-scheduling.
An entirely different application!

 

[JackD]

Jack,
I stand corrected. I was thinking about scheduling. You're talking
about
fooling-an-ignorant-manager-so-he-sees-what-he-thinks-he-should-see-in-a-sim
ulated-schedule-when-he-knows-nothing-about-scheduling.
An entirely different application!

Project has many uses!

-Jack

 

[Jan De Messemaeker]

Hi guys,

Just one for a good laugh.
I just went through "2003 Step by Step" edited by Microsoft.
It RECOMMENDS linking summaries "it is much clearer"
But it also recommends intensive use of %complete which is just as lmousy.
Greetings,

 

[davegb]

Hi guys,

Just one for a good laugh.
I just went through "2003 Step by Step" edited by Microsoft.
It RECOMMENDS linking summaries "it is much clearer"
But it also recommends intensive use of %complete which is just as lmousy.
Greetings,

In all the years I've worked with Project, with all the MS people whom
I talked with about scheduling (including the head of the original
Project for Windows development team and quite a few others), I've
never met anyone yet who knew anything about scheduling. All of the
ones I've met still think you link tasks by clicking and dragging from
Task 1 to the last task and clicking on the link icon!