As you describe it now, there's no conceptual problems I see. What I was
thinking when I wrote that was the you might have been doing what I've seen
some people do where, for example, they are using summary tasks to group
together work done by individual departments or perhaps to group the work
into time blocks rather than using summaries properly to group together all
the component tasks that lead to the creation of a signifigant deliverable.
In that situation, it sometimes happens that the summary task represents all
the work done by, say, the engineering department or during the second
quarter of the year but only some of that work is detailed as specific
subtasks and so they want the duration of the summary to be something other
than what Project computes it to be. But those aren't proper applications
of a WBS and so the answer to the problem is not to change the way Project
computes but rather to change their thinking about how a project's task list
should be organized. When properly done the task list represents the
decomposition of the work creating the final project deliverable into that
creating prgressively smaller and smaller component "modules" until you get
to the level of describing the work done to create one single discrete
granular component and performed by one skill set. If your project creates
a widget, the widget is an assembly of 10 different components A to J, and
each component requires 3 steps, each done by a different worker with his
own unique skills, the WBS would be one summary for the widget with 10
sub-summaries for the components and each of them in turn would have 3
subtasks.
If task 20 isn't part of the group of tasks that build whatever the
deliverable at the end of yor workpackage is then there's no problem to move
it outside the group. But if it's legitimately a component part of the work
package by the physical nature of the process, then I'd leave it a subtask
of the summary and bite the bullet to set up the 19 separate FS links from
those predecessor tasks. Are all 19 of those tasks really not linked to
each other, otherwise able to happen simultaneously if you had enough
resources to do it? Another option would be to create a "sub-summary task"
that groups your 19 together so it would look like this ...
1: Big Summary
1.1 Sub-summary
1.1.01
to
1.1.19 for 19 detail tasks
1.2 20th task
2: Next module
and sub-summary 1.1 links to activity 1.2 FS
--
Steve House [MVP]
MS Project Trainer & Consultant
Visit
http://www.mvps.org/project/faqs.htm for the FAQs
Dave Eade said:
Steve,
I understand the concept of 'summary tasks'.
The problem I was trying to get around was that for a work package I have
20
tasks, task number 20 should start on the latest date that tasks 1-19
finish.
I could have a dependency of F>S for all 19 to number 20, but that seemed
to
be a lot of work, so I thought I could use the dependency on the summary
task.
I guess my other solution would be to have task 20 not in the Workpackage
that 1-19 were in but that isn't how the project is set up.
If you can tell me where my "fundmental conceptual problems" are I'd be
grateful.
--
Dave Eade
Global Project Solutions
