Default Task Type

[JR Winder]

I have a web development project whose total cost was based on estimated
development hours * hourly rarte. The project includes 15 modules, each
estimated (hours to complete) separately but with the same hourly rate.

Because of the hours estimates should the task type for resources
(programmers only) be set to Fixed Work rather than the default Fixed
Duration? I'm thinking it makes sense to have the programmer resources be
Fixed Work and then insert a 'Work' column in the Gant Chart view to put the
est hrs for each module for. Does this sound right?

Thanks in advance
JR

 

[Jack Dahlgren]

Task type is set on tasks rather than resources, but yes, you may find it
more convenient to have task type for hourly estimated tasks like the ones
for programmers, to be set to fixed work.

Your approach sounds right to me.

-Jack Dahlgren

 

[Steve House]

As Jack said. In fact, Fixed Units, not Fixed Duration, is the default
'fresh out of the box' task type and for your application either that or
fixed work makes much more sense than fixed duration. In fact, I'm very
reluctant to suggest fixed duration for any except the most unusual
situations. Consider, a programmer may be able to produce 10 lines of
debugged code per man-hour if he doesn't have any distractions. He has to
produce a module that would take about 1000 lines of code. If he's not
distracted by competing tasks he'll take about 100 hours to complete that
module. But if he's constantly called into meetings, handling tech support
calls, etc he's not going to be able to average 10 lines per hour and so it
would take him more than 100 hours of time to produce that 1000 required
lines of code. That's classic fixed work behaviour. "Fixed Duration" means
he would work on it for 100 hours then stop and it wouldn't matter if he
gotten 500 lines, 1000 lines, or 1500 lines written in that time period, we
would say he had successfully done the task - that makes no sense
what-so-ever.

HTH

 

[Jack Dahlgren]

Steve,

Actually, no, it doesn't. We would say that he had completed his work when
he had completed it. Effort or duration or units are NOT measures of
physical completion. Fixed duration only controls the way that project
processes changes to work, units or duration. The equation is exactly the
same except that one of the variables is fixed.

-Jack Dahlgren

 

[Steve House]

When a project manager enters a task as having X hours duration and sets it
to fixed duration he has said that editing effort will change work and
editing work will change effort, holding task time constant. It says that
effort and work units are variables but how can that be, what physical
condition does that model? Can time frames arbitarily set ever really be
the determining factor in how a schedule proceeds? Do you speed up or slow
down your work so that the man-hours of full-time equivalent work, thus the
output you are required to produce, is done in some a priori determined time
frame? Or if you work at a constant rate of 100% effort, does the amount of
deliverable required change to fit the amount produced in some arbitrarily
determined X hours of time? The scheduling equations model physical
reality - what real world human behaviour does fixed duration model? You
have X units of resources available and the amount of work they must do is
fixed by the physical process of the project itself - the most fluid metric
is time and IMHO it is generally the dependent variable. Work is driven by
deliverable and effort units by resource capacity, duration is the
consequence.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs

Steve,

Actually, no, it doesn't. We would say that he had completed his work when
he had completed it. Effort or duration or units are NOT measures of
physical completion. Fixed duration only controls the way that project
processes changes to work, units or duration. The equation is exactly the
same except that one of the variables is fixed.

-Jack Dahlgren

 

[Jack Dahlgren]

When a project manager enters a task as having X hours duration and sets
it to fixed duration he has said that editing effort will change work and
editing work will change effort, holding task time constant. It says that
effort and work units are variables but how can that be, what physical
condition does that model?

It models the condition where you bring on more workers or assign your
workers at greater rates to tasks that must be completed by a certain date.
This answers the question - "How many people do I need to get this work done
by May?" or "If I assign Joe at 50% will it finish as planned?".

Can time frames arbitarily set ever really be the determining factor in
how a schedule proceeds?

Yes, of course. But they aren't arbitrary. You can't reduce or expand a task
beyond certain limits.

Do you speed up or slow down your work so that the man-hours of full-time
equivalent work, thus the output you are required to produce, is done in
some a priori determined time frame?

Yes, you may do this indirectly by working on something else or by
postponing something else so you can meet your commitments.

Or if you work at a constant rate of 100% effort, does the amount of
deliverable required change to fit the amount produced in some arbitrarily
determined X hours of time?
What?

The scheduling equations model physical reality - what real world human
behaviour does fixed duration model?

They are just equations. Think about them. You should be able to figure out
a good example. If you haven't read the examples above I summarize them in
the last paragraph.

You have X units of resources available and the amount of work they must
do is fixed by the physical process of the project itself - the most fluid
metric is time and IMHO it is generally the dependent variable. Work is
driven by deliverable and effort units by resource capacity, duration is
the consequence.

Your experience and mine differ in this regard.
Resource capacity IS a variable. It is possible to increase or decrease
resources as required to meet deadlines.
Work IS a variable. Project scope can be changed to meet deadlines.
Fixing duration in both of those cases is an appropriate modelling choice.
I agree that ALL forms of "fixed X" are useful in certain circumstances. I
don't know why you insist that Fixed Duration is the only one which is not
valid.

-Jack Dahlgren

 

[Steve House]

Exactly my point! All of your examples describe a fixed work task type, not
fixed duration. You have a task that needs to be done in 1 week but is
presently requiring 3. You increase the resource units until the task
duration shortens down to 1 week. That's fixed work behaviour, not fixed
duration. Making it fixed duration task programs sets it so that no matter
how you adjusted the resource units the duration would remain at 3 weeks
while the computed man-hours for the task, hence its cost, would change. I
reiterate, the latter behaviour just doesn't make sense as an approach to
scheduling the majority of the time.

Resource maximums aren't so variable - perhaps if you're using day labour
and can always call the hiring hall to send another guy but generally the
situation is more like you have 3 engineers for the duration of the project
so you can use resource 'engineer' up to a total of 300% at any one time but
the time frame for recruiting and hiring a fourth is such that for all
practical purposes that 300% is an engraved-in-granite fixed limit. At the
same time, you're not going to use them less than the maximum except in very
unusual circumstances because that would needlessly delay your project. So
you can say assigning 'engineer' to the max of 300% is pretty well fixed
across the project.

Project scope certainly isn't a variable in most cases - the project calls
for paving 100 km of road by 01 Sept. You don't stop at 75km because you
are taking longer than planned and have only gotten that far by the deadline
date and you don't keep going paving extra kilometres if you've finished the
100 by 01 August. The scope is fixed, the project manager's to figure out
how to achieve it efficiently.

I don't say fixed duration isn't valid - I say it's overused. The problem I
have is that it is very often used in a scenario where an admin assistant
has been given an project "schedule" on a yellow legal pad that has been
worked out manually by his boss and the sales department and he's trying to
pump it into Project. When Project insists on recalculating dates and the
result doesn't conform to the boss's seat of the pants mandates or the sales
rep's pie in the sky promises to the client, he discovers he can 'fudge the
system' by making tasks fixed duration so the dates don't recalculate and
Project becomes a glorified Gantt chart typewriter. The end result is a
'schedule' in project that bears no relation to physical reality whatsoever
and is most likely completely unworkable and doomed to failure.

 

[Jack Dahlgren]

Exactly my point! All of your examples describe a fixed work task type,
not fixed duration. You have a task that needs to be done in 1 week but
is presently requiring 3. You increase the resource units until the task
duration shortens down to 1 week. That's fixed work behaviour, not fixed
duration. Making it fixed duration task programs sets it so that no
matter how you adjusted the resource units the duration would remain at 3
weeks while the computed man-hours for the task, hence its cost, would
change. I reiterate, the latter behaviour just doesn't make sense as an
approach to scheduling the majority of the time.

It makes sense in many cases which I have been involved.

Resource maximums aren't so variable - perhaps if you're using day labour
and can always call the hiring hall to send another guy but generally the
situation is more like you have 3 engineers for the duration of the
project so you can use resource 'engineer' up to a total of 300% at any
one time but the time frame for recruiting and hiring a fourth is such
that for all practical purposes that 300% is an engraved-in-granite fixed
limit.

This is not my experience. Resources are frequently shifted from one project
to one with higher priority. Likewise, in planning, no resources have
actually been assigned. You often want to know how many resources something
would take.

At the same time, you're not going to use them less than the maximum
except in very unusual circumstances because that would needlessly delay
your project. So you can say assigning 'engineer' to the max of 300% is
pretty well fixed across the project.

Again, this does not match my experience. Resource needs during a project
are variable. The typical S curve is just another illustration of this.

Project scope certainly isn't a variable in most cases - the project calls
for paving 100 km of road by 01 Sept. You don't stop at 75km because you
are taking longer than planned and have only gotten that far by the
deadline date and you don't keep going paving extra kilometres if you've
finished the 100 by 01 August.

In software development scope trade-off is common. Even in hard-bid
construction projects scope is traded off against schedule.

The scope is fixed, the project manager's to figure out how to achieve it
efficiently.

Scope is often negotiable. This is why we have change orders.

I don't say fixed duration isn't valid - I say it's overused.

Actually, you didn't say it was overused. You said it doesn't model "real
world human behavior". I interpret that to mean it is not valid - making the
assumption that schedules should model reality.

The problem I have is that it is very often used in a scenario where an
admin assistant has been given an project "schedule" on a yellow legal pad
that has been worked out manually by his boss and the sales department and
he's trying to pump it into Project.

No. You have been stating that it does not model reality. I contend it does
and is valid in many cases.
Changing your assertions at this point only confuse the issue.

When Project insists on recalculating dates and the result doesn't conform
to the boss's seat of the pants mandates or the sales rep's pie in the sky
promises to the client, he discovers he can 'fudge the system' by making
tasks fixed duration so the dates don't recalculate and Project becomes a
glorified Gantt chart typewriter.

Just because something allows bad behavior doesn't mean it is bad. There are
perfectly valid and righteous uses of fixed duration. It is several steps
above things like linking summary tasks on my scale of good and evil
scheduling practices.

The end result is a 'schedule' in project that bears no relation to
physical reality whatsoever and is most likely completely unworkable and
doomed to failure.

Fixed duration doesn't doom projects. People doom projects.

-Jack Dahlgren

 

[Steve House]

Except for the rare cases when the task really is something that must run
for a specific time, such as a test that must run for precisely 24 hours, no
more and no less, why would you fix the duration and vary the resources
while recomputing work as the dependent variable? Work effort is what
translates directly to deliverable creation, not the passage of time. It
seems more logical to fix the amount of work to that which will produce the
required deliverable and vary the resources until the computed time fits
into the required deadlines. Indeed, the applications you offer where you
are trying to determine how many resources will be required on the project
is exactly where that approach is most useful. "Our contract calls for us
to deliver 1000 widgets on June 1st and it takes 1 man 1 hour to make 1
widget. How many resources will it take to complete the required 1000
man-hours of work by our contracted delivery date?" Answering that question
is best done through fixed work task typing, not fixed duration, comparing
computed end date with the contract deadline and adjusting resources
accordingly. (And note, when you vary the units on a default fixed units
tasks, Project treats the task as fixed work.)

I know that scope tradoffs happen in software development (and elsewhere) -
that doesn't mean they're good. Remember Windows ME? Having to renegotiate
for a reduced scope after the project begins is one of the things one is
trying to avoid through proper planning. Reducing scope because the
business objectives or priorities have changed - no problem. But change
orders shouldn't come about from planning failure, they should come from
change to the strategic business need for the project's objectives,
initiated or at the least approved by higher pay-grades than the project
manager. A project that doesn't complete its stated charter objectives 100%
is a failed project, something we're trying to avoid through proper
planning.

 

[Jack Dahlgren]

Except for the rare cases when the task really is something that must run
for a specific time, such as a test that must run for precisely 24 hours,
no more and no less, why would you fix the duration and vary the resources
while recomputing work as the dependent variable? Work effort is what
translates directly to deliverable creation, not the passage of time. It
seems more logical to fix the amount of work to that which will produce
the required deliverable and vary the resources until the computed time
fits into the required deadlines. Indeed, the applications you offer
where you are trying to determine how many resources will be required on
the project is exactly where that approach is most useful. "Our contract
calls for us to deliver 1000 widgets on June 1st and it takes 1 man 1 hour
to make 1 widget. How many resources will it take to complete the
required 1000 man-hours of work by our contracted delivery date?"
Answering that question is best done through fixed work task typing, not
fixed duration, comparing computed end date with the contract deadline and
adjusting resources accordingly.

Why? Fixing duration and entering work will give you the resource
requirement in a single step. I don't understand why you contend that the
easiest way to do this is wrong.

(And note, when you vary the units on a default fixed units

tasks, Project treats the task as fixed work.)

I know that scope tradoffs happen in software development (and
elsewhere) - that doesn't mean they're good.

Changes to a plan in response to reality are inevitable and are neither bad
nor good.

Remember Windows ME? Having to renegotiate for a reduced scope after the
project begins is one of the things one is trying to avoid through proper
planning. Reducing scope because the business objectives or priorities
have changed - no problem. But change orders shouldn't come about from
planning failure, they should come from change to the strategic business
need for the project's objectives, initiated or at the least approved by
higher pay-grades than the project manager. A project that doesn't
complete its stated charter objectives 100% is a failed project, something
we're trying to avoid through proper planning.

The schedule tool doesn't know if a change is good or bad either. I hope you
aren't suggesting that a schedule is failed if there is any change to it.
Changing your "reality" to match your plan is not a particularly good idea.

-Jack Dahlgren

 

[Steve House]

Changes to the schedule don't mean it's failed. But a project plan that a)
finishes late; b) finishes over budget; c) fails to meet chartered scope; or
d) is abandoned prior to completion certainly is. While scope changes
certainly occur and by themselves don't necessarily mean failure, they
should be driven by changing business needs or a changing economic
environment and not by scheduling or budgetary conditions within the
project. The whole reason for using a scheduling tool is so we are better
able to devise a plan that will have us finishing on-time and within budget
WITHOUT having to compromise on scope or quality and one that is solidly
enough grounded in reality that we'll actually be able to work the plan as
scheduled in practice.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs



....>> I know that scope tradoffs happen in software development (and

 

[Jack Dahlgren]

Exactly. But that has nothing to do with the use of fixed duration tasks
does it?
In my opinion they are a valid and useful way of modeling a schedule.

-Jack

Changes to the schedule don't mean it's failed. But a project plan that
a) finishes late; b) finishes over budget; c) fails to meet chartered
scope; or d) is abandoned prior to completion certainly is. While scope
changes certainly occur and by themselves don't necessarily mean failure,
they should be driven by changing business needs or a changing economic
environment and not by scheduling or budgetary conditions within the
project. The whole reason for using a scheduling tool is so we are better
able to devise a plan that will have us finishing on-time and within
budget WITHOUT having to compromise on scope or quality and one that is
solidly enough grounded in reality that we'll actually be able to work the
plan as scheduled in practice.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs



...>> I know that scope tradoffs happen in software development (and

Changes to a plan in response to reality are inevitable and are neither
bad nor good.
....

The schedule tool doesn't know if a change is good or bad either. I hope
you aren't suggesting that a schedule is failed if there is any change to
it. Changing your "reality" to match your plan is not a particularly good
idea.

-Jack Dahlgren

 

[Mike Glen]

If I may enter the debate, I'm not convinced about estimating the Work to
assign to a task. It is my opinion that we humans don't take naturally to
estimating work. Except for very short term, say, no more than 2 day's
worth, I believe it is more natural to say that a task will take a week, 2
weeks, a month, 4 days, whatever. It's very unlikely that estimates will
come naturally like 230 hours of work, or 42 hours, or 520 hours. If you
receive estimates in man-hours, my bet is that the individual has said to
himself "that'll take me about 10 days" and he then converts that to 80
man-hours, at 8 hours per day, or 75 at 7.5 hours per day, to give you the
Work cost. This seems most unnatural to me. So why not ask for estimated
durations in days, weeks, months and let Project do the arithmetic for you.

Mike Glen
Project MVP

Exactly. But that has nothing to do with the use of fixed duration tasks
does it?
In my opinion they are a valid and useful way of modeling a schedule.

-Jack

Changes to the schedule don't mean it's failed. But a project plan that
a) finishes late; b) finishes over budget; c) fails to meet chartered
scope; or d) is abandoned prior to completion certainly is. While scope
changes certainly occur and by themselves don't necessarily mean failure,
they should be driven by changing business needs or a changing economic
environment and not by scheduling or budgetary conditions within the
project. The whole reason for using a scheduling tool is so we are
better able to devise a plan that will have us finishing on-time and
within budget WITHOUT having to compromise on scope or quality and one
that is solidly enough grounded in reality that we'll actually be able to
work the plan as scheduled in practice.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs



...>> I know that scope tradoffs happen in software development (and

elsewhere) - that doesn't mean they're good.

Changes to a plan in response to reality are inevitable and are neither
bad nor good.
....

The schedule tool doesn't know if a change is good or bad either. I hope
you aren't suggesting that a schedule is failed if there is any change
to it. Changing your "reality" to match your plan is not a particularly
good idea.

-Jack Dahlgren

 

[Steve House]

Exactly - my point is more what happens after the initial estimate - as one
does "what-if" cases to build a workable plan to best meet the project's
objectives, should one lock down the duration to the initial estimate and
have the work estimate change for each revision in resource assignment or
does it make more sense to lock down the work estimate that Project has
initially calculated and have the duration change as we experiment with
different resource assignments? The most logical approach seems to me to be
to initially enter a preliminary estimated duration based on an anticipated
resource availability, letting Project calculate the work. Then we see if
the computed finish meets our objectives. If not, hold the work constant
(since work and not the passage of time is what creates the task's
deliverable) and juggle resource assignments until the computed durations
match those required to achieve the project's deadlines. I reiterate my
objection to fixed duration - it's often used to try to force the project
schedule to conform to some preceived notion of what it ought to look like -
management as an act of imposition of will power - rather than going through
the process of discovery of a working model that can be used to accurately
predict outcomes. Generally I think it should only be used for those
situations where a precisely defined duration is implicit within the
physical process of the task itself, as an example a test that must be run
for a specific period of time. I tend to think of the optimum schedule as
something to be discovered rather than something to be decided.

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

If I may enter the debate, I'm not convinced about estimating the Work to
assign to a task. It is my opinion that we humans don't take naturally to
estimating work. Except for very short term, say, no more than 2 day's
worth, I believe it is more natural to say that a task will take a week, 2
weeks, a month, 4 days, whatever. It's very unlikely that estimates will
come naturally like 230 hours of work, or 42 hours, or 520 hours. If you
receive estimates in man-hours, my bet is that the individual has said to
himself "that'll take me about 10 days" and he then converts that to 80
man-hours, at 8 hours per day, or 75 at 7.5 hours per day, to give you the
Work cost. This seems most unnatural to me. So why not ask for estimated
durations in days, weeks, months and let Project do the arithmetic for
you.

Mike Glen
Project MVP

Exactly. But that has nothing to do with the use of fixed duration tasks
does it?
In my opinion they are a valid and useful way of modeling a schedule.

-Jack

Changes to the schedule don't mean it's failed. But a project plan that
a) finishes late; b) finishes over budget; c) fails to meet chartered
scope; or d) is abandoned prior to completion certainly is. While scope
changes certainly occur and by themselves don't necessarily mean
failure, they should be driven by changing business needs or a changing
economic environment and not by scheduling or budgetary conditions
within the project. The whole reason for using a scheduling tool is so
we are better able to devise a plan that will have us finishing on-time
and within budget WITHOUT having to compromise on scope or quality and
one that is solidly enough grounded in reality that we'll actually be
able to work the plan as scheduled in practice.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs



...>> I know that scope tradoffs happen in software development (and
elsewhere) - that doesn't mean they're good.

Changes to a plan in response to reality are inevitable and are neither
bad nor good.

....

The schedule tool doesn't know if a change is good or bad either. I
hope you aren't suggesting that a schedule is failed if there is any
change to it. Changing your "reality" to match your plan is not a
particularly good idea.

-Jack Dahlgren