Can tasks be shown more than one?

[Henrik]

Is it possible to show tasks more than once if they are relevant to more than
one workstream (group of tasks)? They should then ideally both (all) update
if updated in one place.

Thanks
Henrik

 

[JulieS]

Hello Henrik,

No, sorry. Each task listed is a separate task, the only
relationship they have would be through predecessors/successors.
You can insert a hyperlink to another task to make navigation
between the tasks easier.

I don't know what you are trying to accomplish, but on the surface,
it a task is "relevant" to move than one workstream, shouldn't it be
a predecessor to the multiple tasks?

I hope this helps. Let us know how you get along.

Julie
Project MVP

Visit http://project.mvps.org/ for the FAQs and additional
information about Microsoft Project

 

[Andrew Lavinsky]

I am not sure why you would want to do that, as this situation would be more
adequately handled by using multiple dependencies on one task.

That being said, if you absolutely need to synchronize multiple tasks, you
can do so by selecting the cell you want (let's say Duration of Task A),
copying it (Control C), and then pasting it as a link into the target cell
(Duration of Task B).

To paste as a link: Right click on the target cell, Paste Special, Paste
Link, Text Data.......

Now whenever you update the duration on A, B will change as well.

Note that this does use computer resources, and slow performance of the project
plan, so take that into account if you intend to do many of these cross-task
links.

-A

 

[Steve House]

It's not quite clear what you mean. A certain type of activity, like
painting a wall, can occur many times in a project and task names do not
have to be unique. But a "task" in a project plan is more than just a type
of activity, it's a specific action done at a certain time by a resource
that produces a specific deliverable. "Paint wall" can occur many times but
each time it does, it is a different wall getting painted. If what you are
asking about is one activity producing one deliverable but that deliverable
is a something used in more than one workstream, you would not represent it
as two occurances of the task but instead decide the workstream of which
it's primarily a member and list it there. All tasks should have at least
one predecessor and one successor so I'd place it within the group of tasks
that contain its predecessor. Then you'd model its participation in the
other workstream with a dependency link flowing from the task in question to
its successor in the second stream.

1. Produce Widget
1.1 Design Widget
1.2 Prototype Widget, 1.1FS
1.3 Approve Widget for Manufacture, 1.2FS
1.3 Make 100 Widgets, 1.3FS
2. Produce Widget Carrying Case
2.1 Design Case, 1.2FS
2.2 Make 100 Cases, 2.1FS

Notice that "Prototype Widget" is a predecessor to both "Approve for Mfgr"
in the first workstream and "Design Case" in the second because you can
neither start manufacturing nor design the carrying case until you've
approved the final design of the widgets.

 

[Henrik]

Thanks, all, I'll work on it

It's not quite clear what you mean. A certain type of activity, like
painting a wall, can occur many times in a project and task names do not
have to be unique. But a "task" in a project plan is more than just a type
of activity, it's a specific action done at a certain time by a resource
that produces a specific deliverable. "Paint wall" can occur many times but
each time it does, it is a different wall getting painted. If what you are
asking about is one activity producing one deliverable but that deliverable
is a something used in more than one workstream, you would not represent it
as two occurances of the task but instead decide the workstream of which
it's primarily a member and list it there. All tasks should have at least
one predecessor and one successor so I'd place it within the group of tasks
that contain its predecessor. Then you'd model its participation in the
other workstream with a dependency link flowing from the task in question to
its successor in the second stream.

1. Produce Widget
1.1 Design Widget
1.2 Prototype Widget, 1.1FS
1.3 Approve Widget for Manufacture, 1.2FS
1.3 Make 100 Widgets, 1.3FS
2. Produce Widget Carrying Case
2.1 Design Case, 1.2FS
2.2 Make 100 Cases, 2.1FS

Notice that "Prototype Widget" is a predecessor to both "Approve for Mfgr"
in the first workstream and "Design Case" in the second because you can
neither start manufacturing nor design the carrying case until you've
approved the final design of the widgets.

 

[paul]

Is it possible to show tasks more than once if they are relevant to more than
one workstream (group of tasks)? They should then ideally both (all) update
if updated in one place.

Thanks
Henrik

As others have pointed out, this is not a "normal" occurrence.
However, I have run across it when things are combined -- in my case,
combined progress reviews -- and continuity with previous schedules is
desired.

Consider two parts, each with their own tasks to completion. When it
becomes apparent that they will finish around the same time, it
becomes possible to have a single review meeting encompassing both
products. As such, I have renamed the two reviews, put a common set
of predecessors on one, and made the second a successor to the first.
(Links would work as well in theory, but I don't care for them.) The
customer desires to see it this way for continuity with previous
schedules, but I want to ensure the two dates are always the same.

1.0 Part 1
...
1.4 Combined Review - Part 1 & 2 (1.3 FS, 2.3 FS)
2.0 Part 2
...
2.4 Combined Review - Part 1 & 2 (1.4 SS)

One could use the same predecessors on both reviews, but that will be
double work if they need to be revised for some reason. The
successors to these reviews remain unchanged.

The alternative (normal?) tact is to move the review "out" one or more
levels and only have a single task. This will require adjusting all
the successors.

In either case, you will have some jiggering to do to sync up with
your baseline and EV if there is work associated with this task. On
the whole, I think keeping the task listed twice entails less editing
(and therefore potential for error).

Paul