Steve
Thu Mar 20 06:37:02 CDT 2008
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.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit
http://project.mvps.org/faqs.htm for the FAQs
"Jack Dahlgren" <jack@zo-d.com> wrote in message
news:ed9FG8diIHA.4468@TK2MSFTNGP03.phx.gbl...
>
> "Steve House" <sjhouse at hotmail dot com> wrote in message
> news:ecUChbaiIHA.4868@TK2MSFTNGP03.phx.gbl...
>> 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
>
>