Salgud gave a partial answer, in that we usually have afixednumber of
resources that we can commit and so theunitsshould'nt change when you edit
work or duration. But I disagree with him in that I findFixedDuration
only rarely to be appropriate andFixedWork to be the norm. Important
note - whileProject'sdefault task setting isFixedUnits, if you editunitson aFixedUnitstask it behaves as if it wasFixedWork. Projects
are not driven forward by the passage of time, they are driven by the
expenditure of work. Tasks produce finite amounts of deliverable - an
exact, predictable, measurable, amount. Any less and the deliverable is
incomplete. Any more and work is being wasted. Work produces the
deliverable and the amount of work required is just as exact in the vast
majority of cases as is the amount of deliverable required. For example, we
need to paint 400 square feet of wall and a painter can paint 10 square feet
per hour when working at capacity (and he WILL work at capacity or we'll
replace him with one who will). 40 man-hours of work is required, no more
and no less. If we commit painter resources to it the duration will drop
and if we pull painter resources away from it the duration will increase but
the required man-hours of work will never change.
We estimate duration, assign resources, andProjectcalculates work. Nowas
we edit to refine our schedule, without changing the default settings, we
have ...
EditUnits, Duration changes;
Edit Work, Duration changes;
Edit Duration, Work changes.
Increase the commitment of the painter, duration shrinks.
Free up part of the painter's day to use him elsewhere, duration grows.
We realize it's 300 square feet, not 400. Edit work to be 30 man-hours,
duration shrinks.
Edit duration - why would we ever do that normally? Duration is not set
arbitrarily. It is something to be discovered within theprojectprocess,
not established by executive fiat. If you ARE going to do it, for instance
when running a "what-if" case in order to figure out how many more resources
you need to recruit to shorten a task so you can complete by a certain
deadline, make the taskFixedWork first.
This, to me, is behaviour that comes closest to modeling the real world.FixedUnits(Work) most of the time,FixedWork some of the time,Fixed
Duration almost never. About the only time I'd useFixedDuration is fora
task that truly requires a specific interval completely independent of the
resource commitment to it - a timed process, for example, that will run for
exactly 24 hours regardless of whether the technician is sitting there the
full time watching it or just pops in for a couple of minutes every few
hours to make sure it's still running. In that case I'd set the duration to
24 hours, make itfixedduration, and assign the resource with whateverunitsI think he'll need to commit to it so we can get an estimate of the
cost (ie, work) of the task.
I tend to think of task type and effort driven settings as switches the PM
can use during "what if" explorations to insureprojectrecalculates the
proper thing when a variable is edited. But it's up to the PM to insure
that the resulting calculation accurately models the real world physical
behaviour of the task parameters.
--
Steve House [ProjectMVP]MSProjectTrainer & Consultant
Visithttp://project.mvps.org/faqs.htmfor the FAQs
I have been teachingMSProjectfor a number of years. Recently, I
came across an article <a href="
http://www.pmi.org/eNews/Post/
2008_04-25/WhatToDoWhenPreparingAProjectSchedule.html</a> that states
"in almost all casesfixedduration should be used". Over the past
hour I have been reading postings in various newsgroups and I have
found that people have various opinions but most recommend usingfixed
duration orfixedWork but notfixedunits. I found Bud's comment
interesting, why wouldMSProjectmakeFixedUnitsthe default if most
so-calledprojectexperts do not recommend using it?- Hide quoted text -
- Show quoted text -
