Defining duration in materials

[Laser_razor]

Hi everyone,

does anybody know how to define a duration in material ? like maximum
material available.

That would allow to specify if a material ressource is defined as xx
units/hr to calculate how long it may take to complete the task.

Greetings

Marcus

 

[Jan De Messemaeker]

Hi,

Maybe you can program something like this in VBA but it definitely isn't
standard Project.
Project doesn't even want to know how much of a material is available let
alone how long you can work with that.
Sorry!

 

[Steve House]

No offense intended but that just doesn't make sense. A task produces a
specific, finite, deliverable. It's done when the deliverable is finished.
A material resource is consumed over the duration of a task, it is not the
result of the task. We don't assemble widgets for the length of time it
takes to use up the widget parts in inventory. We assemble widgets for the
time it takes to produce the required number of widgets and we make sure we
order how ever many parts it's going to take to create the required number
of widgets.

Project assumes materials are infinite in supply and instantaneously
available whenver needed. Sorry, what you're asking isn't in the cards.

 

[Laser_razor]

No Problem.

Unfortunately materials are most od the time not infinite and I would
love to use that kind of functionality to control a large production
outlet.

I will go the detour around and use work and length of work to define
in combination with ressources per time the maximum material consumed.

But that is only a trick to go around.... May be MS Project will
supply that field one day to enter maximum material available and will
automaticall y end the task when the material is completely consumed
by the unit / time equasion, defined by the calendar used...



So far thanks and happy projecting !!!

 

[Steve House]

I'm having a real problem thinking of a real world application where the
length of the task is defined by the quantity of raw materials on-hand. Is
not the OUTPUT of any task more important than the input? If my task is to
make widgets usually I have to make a specific number of them and the finish
of the task is defined by when I have made exactly that many, no more and no
less. Yes, I need to make sure I order enough parts for the number of
widgets that I need and it would certainly be nice if Project has some tools
to help manage the quantity on-hand (which it doesn't). But I'd never make
how ever many widgets I happen to have parts on hand for - the instant
project will always requre an exact specific number. Using parts on hand to
control their creation would virtually always lead me either to make too few
for the needs of the project or so many that I've wasted resources by making
more than are needed.

You said "control large production outlet." Perhaps that's the source of
your discomfort. Projects are time limited undertakings producing a
specific, clearly defined, unique and quantifiable output. When that
output is completed, the project evaporates and ceases to exist for all
time. MS Project is designed to schedule that sort of activity and it
doesn't comfortably lend itself to ongoing production management, something
that it's simply not designed to do. If you try to force a square peg down
a round hole you're bound to experience some frustration.

 

[Dave]

I'm having a real problem thinking of a real world application where the
length of the task is defined by the quantity of raw materials on-hand.
Is not the OUTPUT of any task more important than the input? If my task
is to make widgets usually I have to make a specific number of them and
the finish of the task is defined by when I have made exactly that many,
no more and no less. Yes, I need to make sure I order enough parts for
the number of widgets that I need and it would certainly be nice if
Project has some tools to help manage the quantity on-hand (which it
doesn't). But I'd never make how ever many widgets I happen to have
parts on hand for - the instant project will always requre an exact
specific number. Using parts on hand to control their creation would
virtually always lead me either to make too few for the needs of the
project or so many that I've wasted resources by making more than are
needed.

You said "control large production outlet." Perhaps that's the source
of your discomfort. Projects are time limited undertakings producing a
specific, clearly defined, unique and quantifiable output. When that
output is completed, the project evaporates and ceases to exist for all
time. MS Project is designed to schedule that sort of activity and it
doesn't comfortably lend itself to ongoing production management,
something that it's simply not designed to do. If you try to force a
square peg down a round hole you're bound to experience some frustration.

One example would be when components needed become obsolete. Then you
may be faced with a scenario in which what you can make is determined by
what you can get as end-of-lifetime buys.

One scenario that is likely to be relatively common is when the supply
of raw components is rate limited. So if I have a given quantity of raw
materials in stock now, I can make what I can now and make some more
later on when I have more materials and so on. This approach makes
sense in some Project scenarios because you can de-risk your development
now rather than waiting until the end and making the whole lot at once
thereby taking the risk that problems will be discovered late in the
Project. Admittedly this isn't quite what the OP originally described,
but it isn't a million miles away.

 

[Jan De Messemaeker]

Hi Dave and all,

That IS what the poster meant.
You can only produce till you run out of base product.
Even Steve's widgets need some sort of input, which may indeed be in short
supply.
This very often IS real-world you know.

Greetings,

 

[Steve House]

My thinking runs along the lines of putting up a building. You don't
build until you run out of bricks, you order enough bricks so the amount
on-hand is sufficient to erect the building the specifications call for.
You can't stop a few floors short because you ran out of bricks and you
don't continue to add more floors than were called for in the blueprints
because you happen to have more bricks than required. Now, in a
production environment where you're going to keep making stuff as long
as the demand holds out that's another matter. But projects are
closed-ended, you can't stop until the deliverable is created and you do
stop once the deliverable is created even if you have the ability to go
farther.