1 task to be used in multiple activites

[Anna]

Completely daft question I'm afraid, but how can I get 1 task to be reported under multiple activities - similar to importing a project or task from another project.

I need to be able to have a task "eg code form 2330, resource Fred, 10 day duration" as part of 3 different work packages, but the task is only done once, but I need to be able to view it's progress as part of each package.

 

[John]

Anna,
First, put the common task in its own separate work package (i.e. not
associated with any of the other three).

There are probably several ways to "view" the common task's progress
with each package. Once simple way is to use a spare number field (e.g.
Number1) to set up a code sequence and then filter on that code
sequence. For example, code the common task as "1". Code all task lines
of the first workpackage as "2". Code the second as "3" and so forth.
Then set a filter to look for codes "1" & "2" or "1" & "3", etc. You can
even make an interactive filter to allow the user to enter the second
code value.

Hope this helps.
John

 

[Steve House]

Alarm bells going off here - are you saying the Fred codes ONE "form 2330"
and that one coded form is then used in three different work packages or are
you saying the there are 3 different work packages that need a "form 2330"
and Fred codes a fresh one for each package? If it's the former I'd suggest
making "code form 2330" a single task that is a predecessor to each of the
three packages that use it ( a task may have more than one task directly
dependent on it). If it's the latter, it's not one task but three separate
tasks done at different times and should be included as a subtask in each of
the packages where it's produced/used.

I say alarm bells are going off because it sort of sounds like you may be
organizing your tasks into some sort of administrative category reporting
structure outline rather than as a true WBS that describes and schedules the
actual workflow through the project. Very often that strategy presents
severe problems at some point and if that's the case you might want to
rethink it while it's still relatively easy to switch directions. There's
an excellent guide to network analysis on the MVP web site that could be big
help and might be worth your while to review.


--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Completely daft question I'm afraid, but how can I get 1 task to be

reported under multiple activities - similar to importing a project or task
from another project.

I need to be able to have a task "eg code form 2330, resource Fred, 10 day

duration" as part of 3 different work packages, but the task is only done
once, but I need to be able to view it's progress as part of each package.

 

[Steve House]

Sounds like you need to anonymously slip him some materials on project
planning methodologies <grin>. I'm not an expert on use case methods by any
means but to my understanding it is an approach to analyzing what needs to
be done so as to detail the required functionality. The result is a
detailed description of the what the final project deliverable output is
supposed to do, a product specification document. But it doesn't detail
all the individual steps that are required to produce the deliverable that
does what the use case study says is required. In my classes I try to make
clear the distinction between *product* specifications and *project*
specifications. The product specification details where we want to go and
use case studies are a very good way of determining that. The project
specification details what we need to do step by step in order to get there
and its output is a schedule that tells Joe that he needs to be at X on
Friday at 10am with the tools required to do Y for 3 hours.

--
Steve House [MVP]
MS Project Trainer/Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs

Thank you both for your help.

Steve, my Delivery Manager is trialling planning by "use case", part of

the RUP iterative software development methodology. Which are not
workpackages in the true sense of the word, due to 1 task could affect
multiple use cases. Apparently this task could take place at any time in
the development of each usecase, and he doesn't want to create separate
tasks for each as these "would not show the true status of this task".
These could also run across multiple project plans, (we create a separate
plan for each iteration). It is his cunning idea that 1 task could be part
of multiple use cases, and therefore could you insert/link this 1 task in
multiple cases. I think he is trying to replicate a "sub project" but only
using a task.

Please accept my apologies for my explanation, but I am trying very hard

to understand what he wants myself.