Adding additional duration units

[Natasha]

I am using project to map factory processes in order to evaluate resources
and costs. Some processes take 30 seconds, but I can't figure out how to
change the duration units to allow for less than a minute. Any ideas? This
may seem like micro-scheduling, but is necessary for using a shared resource
pool in a manufacturing setting.

 

[Jan De Messemaeker]

Hi Natasha,

30 secs can be entered as 0.5 min
Project's internal clock ticks i tenths of a minute; hope this is good
enough for you?
HTH

 

[davegb]

I am using project to map factory processes in order to evaluate resources
and costs. Some processes take 30 seconds, but I can't figure out how to
change the duration units to allow for less than a minute. Any ideas? This
may seem like micro-scheduling, but is necessary for using a shared resource
pool in a manufacturing setting.

Manufacturing processes are not projects. A project, by any definition,
has a start and an end date.

Hope this helps in your world.

 

[Ratheesh]

Natasha,
Minutes is the smallest fraction that can be accounted in MS project

But here is some crazy idea if there are no other tools available other than
MS Excel and you want to somehow use MS project.Not very sure if this will
work.I have never tried and apologize if this is a stupid one.

Since minutes is the smallest fraction that can be accounted in MS project
you can achieve recoding seconds only by doing some kind of manual conversion.

Say if you want to enter 1 second for a task enter 60 meaning project will
take that as 60 seconds rather than 60 minutes since these clock times are
always devisible by 60 to achive next level of the measurment scale
(hour/minuts) this may help you.You can include a custom colum/equation to
see the hour/minuts value the project is indicatind in the work column.

Hope this helps

 

[Natasha]

The process is a project if the start and end date are defined as one day.

 

[Natasha]

Thanks. I tried this, but it shows as zero duration. Does MSP still
calculate 30 seconds on the back end?

 

[Jan De Messemaeker]

Hi Natasha,

Sorry, I should have tried first; indeed you cannot enter durations less
than 1 minute and it doesn't count them in the end.
But I DO think modeling manufacturing work in Project is a good idea.

Greetings,

 

[Steve House [Project MVP]]

A project produces a unique, one-off, deliverable. Manufacturing processes
produce a stream of multiple identical copies of the same deliverable.
Project's are closed ended - once the deliverable is produced everyone goes
home and that particular resource pool is disbanded (the world only needs
one Aswan dam). Manufacturing is open ended - you hope your business keeps
on going and your assembly line can produce and sell unit after unit after
unit for an indeterminate period of time.

You would probably be better served by a dedicated manufacturing scheduling
application.

 

[Jan De Messemaeker]

Hi Steve,

This is where your statement is highly incomplete:

Manufacturing processes

produce a stream of multiple identical copies of the same deliverable.

This is what they do in China, but except for some industries most
production in the Western world is now Unique batch production or even
unique products.
This kind of production could be covered very well by Project.
In the early 70s I used to be "specialist" in IBM's production planning
systems and I can assure you that the one for Workshop scheduling used about
the same algorithms as leveling does now - the wording was different but the
logic was the same.

When I look at today's Production planning system like AXAPTA (haven't seen
that much of SAP but it has the same flavour) they require far more
knowledge of cost accounting, they are very complex to learn (don't talk
about steep learning curves in Project before you've seen that) and far more
expensive, especially to introduce into the company.

So it is absolutely logical that people want to use Project in this
environment: as for scheduling it does NEARLY all they need, it is very
cheap and can be learned in days.

And from there on, it is only human that people ask for the few things
Project cannot do in this world - Just in Time scheduling and taking
material availability into account in the schedule. And I consider the
roaring deafness of the Product people at Microsoft, to refuse to even
consider these weaknesses, rather arrogant (but after having spent 28 years
with the other giant in the industry, I know that size makes arrogant).

Greetings,





--
Jan De Messemaeker, Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
For FAQs: http://www.mvps.org/project/faqs.htm

A project produces a unique, one-off, deliverable. Manufacturing processes
produce a stream of multiple identical copies of the same deliverable.
Project's are closed ended - once the deliverable is produced everyone goes
home and that particular resource pool is disbanded (the world only needs
one Aswan dam). Manufacturing is open ended - you hope your business keeps
on going and your assembly line can produce and sell unit after unit after
unit for an indeterminate period of time.

You would probably be better served by a dedicated manufacturing scheduling
application.

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

 

[Steve House [Project MVP]]

I don't really disagree with you except that I do think "classical"
manufacturing still predominates. Yes, a Boeing airliner only looks like
multiple units of the same product to the untrained eye when in fact each
order is so highly customized that a production run could be well managed as
a "project." But steel making, pharmacuticals, petroleum refining, auto
assembly - the list goes on and on - are still based on the classical
assembly line model of a steady stream of identical units without an
identifiable point in time when one can say that all the units that ever
will be produced have been produced. One problem with using Project as a
scheduling tool for that sort of thing is that it is basically designed to
schedule human work on individual unit tasks and you just can't say with any
certainty that Joe will tighten the third bolt on the left back from the
front of the engine in the head assembly on the 3rd vehicle coming down the
line on Tuesday at exactly 10:37am. People trying to use Project overlook
the fact that in a Project environment the 3rd bolt on the 5th vehicle and
the 3rd bolt on the 10th vehicle are two totally separate tasks, completely
isolated from each other and scheduled independently. Even saying an
individual vehicle is a "project" breaks down because scheduling means (to
MSP) placing the task to occur at a precise, definable, single point in the
history of the universe and a single operation in a manufacturing cycle
isn't predictable like that - you can say the bolt is tightened 1 hour after
the vehicle starts down the line but you can't say it will be tightened on
Tuesday, May 16th, at 11:02:00am.

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

Hi Steve,

This is where your statement is highly incomplete:

Manufacturing processes

produce a stream of multiple identical copies of the same deliverable.

This is what they do in China, but except for some industries most
production in the Western world is now Unique batch production or even
unique products.
This kind of production could be covered very well by Project.
In the early 70s I used to be "specialist" in IBM's production planning
systems and I can assure you that the one for Workshop scheduling used
about
the same algorithms as leveling does now - the wording was different but
the
logic was the same.

When I look at today's Production planning system like AXAPTA (haven't
seen
that much of SAP but it has the same flavour) they require far more
knowledge of cost accounting, they are very complex to learn (don't talk
about steep learning curves in Project before you've seen that) and far
more
expensive, especially to introduce into the company.

So it is absolutely logical that people want to use Project in this
environment: as for scheduling it does NEARLY all they need, it is very
cheap and can be learned in days.

And from there on, it is only human that people ask for the few things
Project cannot do in this world - Just in Time scheduling and taking
material availability into account in the schedule. And I consider the
roaring deafness of the Product people at Microsoft, to refuse to even
consider these weaknesses, rather arrogant (but after having spent 28
years
with the other giant in the industry, I know that size makes arrogant).

Greetings,





--
Jan De Messemaeker, Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
For FAQs: http://www.mvps.org/project/faqs.htm

A project produces a unique, one-off, deliverable. Manufacturing processes
produce a stream of multiple identical copies of the same deliverable.
Project's are closed ended - once the deliverable is produced everyone goes
home and that particular resource pool is disbanded (the world only needs
one Aswan dam). Manufacturing is open ended - you hope your business keeps
on going and your assembly line can produce and sell unit after unit
after
unit for an indeterminate period of time.

You would probably be better served by a dedicated manufacturing scheduling
application.

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

The process is a project if the start and end date are defined as one day.
--
Natasha


:


Natasha wrote:
I am using project to map factory processes in order to evaluate
resources
and costs. Some processes take 30 seconds, but I can't figure out how
to
change the duration units to allow for less than a minute. Any ideas?
This
may seem like micro-scheduling, but is necessary for using a shared
resource
pool in a manufacturing setting.
--
Natasha

Manufacturing processes are not projects. A project, by any
definition,
has a start and an end date.

Hope this helps in your world.

 

[Jan De Messemaeker]

Hi Steve,

Just a few small comments.

Petrol refinery etc. are the Process industry, not manufacturing, I've
always been told to make that distinction; And especially in Europe, mass
production is rapidly disappearing (the low salary cost countries take
over).

Assembling a Boeing is not something you "could consider a project" it is a
very typiccal example of a large project. Lookup PMIBOK for the definitions
(unique result, limited resources etc.)

Project is not meant to (only) schedule human work, to the contrary -
leveling works more than perfect when you schedule machines, because at
least you will never be tempted to assign them x% to a task - which is the
halfhearted solution for human work when people want to level themselves and
then wonder why leveling does not generate an ideal schedule from the mess
they introduce.

Greetings,
--
Jan De Messemaeker, Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
For FAQs: http://www.mvps.org/project/faqs.htm

I don't really disagree with you except that I do think "classical"
manufacturing still predominates. Yes, a Boeing airliner only looks like
multiple units of the same product to the untrained eye when in fact each
order is so highly customized that a production run could be well managed as
a "project." But steel making, pharmacuticals, petroleum refining, auto
assembly - the list goes on and on - are still based on the classical
assembly line model of a steady stream of identical units without an
identifiable point in time when one can say that all the units that ever
will be produced have been produced. One problem with using Project as a
scheduling tool for that sort of thing is that it is basically designed to
schedule human work on individual unit tasks and you just can't say with any
certainty that Joe will tighten the third bolt on the left back from the
front of the engine in the head assembly on the 3rd vehicle coming down the
line on Tuesday at exactly 10:37am. People trying to use Project overlook
the fact that in a Project environment the 3rd bolt on the 5th vehicle and
the 3rd bolt on the 10th vehicle are two totally separate tasks, completely
isolated from each other and scheduled independently. Even saying an
individual vehicle is a "project" breaks down because scheduling means (to
MSP) placing the task to occur at a precise, definable, single point in the
history of the universe and a single operation in a manufacturing cycle
isn't predictable like that - you can say the bolt is tightened 1 hour after
the vehicle starts down the line but you can't say it will be tightened on
Tuesday, May 16th, at 11:02:00am.

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

Hi Steve,

This is where your statement is highly incomplete:

Manufacturing processes

produce a stream of multiple identical copies of the same deliverable.

This is what they do in China, but except for some industries most
production in the Western world is now Unique batch production or even
unique products.
This kind of production could be covered very well by Project.
In the early 70s I used to be "specialist" in IBM's production planning
systems and I can assure you that the one for Workshop scheduling used
about
the same algorithms as leveling does now - the wording was different but
the
logic was the same.

When I look at today's Production planning system like AXAPTA (haven't
seen
that much of SAP but it has the same flavour) they require far more
knowledge of cost accounting, they are very complex to learn (don't talk
about steep learning curves in Project before you've seen that) and far
more
expensive, especially to introduce into the company.

So it is absolutely logical that people want to use Project in this
environment: as for scheduling it does NEARLY all they need, it is very
cheap and can be learned in days.

And from there on, it is only human that people ask for the few things
Project cannot do in this world - Just in Time scheduling and taking
material availability into account in the schedule. And I consider the
roaring deafness of the Product people at Microsoft, to refuse to even
consider these weaknesses, rather arrogant (but after having spent 28
years
with the other giant in the industry, I know that size makes arrogant).

Greetings,





--
Jan De Messemaeker, Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
For FAQs: http://www.mvps.org/project/faqs.htm
"Steve House [Project MVP]" <[email protected]> schreef in
bericht news:[email protected]...

A project produces a unique, one-off, deliverable. Manufacturing processes
produce a stream of multiple identical copies of the same deliverable.
Project's are closed ended - once the deliverable is produced everyone goes
home and that particular resource pool is disbanded (the world only needs
one Aswan dam). Manufacturing is open ended - you hope your business keeps
on going and your assembly line can produce and sell unit after unit
after
unit for an indeterminate period of time.

You would probably be better served by a dedicated manufacturing scheduling
application.

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


The process is a project if the start and end date are defined as one day.
--
Natasha


:


Natasha wrote:
I am using project to map factory processes in order to evaluate
resources
and costs. Some processes take 30 seconds, but I can't figure out how
to
change the duration units to allow for less than a minute. Any ideas?
This
may seem like micro-scheduling, but is necessary for using a shared
resource
pool in a manufacturing setting.
--
Natasha

Manufacturing processes are not projects. A project, by any
definition,
has a start and an end date.

Hope this helps in your world.

 

[Steve House [Project MVP]]

As I said, we agree - in fact, I use aircraft manufacturing as an example of
where projects are found in industry in my introductory classes.

Hi Steve,

Just a few small comments.

Petrol refinery etc. are the Process industry, not manufacturing, I've
always been told to make that distinction; And especially in Europe, mass
production is rapidly disappearing (the low salary cost countries take
over).

Assembling a Boeing is not something you "could consider a project" it is
a
very typiccal example of a large project. Lookup PMIBOK for the
definitions
(unique result, limited resources etc.)

Project is not meant to (only) schedule human work, to the contrary -
leveling works more than perfect when you schedule machines, because at
least you will never be tempted to assign them x% to a task - which is the
halfhearted solution for human work when people want to level themselves
and
then wonder why leveling does not generate an ideal schedule from the mess
they introduce.

Greetings,
--
Jan De Messemaeker, Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
For FAQs: http://www.mvps.org/project/faqs.htm

I don't really disagree with you except that I do think "classical"
manufacturing still predominates. Yes, a Boeing airliner only looks like
multiple units of the same product to the untrained eye when in fact each
order is so highly customized that a production run could be well managed as
a "project." But steel making, pharmacuticals, petroleum refining, auto
assembly - the list goes on and on - are still based on the classical
assembly line model of a steady stream of identical units without an
identifiable point in time when one can say that all the units that ever
will be produced have been produced. One problem with using Project as a
scheduling tool for that sort of thing is that it is basically designed
to
schedule human work on individual unit tasks and you just can't say with any
certainty that Joe will tighten the third bolt on the left back from the
front of the engine in the head assembly on the 3rd vehicle coming down the
line on Tuesday at exactly 10:37am. People trying to use Project
overlook
the fact that in a Project environment the 3rd bolt on the 5th vehicle
and
the 3rd bolt on the 10th vehicle are two totally separate tasks, completely
isolated from each other and scheduled independently. Even saying an
individual vehicle is a "project" breaks down because scheduling means
(to
MSP) placing the task to occur at a precise, definable, single point in the
history of the universe and a single operation in a manufacturing cycle
isn't predictable like that - you can say the bolt is tightened 1 hour after
the vehicle starts down the line but you can't say it will be tightened
on
Tuesday, May 16th, at 11:02:00am.

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


"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in
message

Hi Steve,

This is where your statement is highly incomplete:

Manufacturing processes
produce a stream of multiple identical copies of the same deliverable.

This is what they do in China, but except for some industries most
production in the Western world is now Unique batch production or even
unique products.
This kind of production could be covered very well by Project.
In the early 70s I used to be "specialist" in IBM's production
planning
systems and I can assure you that the one for Workshop scheduling used
about
the same algorithms as leveling does now - the wording was different
but
the
logic was the same.

When I look at today's Production planning system like AXAPTA (haven't
seen
that much of SAP but it has the same flavour) they require far more
knowledge of cost accounting, they are very complex to learn (don't
talk
about steep learning curves in Project before you've seen that) and far
more
expensive, especially to introduce into the company.

So it is absolutely logical that people want to use Project in this
environment: as for scheduling it does NEARLY all they need, it is very
cheap and can be learned in days.

And from there on, it is only human that people ask for the few things
Project cannot do in this world - Just in Time scheduling and taking
material availability into account in the schedule. And I consider the
roaring deafness of the Product people at Microsoft, to refuse to even
consider these weaknesses, rather arrogant (but after having spent 28
years
with the other giant in the industry, I know that size makes arrogant).

Greetings,





--
Jan De Messemaeker, Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
For FAQs: http://www.mvps.org/project/faqs.htm
"Steve House [Project MVP]" <[email protected]> schreef in
bericht A project produces a unique, one-off, deliverable. Manufacturing
processes
produce a stream of multiple identical copies of the same deliverable.
Project's are closed ended - once the deliverable is produced everyone
goes
home and that particular resource pool is disbanded (the world only needs
one Aswan dam). Manufacturing is open ended - you hope your business
keeps
on going and your assembly line can produce and sell unit after unit
after
unit for an indeterminate period of time.

You would probably be better served by a dedicated manufacturing
scheduling
application.

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


The process is a project if the start and end date are defined as
one
day.
--
Natasha


:


Natasha wrote:
I am using project to map factory processes in order to evaluate
resources
and costs. Some processes take 30 seconds, but I can't figure
out
how
to
change the duration units to allow for less than a minute. Any
ideas?
This
may seem like micro-scheduling, but is necessary for using a shared
resource
pool in a manufacturing setting.
--
Natasha

Manufacturing processes are not projects. A project, by any
definition,
has a start and an end date.

Hope this helps in your world.