Re: Isn't there a "Machine" Resource Type???



Let's just assume that I have finally gotten over my disillusionment about
the interface.

I'll say this now: I am using Fixed Units and Effort Driven is checked, but
only because that was th default. Since Effort Driven does not really matter
in my case, I'm just leaving it alone. If I have to correct an entry error
to resources on a task, I may also have to go back and fix the duration
again. This works, so I will only complain to my dog about it.

I have splits turned off (I think) from the two checkboxes where this is
controlled. I have Auto-Calculate ON and AutoLevel OFF. I have "Leveling
can adjust individual
assignments" checkbox is turned OFF, too. I deleted the more recent files
that cause Project to crash, and I have gone back to the earlier [100%
hand-entered] models that are stable. I created some Macro buttons for
Clear, Level, and a VB Form that displays the last milestone date in the
project (my "answer").

As Jan suggested, I tried to use recurring events, but had some problems --
however, that was using the unstable model. I'll try it again. I assume
that recurring events only work if I assign my humans to be at these
mandatory "meetings" -- so I can prevent work from being suspended across
breaks and lunches. The "tasks" I am trying to simulate must be completed
once started. Using recurring events to simulate breaks, etc., would cause a
split rather than a suspension of work. Since I have splits turned off, I
should get the desired result.

==========

To summarize, in this thread I have asked the following questions and gotten
the following answers:

1. Is there a resource type "Machine" (allocated) in addition to "Person"
(allocated) and "Material" (consumed).

The answer is there is only ONE CLASS used for allocated resources, and you
may use it as either Man or Machine. However, Project is limited in the ways
they may be combined on one task. This is similar to what Tim Pyron
describes in his book when a Foreman is added to a project task to supervise
ditch diggers. Extreme care is required when combining different classes of
resources in one task because Project does not explicitly support it.

Short Answer: "NO, not really;" there is only one class of allocated
resources in Project.

2. How can I keep tasks from splitting?

The answer is there are two ways tasks become non-contiguous: splits (caused
by leveling when resources are overallocated) and suspensions (the
designed-in behavior of Project that allows a task to straddle a segment on
non-working time in the calendar defined for that resource). The splits are
prevented by clearing a couple checkboxes, at least one of which is checked
by default. The problem with tasks crossing non-working time segments might
be worked-around using recurring events.

===========

I am still wondering why certain files became unstable and lock-up Project.
I may never know. There is nothing about in Help, Technet, MSDN, Google, etc.

I am still wishing there were a better way to keep tasks from crossing
non-working time. I should have been able to specify this behavior in the
resource's calendar. Maybe in a future version, eh?

I'll keep an eye on this thread for any additional remarks by anyone. And I
really do appreciate all the input.

Thanks,

-- Jim


"Steve House" wrote:

But Project DOES only use delays in leveling exactly as you say you want.
Leveling never changes the amount of a resource's work nor the duration of
his individual work involvment in the task nor the units that he is
assigned. The problem is that with the default settings it treats multiple
resource assignments as individual entities so you can get the illusion of a
duration change if one resource is delayed while the other isn't. If two
resources A and B are both assigned to 1-day task X and only A is
overallocated, depending on the option settings, leveling can delay him to
the next day while leaving B in place on the first day as originally
scheduled. Since duration is defined as the time between when work on the
task begins and when it ends, regardless of who is doing each bit, the
task's duration shows changed to 2 days. But in fact, when you view the
work of each resource, the duration of A's work is still 1 day and the
duration of B's work is also still just one day, just as before. The
aggregate duration has changed but in terms of each resource's individual
W=D*U equation it has not. All that has really happened is that the two
1-day blocks of work that were originally concurrent have now become
consecutive. This happens if the "Leveling can adjust individual
assignments" checkbox is turned on - to prevent them being separated, clear
this checkbox so that if either of the resource's work has to be delayed
leveling will move both of them together.

Fixed units, fixed work, and fixed duration only applies to what happens
when you edit an individual resource's assignment data or make some other
change that effectively changes one of those parameters. As I'm sure you're
well aware, every linear equation y=mx has one independent variable x, one
dependent variable y, and one constant m. The task type setting allows you
to designate what term in the equation W=D*U is to be considered the
constant, allowing you to arbitrarily pick one of the two remaining terms as
the independent variable you're going to change with the last term becoming
the dependent variable to be recalculated to keep the equation in balance
(and it absolutely positively will ALWAYS be in balance for every resource
assignment, no matter what, unless you disable calculations altogether). It
does not prevent you from changing any of the terms at any time and there's
a set of default behaviors that apply if you manually edit the term that the
task type says is the constant ... for example, if you manually change the
units in a Fixed Units task it behaves as if it was a Fixed Work task.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://www.mvps.org/project/faqs.htm for the FAQs



"Jim Rodgers" <JimRodgers@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BC2681E4-52C1-44F5-8FC9-F0848584EC89@xxxxxxxxxxxxxxxx
Thanks, John.

Yes, I am familiar with "the formula" of Project. What I was trying to
say
was that while Project has this view of the world, my actual task really
is
fixed in all three factors. I am just trying to get Project to deal with
it.
All I want is to schedule the tasks with a leveling process that only uses
delays. I don't want Project trying to change anything except the start
and
finish dates and times.

I'm almost three, but now Project freezes up when I level it.

This is not the first time Project got flakey on me. The more I change
task
parameters, the more unstable the program becomes. It's been a long time
since I've seen software this bad. It bespeaks the need for a complete
rewrite. (In my experience as a software developer.)

Anyway, I will now re-enter the data -- perhaps from a spread*** this
time. This usually fixes it until I start making mass changes by
selecting
multipe tasks and setting new parameters with [right-click]/[Task
Information]. After a few of those, it's off to the weeds again.

Thanks again, John. Stay in touch if you can.

-- Jim



"John" wrote:

In article <6A8BD847-7EB6-4936-BA0B-9BC7EFA705C3@xxxxxxxxxxxxx>,
Jim Rodgers <JimRodgers@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:


I found (maybe, I think) I need to use the Fixed Units type for my
fixed
duration tasks. This is because the "units" and the "work" ALSO are
fixed.
However, the Fixed Units type behaves somewhat better by not changing
what
I've entered into the program to describe my processes. *** I JUST
WANT TO
SCHEDULE these d_mn tasks. Move them forward or backward without
fragmenting
the integrity of the tasks. It's just that simple!

The idea one of you mentioned about using Reecurring Tasks is
excellent. To
get better info on Project, I overnighted some books, and I've been
reading
them. I got the highly regarded "Using..." text by Tim Pyron, plus the
MS
"Step by Step" book. They both seem pretty good.

Now, something funny happens when I Level the project. It takes off
into
the ozone. CPU=100% for ten to forty minutes each time. When it's
done,
there's a discontinuity in the schedule where the next task comes in at
at
6:30AM one morning in the year 2049! I can't get up that early! ;-)
There
seems to be no reason for this.

I'll go ahead and post this now. In the meanwhile, I will try to find
out
what it is that makes Project go crazy with my recent Fixed Units
version of
the project. Maybe it's because I cleared the Effort-Driven box. I
don't
know. Also, I will change my calendar for the humans to use recurring
tasks
for lunch and breaks.

Thanks for the tips!

Looking forward to more discussion. I hope I can pay back the favors
some
way.

Cheers,

Jim

Jim,
Just a couple of comments. In Project you cannot have more than one type
associated with each task. In other words, you cannot have a fixed
duration task that also has fixed units and fixed work. Did you read
about Project's work equation that I mentioned earlier in this thread?

Generally tasks that are performed by a human resource tend to be fixed
unit or fixed work. For those tasks duration varies as the number of
resources assigned or the amount of work is varied. In your case that
sounds like tasks 1 and 3 (setup and inspect). Task 2 is most definitely
fixed duration. The machine runs at a particular speed or it may even
vary according to the programming, but the total run time (duration)
will be fixed.

That said, it sounds like Jan has more hands-on experience with your
scheduling scenario and this post is getting more detailed than I have
time to devote to it, so I will bow out and let Jan take the reign. Good
luck with your scheduling.

John
Project MVP

"Jan De Messemaeker" wrote:

Hi,

I beg to disagree.

Job scheduling programs tend to behave like accounting programs,
talking
more about work in process value and such than about scheduling and
they
become rapidluy much more complex than Project without necessarily
giving
better results.

And those workshop jobs are within the exact PMI definition of a
project
(result, budget, timing) - it's just that you have to schedule a lot
of
them
on the same resources (machines) but isn't that program management?

I'm sorry that an overload of work made that I didn't read this
thread from
the beginning because I installed such a system years ago and have
had to
deal with most of the pitfalls discussed (the two leveling options,
etc.).

Now concretely, I am utterly sirprised at this:

It would not allow me to correct errors in the duration after
that. If I tried to change a duration by editing the task, it
would
just
change it back.

Are you sure you changed duration? I suspect you changed work; than
duration
is reset. Fixed duration can be changed at will by entering a new
value in
duration.

As for the "split" during lunch breaks, I would try to avoid that by
making
Project consider it a true "split". Replace the breaks in the
nonworking
time by recurring tasks (they have leveling priority 1000, i.e. do
not
level, by default; wu=ith the leveling option "levelindg can spli"
off,
tasks should no more span a break.

Hope this helps,


--
Jan De Messemaeker
Microsoft Project MVP
http://users.online.be/prom-ade
"Rob Schneider" <honeycreek2006-guard@xxxxxxxxx> wrote in message
news:OQTYckbIHHA.5000@xxxxxxxxxxxxxxxxxxxxxxx
Jim Rodgers wrote:
Thanks everybody for helping out. I really appreciate it.

I would have responded sooner, but the motherboard fried, and I
had to
transplant everything onto a spare motherboard. But I'm back.

Okay, so I keep changing what it is I say I'm doing. That's
because of
a
client confidentiality issue. However, let me get it a little
closer
with another scenario. This example really is close to what I am
working
on. I am scheduling jobs in a machine shop.

The humans are working in one shift -- with breaks, lunch hour,
etc.,
all
programmed into the calendar for the machinists. They work five
days, 8
hours (not including the breaks). I modified the "standard"
calendar
for
this purpose. The machines are CNC mills, routers, lathes, etc.
Since
these are programmable, each machining operation requires a human
to set
it up and start it. I have one each of a about a half dozen
machines.
The machines run on a 24/7 calendar. A "process" in a machine
shop has
three parts: (1) Setup, (2) Run, and (3) Inspect. I need humans
for 1
and 3. I need machines for 1 and 2. I have defined resources
that have
names like "Machinist," "Master Machinist." "Router," and "Lathe."
So
each process would be close to this example: An typical process
(three
tasks) --

Task #1: Setup
Fixed Duration = 30 minutes
One Master Machinist
One CNC Mill

Task #2: Run
Fixed Duration = 30 minutes
One CNC Mill

Task #3: Inspect
Fixed Duration = 10 minutes
One Master Machinist

These tasks are linked directly with Finish/Start Links to form
one
"Job"
in a "Job Shop." Next, I string together all the jobs using
"Routings."
In a machine shop, there is a list (the routing) for each assembly
they
make. The first process is where they take a bar of stainless
steel and
whittle it down somehow. The next process in the routing says to
drill
it this way and that way. The next process perhaps mills a
surface onto
the object. And maybe there's a final process where they put a
finish
on
the non-milled surfaces. etc.

So, let's say I have to make anywhere from one to fifty EACH of
fifty
different assemblies. For each assembly, I create a project path
of
processes (three tasks per process as above) in series with
finish/start
links. One path for each assembly. Some assemblies are more
urgently
needed, so I raise the priorities on all the tasks in those paths
.


Loading