B
Bryan A
Other than within a gannt view is there a way to split a task?
i.e. take a 12hr task and split it into 3 - 4hr tasks?
Bryan
i.e. take a 12hr task and split it into 3 - 4hr tasks?
Bryan
B
Bryan A
Thanks for your help!
Logic link? is that a function somewhere within project?
Bryan
Logic link? is that a function somewhere within project?
Bryan
M
Mike Glen
Hi Bryan,
Welcome to this Microsoft Project newsgroup
Yes. Try the Task Usage view, zoom in to hours of the day and enter zeros
where you want the gaps. If that is not what you meant, I would create 2
more tasks, logic link the three and apportion the time between them.
FAQs, companion products and other useful Project information can be seen at
this web address: http://www.mvps.org/project/
Hope this helps - please let us know how you get on
Mike Glen
Project MVP
Welcome to this Microsoft Project newsgroup
Yes. Try the Task Usage view, zoom in to hours of the day and enter zeros
where you want the gaps. If that is not what you meant, I would create 2
more tasks, logic link the three and apportion the time between them.
FAQs, companion products and other useful Project information can be seen at
this web address: http://www.mvps.org/project/
Hope this helps - please let us know how you get on
Mike Glen
Project MVP
J
Jan De Messemaeker
Hi Bryan,
There is no circular reference at all.
I numbered your tasks below and put the sucessor number behind.
This does not give a circular reference at all.
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
Project Management Consultancy
Prom+ade BVBA
32-495-300 620
There is no circular reference at all.
I numbered your tasks below and put the sucessor number behind.
This does not give a circular reference at all.
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
Project Management Consultancy
Prom+ade BVBA
32-495-300 620
B
Bryan A
I agree that by having the successor tasks set the way that you have them,
it doesn't create a circular reference with, and this is the kicker, the
cycle tasks on the same level as the summary task. Once you indent them to
the next level it creates a circular reference. So by going down this train
of thought is there a way to have a summary task on the same level as it's
subordinate tasks?
isn't this fun?? I have another question about leveling that I'll post on a
different string.
Thanks for all your help.
Bryan
it doesn't create a circular reference with, and this is the kicker, the
cycle tasks on the same level as the summary task. Once you indent them to
the next level it creates a circular reference. So by going down this train
of thought is there a way to have a summary task on the same level as it's
subordinate tasks?
isn't this fun?? I have another question about leveling that I'll post on a
different string.
Thanks for all your help.
Bryan
B
Bryan A
Jan,
I sincerely apologize. Honestly I tried it several times before I posted
this message. You are definitely correct. I set it up one more time and it
worked fine. Thanks for being persistent.
Bryan
I sincerely apologize. Honestly I tried it several times before I posted
this message. You are definitely correct. I set it up one more time and it
worked fine. Thanks for being persistent.
Bryan
J
Jan De Messemaeker
No sweat.
I was sure you kept on making connections to the summary taks, which is not
necessary for your logic.
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
Project Management Consultancy
Prom+ade BVBA
32-495-300 620
I was sure you kept on making connections to the summary taks, which is not
necessary for your logic.
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
Project Management Consultancy
Prom+ade BVBA
32-495-300 620
S
Steve House
In addition to Jan's fix, you might also want to reconsider the structure of
the tasks themselves. I'd suggest reversing the positions of the summary and
detail tasks. In a project WBS, a summary task does not represent "class"
of work, like carpentry, painting, coding, testing, etc with all the
instances of that operation in the project indented underneath it - grouping
subtasks by type. Instead they summarize a sequence of operations that will
end in a given result, a "state change" if you will, that is one of the
deliverables or components in the project. In an application that requires
a number of code modules, a summary task would be the creation of one of the
modules, with all the various activities that go into creating that specific
module represented as subtasks under it.
It appears your code development process is going through several iterations
of a loop, just like code itself does in a "do while" loop. A program loop
goes through a sequence of operations until a certain state change occurs in
the data and then exits the loop, right? Unfortunately, there is no way to
encode loop logic in a WBS - we have to estimate in advance how many
iterations of a repeating sequence will be required - the example you gave
shows three iterations are to be expected. But you can accomplish the same
thing by having each iteration represented as a summary task, the summaries
linked in success if you like, and the various elements of each individual
cycle as subtasks under the summary. I suggest you will have a far easier
time of it, both from a schedule development and resource assignment
standpoint and a later management standpoint is you restructure the logic as
follows:
1 Start
2 Code Create
3 Code Evaluate
3.a Cycle 1
3.a.1 Code Review
3.a.2 Code Modification
3.b Cycle 2
3.b.1 Code Review
3.b.2 Code Modification
3.c Cycle 3
3.c.1 Code Review
3.c.2 Code Modification
4 Code Accepted
5 Finish
Notice that each cycle is a summary task and the three cycles are to be done
in succession. Each cycle consists of two operations, Review and Modify.
Should it require additional iterations it is easy to add them and if it
turns out we're lucky enough hit the mark with only one or two cycles we can
easily remove the extras. Notice also the dates and durations of our
summary tasks are now more meaningful, showing the time each phase is going
to take. Using your structure, the duration of the code review summary, for
example, will show the total time between start of the review of cycle 1 to
the end of the review of cycle three, not a very meaningful value.
the tasks themselves. I'd suggest reversing the positions of the summary and
detail tasks. In a project WBS, a summary task does not represent "class"
of work, like carpentry, painting, coding, testing, etc with all the
instances of that operation in the project indented underneath it - grouping
subtasks by type. Instead they summarize a sequence of operations that will
end in a given result, a "state change" if you will, that is one of the
deliverables or components in the project. In an application that requires
a number of code modules, a summary task would be the creation of one of the
modules, with all the various activities that go into creating that specific
module represented as subtasks under it.
It appears your code development process is going through several iterations
of a loop, just like code itself does in a "do while" loop. A program loop
goes through a sequence of operations until a certain state change occurs in
the data and then exits the loop, right? Unfortunately, there is no way to
encode loop logic in a WBS - we have to estimate in advance how many
iterations of a repeating sequence will be required - the example you gave
shows three iterations are to be expected. But you can accomplish the same
thing by having each iteration represented as a summary task, the summaries
linked in success if you like, and the various elements of each individual
cycle as subtasks under the summary. I suggest you will have a far easier
time of it, both from a schedule development and resource assignment
standpoint and a later management standpoint is you restructure the logic as
follows:
1 Start
2 Code Create
3 Code Evaluate
3.a Cycle 1
3.a.1 Code Review
3.a.2 Code Modification
3.b Cycle 2
3.b.1 Code Review
3.b.2 Code Modification
3.c Cycle 3
3.c.1 Code Review
3.c.2 Code Modification
4 Code Accepted
5 Finish
Notice that each cycle is a summary task and the three cycles are to be done
in succession. Each cycle consists of two operations, Review and Modify.
Should it require additional iterations it is easy to add them and if it
turns out we're lucky enough hit the mark with only one or two cycles we can
easily remove the extras. Notice also the dates and durations of our
summary tasks are now more meaningful, showing the time each phase is going
to take. Using your structure, the duration of the code review summary, for
example, will show the total time between start of the review of cycle 1 to
the end of the review of cycle three, not a very meaningful value.