P
Paul
When initially setting-up a project does it matter if you
add work or duration before reasources?
add work or duration before reasources?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
G
Gérard Ducouret
Hello Paul,
Yes, you can define a task by it's Duration and it's load of Work
Then set the Task Type to Fixed Duration.
When you'll assign a resource to that task, Ms Project will calculate the
Units:
Duration x Units = Work
Gérard Ducouret
Yes, you can define a task by it's Duration and it's load of Work
Then set the Task Type to Fixed Duration.
When you'll assign a resource to that task, Ms Project will calculate the
Units:
Duration x Units = Work
Gérard Ducouret
J
Jan De Messemaeker
Hi all,
BTW, this is true for ll task types, not just for Fixd Duration.
- You always better enter duration
You CAN then enter work
If you do, when assigning a resource, units are calculated
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
Project Management Consultancy
Prom+ade BVBA
32-495-300 620
BTW, this is true for ll task types, not just for Fixd Duration.
- You always better enter duration
You CAN then enter work
If you do, when assigning a resource, units are calculated
HTH
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
Project Management Consultancy
Prom+ade BVBA
32-495-300 620
G
Gérard Ducouret
Hi Paul, hi Jan,
The task type doesn't matter when you enter the Work in the Assign Resources
dialog box. But if you enter it in the Work column inserted in any Table,
the Fixed Units for example yields a strange result :
Try the following : (I'm working with MSP 2002)
Task A : Duration 10d, Assign resource : 20d (in the Units cell) => Ms
Project Calculate : Units = 2, OK.
Task B : Duration 10d, Work : 20d (in the column) => Ms Project Calculate :
Units = 2 *AND* the Duration jumps to 20 d !
If you observe the Task Usage, there are 2 Units nowhere.
Haven't you observed this phenomenon ?
Gérard Ducouret
The task type doesn't matter when you enter the Work in the Assign Resources
dialog box. But if you enter it in the Work column inserted in any Table,
the Fixed Units for example yields a strange result :
Try the following : (I'm working with MSP 2002)
Task A : Duration 10d, Assign resource : 20d (in the Units cell) => Ms
Project Calculate : Units = 2, OK.
Task B : Duration 10d, Work : 20d (in the column) => Ms Project Calculate :
Units = 2 *AND* the Duration jumps to 20 d !
If you observe the Task Usage, there are 2 Units nowhere.
Haven't you observed this phenomenon ?
Gérard Ducouret
J
Jan De Messemaeker
Hi Gérard,
I mostly use 2000, and there it works like a charm
In 2002, it's even more weird than that.
When the resulting units are less than 100% it works perfectly, units are
calculated allright, but when the resulting units WOULD be >100% the
behaviour is as you describe.
Why won't they leave things that work well alone when making a new release?
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
Project Management Consultancy
Prom+ade BVBA
32-495-300 620
I mostly use 2000, and there it works like a charm
In 2002, it's even more weird than that.
When the resulting units are less than 100% it works perfectly, units are
calculated allright, but when the resulting units WOULD be >100% the
behaviour is as you describe.
Why won't they leave things that work well alone when making a new release?
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
Project Management Consultancy
Prom+ade BVBA
32-495-300 620
S
Steve House
Where are you seeing units without resources being assigned for your
Task B? How are you entering 20d for units in Task A?
When I do your experiment with Task B in Proj 2003, it appears the
calculation is "on hold" until the resources are assigned. After
defining 2 resources and entering the task with a duration of 10 days
and a work of 20, nothing happens. Then opening the resource list box,
selecting one resource and hitting "assign" results in a 100% assignment
and a duration of 20 days while selecting both resources and hitting
assign results in both assigned at 100% and the duration remains at 10
days. (Task Type is the default fixed units). Instead of recalculating
units, when assigning resources to a task that already has a work
estimate, Proj 203 assumes a 100% resource assignment for all resources
assigned together and fixed work, then recalculates duration accordingly
which seems to me to be a very reasonable approach. I don't understand
this love affair so many people seem to have with fixed duration tasks.
Task B? How are you entering 20d for units in Task A?
When I do your experiment with Task B in Proj 2003, it appears the
calculation is "on hold" until the resources are assigned. After
defining 2 resources and entering the task with a duration of 10 days
and a work of 20, nothing happens. Then opening the resource list box,
selecting one resource and hitting "assign" results in a 100% assignment
and a duration of 20 days while selecting both resources and hitting
assign results in both assigned at 100% and the duration remains at 10
days. (Task Type is the default fixed units). Instead of recalculating
units, when assigning resources to a task that already has a work
estimate, Proj 203 assumes a 100% resource assignment for all resources
assigned together and fixed work, then recalculates duration accordingly
which seems to me to be a very reasonable approach. I don't understand
this love affair so many people seem to have with fixed duration tasks.
G
Gérard Ducouret
Hello Steve,
In the Assign Resources dialog box, in the "Units" cell in front of the
resource name that I expect to assign.
together and fixed work, then recalculates duration accordingly<<
I would agree if Project 2002 would really do that. The issue is that MSP
2002 displays a 200% assignment while it manages a 100% assignment.
So we have something like that :
20d duration x 2 units = 20 days of work !!!
(NB: I tried this in the 2002 version, it worked differently in the previous
versions, and I did not tried it in 2003).
Gérard Ducouret
In the Assign Resources dialog box, in the "Units" cell in front of the
resource name that I expect to assign.
together and fixed work, then recalculates duration accordingly<<
I would agree if Project 2002 would really do that. The issue is that MSP
2002 displays a 200% assignment while it manages a 100% assignment.
So we have something like that :
20d duration x 2 units = 20 days of work !!!
(NB: I tried this in the 2002 version, it worked differently in the previous
versions, and I did not tried it in 2003).
Gérard Ducouret
G
Gérard Ducouret
PS :
<<I don't understand this love affair so many people seem to have with fixed
duration tasks<<
I don't have any love affair with fixed duration tasks ;-)
Less than 0.1% of my tasks are set to Fixed Duration in my projects.
Gérard Ducouret
<<I don't understand this love affair so many people seem to have with fixed
duration tasks<<
I don't have any love affair with fixed duration tasks ;-)
Less than 0.1% of my tasks are set to Fixed Duration in my projects.
Gérard Ducouret
G
Gary L. Chefetz [MVP]
Steve:
You need to think outside the classic PM box to understand this. It's not a
love affair, it's a necessity to model certain business processes that do
not fit into an "as soon as possible" scenario. It's evident that you have a
distinct bias toward effort-based planning, and I accept all of your
arguments for it as valid, however that ideal-state is often not desirable
or achievable. Thankfully, Project supports both methodologies.
You need to think outside the classic PM box to understand this. It's not a
love affair, it's a necessity to model certain business processes that do
not fit into an "as soon as possible" scenario. It's evident that you have a
distinct bias toward effort-based planning, and I accept all of your
arguments for it as valid, however that ideal-state is often not desirable
or achievable. Thankfully, Project supports both methodologies.
S
student
I agree completely Gary - I'm a big believer in the right tool for the job.
What I teach my classes is that the task type should be looked at for each
individual task immediately prior to changing any of the three WED values
with an eye to the question "Why am I changing this and what should happen
to the task when I do?" I view it as a control for the PM to use to direct
Project's scheduling engine's behavior toward the most accurate model and
not an attribute of the task per se. What I do see in a lot of my students
is that they have a preconceived notion of what the schedule *should* be and
then set tasks to fixed duration in an effort to prevent Project from
telling them different, even when it really should be doing so.
Steve House
MS PRoject MVP
What I teach my classes is that the task type should be looked at for each
individual task immediately prior to changing any of the three WED values
with an eye to the question "Why am I changing this and what should happen
to the task when I do?" I view it as a control for the PM to use to direct
Project's scheduling engine's behavior toward the most accurate model and
not an attribute of the task per se. What I do see in a lot of my students
is that they have a preconceived notion of what the schedule *should* be and
then set tasks to fixed duration in an effort to prevent Project from
telling them different, even when it really should be doing so.
Steve House
MS PRoject MVP
S
Steve House
Opps - wrong account
I agree completely Gary - I'm a big believer in the right tool for the job.
What I teach my classes is that the task type should be looked at for each
individual task immediately prior to changing any of the three WED values
with an eye to the question "Why am I changing this and what should happen
to the task when I do?" I view it as a control for the PM to use to direct
Project's scheduling engine's behavior toward the most accurate model and
not an attribute of the task per se. What I do see in a lot of my students
is that they have a preconceived notion of what the schedule *should* be and
then set tasks to fixed duration in an effort to prevent Project from
telling them different, even when it really should be doing so.
Steve House
MS PRoject MVP
I agree completely Gary - I'm a big believer in the right tool for the job.
What I teach my classes is that the task type should be looked at for each
individual task immediately prior to changing any of the three WED values
with an eye to the question "Why am I changing this and what should happen
to the task when I do?" I view it as a control for the PM to use to direct
Project's scheduling engine's behavior toward the most accurate model and
not an attribute of the task per se. What I do see in a lot of my students
is that they have a preconceived notion of what the schedule *should* be and
then set tasks to fixed duration in an effort to prevent Project from
telling them different, even when it really should be doing so.
Steve House
MS PRoject MVP
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.