Logic on Summary Tasks

[hammondrob1]

Hi all. Recently I had a discussion with a project manager who was
adamant that applying logic to summary tasks was acceptable and
allowed him to build his schedule from the top down. I raised the
fact that there was an implicit assumption that all tasks contained
under the first summary bar must be completed before any task under
the susbsequent summary bar could commence (ie highly sequential work
when the real world often allows work to be done in parallel). He did
counter that with the status overiding logic option switched on he
could remove the pessimistic forecast that might otherwise be produced
from sequential rather than parallel tasks. I was a loss to explain
any other good reason for not applying logic to summary tasks apart
from being 'good practice'.

Has anyone got any suggestions why logic on summary tasks is not
encouraged? (Using MSp2003 SP3 standalone in master child
structure). Thanks

 

[davegb]

Hi all. Recently I had a discussion with a project manager who was
adamant that applying logic to summary tasks was acceptable and
allowed him to build his schedule from the top down. I raised the
fact that there was an implicit assumption that all tasks contained
under the first summary bar must be completed before any task under
the susbsequent summary bar could commence (ie highly sequential work
when the real world often allows work to be done in parallel). He did
counter that with the status overiding logic option switched on he
could remove the pessimistic forecast that might otherwise be produced
from sequential rather than parallel tasks. I was a loss to explain
any other good reason for not applying logic to summary tasks apart
from being 'good practice'.

Has anyone got any suggestions why logic on summary tasks is not
encouraged? (Using MSp2003 SP3 standalone in master child
structure). Thanks

Let's start by defining our terms. What does "applying Logic to
Summary tasks" mean?

 

[John]

Hi all. Recently I had a discussion with a project manager who was
adamant that applying logic to summary tasks was acceptable and
allowed him to build his schedule from the top down. I raised the
fact that there was an implicit assumption that all tasks contained
under the first summary bar must be completed before any task under
the susbsequent summary bar could commence (ie highly sequential work
when the real world often allows work to be done in parallel). He did
counter that with the status overiding logic option switched on he
could remove the pessimistic forecast that might otherwise be produced
from sequential rather than parallel tasks. I was a loss to explain
any other good reason for not applying logic to summary tasks apart
from being 'good practice'.

Has anyone got any suggestions why logic on summary tasks is not
encouraged? (Using MSp2003 SP3 standalone in master child
structure). Thanks

hammondrob1,
I've got a question for your boss. What is the, "status overriding logic
option"?

Go to our MVP website at, http://www.mvps.org/project/faqs.htm, and take
a look at FAQ 49 - Summary task linking. Read it and share it with your
boss.

John
Project MVP

 

[Steve House]

I'm guessing he's talking about precedence links into or out of summaries.
While I generally agree that best practice usually dictates that links only
flow between activities and not invlolve summaries, I can see that
exceptions might occur. Let's say you have a Design Phase, a Testing Phase,
followed by an Acceptance milestone, followed by a Production phase. In
your particular business model, testing MUST be complete before the
acceptance can occur and acceptance must occur becfore any aspect of
production can be commited. In that case having a link sequence of
Testing->Acceptance->Production linking those summaries through the
milestone doesn't seem unreasonable to me.