What to do? my Enterprise Resources aren't people.

[JackD]

JackD I think you may be right but I am in a similar
situation to you as I haven't found anything.

Actually, the situation I described was what I thought your situation was.
My schedule changes slowly and hourly updates would be meaningless. However
I do have a background where we used to have to deal with very expensive
machines.

Concurrency is the most vital part of what I need in terms
of scheduling and capacity planning, I can't stress enough
how important expiditious status updates are. How concurrent?
daily would be fine really but DAILY means once or twice daily
updates of hourly values per task. Unfortunately
the Project product documentation has other focuses but so far I haven't
really seen anything that says the speed of Project or ability
to process that kind of frequency is the deal breaker.
There are warning signs however.

Anyways I'm just trying to mimic our shops process flow.

Barcoding/scanning of operational status has been tried
here and failed miserably. What our people understand and are
disciplined about is going to a website for the stuff they need
and thoughtfully updateing what may be required of them.

I'm trying to find a middle ground. Coding direct Project Updates
would allow customization that could exploit handhelds/our kiosks/
Numeric Controller output, basically anything; but there is even less
information out there about writing such Updates as there is about
setting up Project server. Project Server is a near match to our needs
as far as I can see, but it would require our Project Managers to
develop a flow as far as cycle time is concerned. We could live with that as
long
as the Projects are current to a known point and not a week out of
date.
When I say hourly I mean Joe works 2 hours on TaskA,
5 hours on TaskB, 8 hours on TaskC. in a 10 hour shift.
That makes up his day. Then the afternoon guy comes
in, Repeat.
Both these guys may update their actuals at lunch, after work, the next
morning
etc. upon logical completetion etc. The point is there is a natural flow to
it all
and that flow is, as I have always maintained, the way it really happens.
See Joes 2 hours on TaskA may have a much great significance than 40 hours
spent elsewhere. This 2 hour segment may have been because he completes
just that little bit early so the window of oportuntity presented by that
enables
a cascading effect of MORE optimal decissions to be made when juggling
resources.
It dosen't take much before big gains are made just because we are able to
present
the fact that

Q.
"Hey guess what Joe's done!!!" Isn't that great?"
A.
"Sure is..,glad we found out about it now. We can....!!!"

The superintendent may be asked to help manage a variance in a production
plan.
When this situation comes up the key players or bottlenecks are most likely
known. Mentally; candidate tasks are already being considered as victims for
delay
All these decisions are based on a good knowledge of the MOST asked question
in any custom manufacturing environment.

"How much is left?"...(on that task)

All I want to do is provide a means to get the response to that question
into Project.
Truely the problem is as simple as that. But as of right now a few simple
concepts
or configurations are missing.

I wrote earlier


Well it didn't get said....but Guess what!!!!! there is a page in Project
Server
called Adjust Actuals that provides an interface to apparently do just that.
However mine dosen't seem to be working and that is a very common
issue.(Googled)
Maybe I can figure it out?

So truely I agree with you but I've been looking very hard at the solutions
that are out there and really nothing offers much beyond what Project
does. Be warned hundreds claim that they do.

I find this rather hard to believe. I would think that there must be some
credible production scheduling software out there.

Have you ever devised a VBA Macro that bulk updates from a CSV
Actual Work, Work Remaining?
50 projects in one Master Project. Enterprise Resource Pool

No. I don't use project server on a regular basis.

-Jack

 

[John Sitka]

If you come in contact with one please post it here.
I would be very interested in seeing yet another one.

 

[Gary L. Chefetz \(MVP\)]

John:

How much experience do you have with the tool? It seems to me that you're
jumping to conclusions without the foundational knowledge in the tool that
you need to make such judgments. Project and Project Server are definitely
not production control tools, and they weren't meant to be.

In most project environments, weekly measurements are adequate. In some
environments daily updating is required. Measuring progress on a
near-real-time hourly basis is flat out impractical with the tool. I suggest
you think through the nature of your hourly/daily sensitivities. In most
manufacturing businesses where I've deployed the tool, when we analyze these
sensitivities we generally find that these are "event driven." Analysis
generally reveals that capturing these events is often very doable using
Project and Project Server because they typically represent a small subset
of what otherwise can be tracked comfortably on a weekly basis.

You might consider some expert assistance with your suitability analysis.

--

Gary L. Chefetz, MVP
"We wrote the book on Project Server
http://www.msprojectexperts.com

-

 

[John Sitka]

I am extremely new to Project.

You say I'm jumping to conclusions.

Really; the only conclusion I've jumped to is that the fundamental
extension of Project to Project Server is not as linear as I hoped.
This major issue I've been struggling with is that resources have
to have logins, I have pointed out why this is flawed in my case, and
also that it is extremely obvious as a thought experiement why it could be
flawed for many situations. If you disagree that is fine, but I believe the
idea stands up to the highest strutiny and is not trival. That is my
conclusion.
What do you think the time span of investigation of that condition and
subsequent conclusion should be before it is not considered a hasty one?
The work around as has been discovered is to let the machines be users.
There may be others, as it is a fairly complex set
of distribution rules in the Server. Are these distributions the ones I
should call in a professional to help with?

You say Project and Project Server are definitely
not production control tools.

Why is this?
I have seen no limitation yet that would suggest that; can you explain them?

I suggest you think through the nature of your hourly/daily sensitivities.

Please Gary this is what I've been focusing on and giving examples of,
it seems you still can not make the leap in thought to hourly
constrained finite resources. That's fine if it is what you know,
but realize I will assume they differ in no way than weekly, monthly or
yearly constrained resources. They are merely "in use" or "not in use",
If you could tell me "Why" there is a difference it would be of value.
Merely saying you need help in your definitions or skills does nothing to
explain this mechanism. Or the arbitrary rule that Project only functions
well
in weekly chunks. That speaks of simple inefficencies in usage, a key
component
of which is the updates of a broad collections of actuals. I submit that
once
timely collection is accomplished Project and Project Server definitely are
production control tools, albiet it not sophisticated rules based ones.
Yours is obviously
a dissenting opinion but there is no evidence of why that timeliness will
not elevate
the functionality of Project.

You mention "weekly" often, I would think that the "softness" of one day
vs. seven would be literally transparent to a rollout such as this.
The computer dosen't care about weeks etc. everything is in minutes anyways
so I don't understand the arbitrary constraint of a week. It seems you
"think
weekly" and have had success doing so, you are therefore in the enviable
situation of "thinking hourly" better than anyone.


Thanks

 

[Gary L. Chefetz \(MVP\)]

John:

I think you're misreading me. Project is good for tracking everything that
leads up to delivering a product to the manufacturing line; once on the
line, it's no longer an applicable tool unless what you're building on the
manufacturing line is a custom, one of a kind product. For instance, a radio
or television transmitter, although using many premanufactured components,
is generally a one-of-a-kind build. For widgets, on the other hand, that are
spit out in mass production, it doesn't apply. This is where a manufacturing
control system takes over.

Out of the box, Project and Project Server are built for and expect to
receive human input for progress reporting. If you want to write your own
front-end to automate tracking data from non human sources, the open
platform allows you to do this. My point to you about
daily/hourly-sensitivity is that you may or may not need to know where
everyone and every piece of equipment is on a day-by-day an hour-by-hour
basis, I'm suggesting that you examine this more closely and look at what's
really important to driving the process. It seems to me that you may only
need to capture specific change events to accomplish the level of tracking
you think you need on daily basis without overlaying this requirement on the
entire project. Typically we see these manifest as "something started" or
"something finished." When you identify and cull these from the reporting
stream, it may be very do-able to rely on human input for this.

So if resource Joe, reports that I finished the task, then the PM can safely
assume that the equipment he was using to do the task is also finished and
available for the next assignment. Now, if that is happening on an hourly
basis and you need to redirect the resource to the next task in a couple
minutes turnaround, you're using the wrong tool. If you're telling me that
you can live with having that redirection occur the next day, you can use
with this tool to craft a workable solution without coding.

You've been using construction metaphors while referencing a manufacturing
process, so I don't have a clue what business you're in or what you're
trying to track and without this knowledge, it's difficult to be more
specific.

--

Gary L. Chefetz, MVP
"We wrote the book on Project Server
http://www.msprojectexperts.com

-

 

[John Sitka]

Thanks for the reponse Gary.
misreading, more like, I'm misleading.

Construction metaphors were used to express the fact that there are a whole
group
of operators available with a limited number of capable machines.
Even at this level, a very simple one. The litmus test of resources as
people fails.
As a machine "wrangler" if you will, would be the one who would identify the
onsite
requirements of those machines (our resources) and thus free them for use on
the
sebsequent tasks.

I am in a concurrent engineer to build environment. We build custom tools
that build the
widgets. Everyone is unique and is a project in their own right and very
dependent on the limited
set of speciallized machines to perform tasks on each project. Thus hourly
resident
or machine time for each project is scheduled very tightly in a 24/7
environment.
These projects also may have build time that ranges from 8 weeks to 2 years

I mentioned this here in response to one of your directions

Stop worrying about equipment as
resources

This I don't understand that it has everything to do with why I'm using
project,
all the rest is fluff. We can always hire more people, we can't buy,
install
or subcontract,
more equipment at the drop of a hat. It costs millions of dollars.
Deadlines
on the
product these machines produce are in a constant state of change, it is a
concurrent
engineering/build to order situation. If our customer has an engineering
change that gives
us more time to complete a project but it also means more tasks and a
reordering of tasks
within that project.
A customer may also purchase premium time which means half way through a
production plan
ever more resources are channelled earlier to that project.

So indeed every manufactured entity is a custom one of a kind project.
Days gained are vital to our success. These days are made up of hours.
Days can be lost because of a missed window of opportunity only an hour long
due
to confounding factors and not having a detailed enough view when the
decisions need
to be made. It sounds caotic and it is. But things get dropped, broken,
changed, explode.
Steel fails under extreme pressure and needs rebuilding, replacing.
Outsources make catastophic mistakes because of misunderstanding. etc.

You mention I don't need to account for every piece of equipment, but that
is the furthest
thing from the truth. These resources demand the highest of accountability
as they are
not replaceable or expandable. They are finite in the purest sense. Other
tasks involved
in our production are not so inflexable, people, for example operators of
the equipment,
we can always get more of those if needed, but they never are in short
supply because
the critial tasks are always bound to the scarce machines and the wait
states of
successors are also largest on the tasks with these machines assigned as
resources.
Thus the requirement to optimize the timeliness of our actuals reporting and
getting them
as soon as possible into a place where our Project managers can reevaluate
all projects accross
the enterprise. I agree that an abstraction to wider time spans or task
units is possible but we have
had that in the past. A clerk for example would wander around with a
clipboard and inquire
as to the status of tasks that took up machine time. He would then go and
update Project actuals.
This was by all accounts arcahic, especially considering the sophistication
of our artisan mutil tasking
machine operators.

It truely is such an easy model to understand once you see the bridge
example for what it is
The bottleneck in the construction of many bridges is the limited number of
earthmovers.
If we had an unlimited number of earthmovers the projects would get done
much quicker.
but we don't so each task has to wait it's turn before it gets it's needed
earthmovers. If
the Boss man can't let the Project Manager know that the earthmovers are no
longer needed
on a certain task they can't be returned to the pool and then reassigned as
quickly as possible.
Or the opposite, we need extra time with those earthmovers. If one
abstracted
this earthmoveing task to an outsource then we ask Bossman when he is done
each task and he replies, we move on
but there is no impact to our scheduling of the outsource contractor's
resource contention. He handled it.
It was invisable to us. But as a company unit our machine resoiurces are the
reson for being and they drive
all we do, every task is dependent on their availability. Just like the
Subcontracted company is dependenent
on their earthmovers. Bundling things up is nice and tidy no doubt but it
serves no purpose in this case.
The whole operational mechanism or schedule or human intelligence needed to
put together or revise Project Plans
is solely dependent on the timeliness of these actual declarations that
define whether a resource is free
or not. I simply need that information as quickly as possible then we have a
more than adaquate
and highly accurate Production Plan.

The true converse arguement of what I've said is that the schedule dictates
what should get done
and all adhere to that. That is the machine is scheduled to work 8 hours
today, we would not expect it
to be 10 hours. But custom is custom, there is no historical knowledge of
why 8 hours is more accurate
than 10 in this CASE. Honestly the root CASE has probably changed. Our
customers often come
to us and say I really need you guys to change this a little bit but I still
need it by such and such a date.
That of course costs money but it also causes havok with Production Plans,
stop at a certain task, re-do some
stuff then put it back on the machine in some other Projects slot. Thus the
flexability of the reporting of actuals
needs to be timely and dynamic. So a new plan and schedule can be evaluated
(leveled), for all downstream projects

So for all the long discourse in these threads I merely want to distribute a
task list and allow
a Project Manager to evaluate it based on the most recent submissions by
those in charge of resources.
We have come to the conclusion that there is no way for Project server to
allow a resource to
exist that isn't capable of logging in. I will deal with that and have my
responsible parties assume the role
of the vital resources in an iterative pattern, they will report on behalf
of the machines. I'm not happy about it;
but it isn't such a leap and truely the login/logoff will be the headache
they experience.
I also realise that there may be some concerns about flow or publish timing
The Prohject Manager will be working
with but these I have pointed out have not made me run the other direction
because none of
them seem to fail. I simply need to optimise the timeliness of the reporting
now in the initial
rollout as it is the limiting constraint on the effectiveness of the whole
implimentation.

I have not seen it demonstarted that Project can not do this other than the
conceptual
hurdle of putting the updates in the proper hands thus exploiting Server the
way
"I" think should be a natively supported configuration.


So what's the question?

hee hee

at the moment it is how can I get granular control of the Update Actuals
screen in PWA?
I'll turn my RESOURCE responsible individuals loose on that once I can get
it
to work for even the Administrator. Do the editable fields turn white when
edits are permitted.
Under what conditions?

PS
You mention Joe finishes his task and therefore we assume he frees up the
resources.
True but Joe may have many tasks at once, (sorry Joe that's the real world
of automation). I expected Project server to allow me to provide a unique
user experience to Joe in which he could handle anything in the domain of
Joe.
But as has been discovered over this last week that is not available and I
still believe
it has devastating impact.

 

[JackD]

John,

I'm going to make some generalizations here so bear with me.

1) Project is a slow tool to update. The turn around time from when people
post status to when the project is updated and published is not conducive to
hourly updates. This is by design. Project managers want to be in control of
the update process (recieving the updates, checking or validating them, then
finally updating the schedule with them and finally publishing the results)
so there is not the sort of real-time update that would be useful in a
production environment. Generally a weekly update is sufficient for the
typical project user. If hours are important then this reason alone would be
enough to leave project and move to a different tool.

2) Project's resource management capabilities are organized around the
individual rather than around machinery, teams of resources or materials. If
you look at the history of project you will see that even handling resources
is something they are just getting a handle on. No doubt by project 2012
they will have heirarchical resources and the ability to designate that a
task can not begin until all the resources assigned to it are available.
However at the present they still can't handle these fundamental things.
Once again, if you have need for these capabilities, you will want to look
elsewhere to see if there is anything better.

3) Project Server is a rather complicated product. It has a number of
capabilities and a wide variety of possible ways to implement it. Gary is
quite right that a careful evaluation of what you require and then time
spent with someone knowledgeable about Project server to determine what sort
of process is best is almost a necessity. You can get some information from
this newsgroup, but a few hours consulting with someone who is an expert is
likely to be more productive. I am not an expert on Project Server, but I
know enough that I'd not hesitate to find someone who is an expert to help
me out.

4) With a bit of code and some ingenuity you can make project and project
server do a wide variety of things that it can't do out of the box, but this
is not the job for a beginning user. And once you get it to do what you
want, you need support for your modifications/customizations. Consider
carefully the development/testing/support costs of a custom solution.

-Jack

 

[Gary L. Chefetz \(MVP\)]

John:

Your statement captioned below, is a clear indication that Project and
Project Server out of the box is the wrong choice for your environment. To
get to this level of precision, you'll need to add a lot of customization to
the product consisting of a front end appropriate for a shop floor. Yes, the
core engine and functionality of Project appears to do the job, but not
quite so microscopically, at least not in this iteration of the product.

"Days can be lost because of a missed window of opportunity only an hour
long"

Sounds like you need an electronic alert whenever a machine is switched off
and an alarm bell to sound after so many minutes of idle time.

--

Gary L. Chefetz, MVP
"We wrote the book on Project Server
http://www.msprojectexperts.com

-
news:[email protected]...

 

[John Sitka]

JackD

1.) updates are instantaneous on my test environment. With what conditions
do the updates slow?

2.)Project itself was fully conversant in the concept of resources as
machines but Server has dropped that notion.
You showed me the work around for that.

3.)The complicatedness is not as great in our situation as all the
supporting products are already in place.
I only need to tap into a very small aspect of what Project Server has to
offer. Unfortunately it is
quite a challange to develop the understanding about where to look for it.
Once again the fact that
resources MUST be users is one of those tricks in the thought process that
has no outlet except for
here. The documents give no indication that is the way it is other than a
defacto assumption based on example.

I heed your warnings, but truely until you go shopping for such software
and really investigate what it does
for you the pickings are very slim. My requirements are very specific and
narrow. This is not what most
of the industry is geared to sell you. Project Server presents and
opportunity to tap into an already
established user base and add a distributed update mechanism that increases
concurrency.
I am prepared to present adjustments to the users as far as real time
interoperability, but I need
to see the product in action first before I can claim to no the limits.

I'm sure it is frustrating to you and the other skilled folks here that my
needs
are obtuse enough to make Project seem like an unlikely candidate. I tried
to
show by simple examples but those didn't seem to help much. Discussions on
those
examples would have been the fodder for discussions in my company as
generalizations
don't work here very well.

So far when I ask the vendors of other products not the pure simulation ones
but the actual finite schedulers
what their product does other than Project all I've seen is some very nice
rules based resource assignment
constructs. However those in and of themselves demand a high level of to set
up and maintenance
into the future. The optimization/allocation algorithims are diverse but at
the core they don't provide
much more to a hands on Program Manager than leveling. Things still turn red
or dates get pushed,
Steve House sums this situation up well in much of his writings.

I truely appreciate the help and direction I have found in this thread.

J.

 

[Michael McGinley]

Question:
Why don't you assign an individual (or 2) to use Project Professional with
the necessary permissions to update the work resource information?
Sorry if this is way off.

 

[John Sitka]

It's not way off in the least Michael.

Just need two questions answered if you could?

Can I restrict the edits that an individual can make on a resource by
resource basis?

Will my Enerprise Manager be flipping out because everytime he wants to make
changes
the project is read only?

Thanks

J.

 

[John Sitka]

Your statement captioned below, is a clear indication that Project and

Project Server out of the box is the wrong choice for your environment.

I'm just asking for why do you think so? I need specifics. Your experitse
in explaining them is what I hope for. I believe you, but I need
to be able to explain it to the people who pay me.

And I think you don't follow the implication of the "days missed because
of an hour." This is solely a human failure when evaluating opportunity.
Or reassigning resources. How they interpret the playing field in front
of them, often in error but that error is reduced as we become more
up to date.

the product consisting of a front end appropriate for a shop floor

The front end is fine in PWA, aside from the obvious "equipment as user"
requirement.

Gary you have focused on something which again is a question of degree.
With no explaination why it won't work. It may change that I only need
updates
once a month, but the mechanism is the SAME.

See the difference?
Think on the bridge construction project
Think on the desire to capture availabilty

My core functionality will be that the folks responsible for the resources
can freely contribute their status to the Project. Spread that across many
resources, many projects and voila a fairly concurrent model. And yes
updates
will be coming in all the time; maybe every minute;
but it isn't a single resource making minute by minute updates,
It's the enterprise, this is native support obviously, there is no timing in
when
resources ARE alllowed to submit updates. It is a continuous stream no
matter
what kind of rollout, our project Manager will know this, he
can push the run rules button often if needed it won't kill him.
What I ask of you is will it kill the implimentation?

It matters not in this discussion how quick the updates are.
Hourly maybe required but often it may only be weekly, I could easily say I
don't know yet. But I am trying to plan for "very frequently".
Non of the contributions have said "Why it fails"
Just that I don't understand what I'm doing.
If you would say something to the effect of
" the XML stream utlized by PDS has a residence latency of half hour which
can really mess things up"
That is something I can use and understand.

Also remember we are only "MANAGING the VARIANCE"
once set up and running.

Do your rollouts fail as soon as a Project Manager makes a series of rapid
requests. I doubt it, but please tell me if they have, I'm the one hung up
on a desire
for concurency but don't build more into it than it is. I want people
reporting frequently,
can you specificly define the limit of this frequency? Can you express
why Project won't work at that frequency.

A brief explaination of Bossman in the construction
example is a great place to start.

So Bossman flys over the construction site
He lands gets his laptop and updates his actuals.
3 bulldozers have finished their assigned task but 2 go over their task
assignment by
what he guesses will be 4 hours. A later flight confirms this.
5 hours later he updates again actual work was work + 4 hours extra for
those remaining
2 buldozers, remaining work is now 0

Is this scenerio inherently broken? And why would a weekly update solve it?
See, same mechanism but you are telling me that the weekly one is better.
Why?
I see the weekly one as handicapping the ability of our Project Manager to
make good decisions.

 

[JackD]

Just a couple of clarifications:

JackD

1.) updates are instantaneous on my test environment. With what conditions
do the updates slow?

When you have to have a person log in and accept the updates. Whenever a
person is involved it will slow things down.

2.)Project itself was fully conversant in the concept of resources as
machines but Server has dropped that notion.

Didn't drop it, they just didn't implement it.

-Jack

 

[John Sitka]

Thanks

Just a couple of clarifications:



When you have to have a person log in and accept the updates. Whenever a
person is involved it will slow things down.


Didn't drop it, they just didn't implement it.

-Jack

 

[Gary L. Chefetz \(MVP\)]

John:

Yes, the system will support the Bossman sending the updates with that
frequency providing that they got accepted and processed extremely
expeditiously.

In the current amplification this is a manual process, that means you need
everyone running project plans at the wheel constantly. Plan wranglers as
you'd likely have it.

The current architecture is inherently slow when high volumes of data are
pushed through it. You can control latency through some architectural
tricks, but if your process is vulnerable to a processing delay of up to
several hours, it ain't worth the risk.

Your answers to the questions in the previous post are no and yes.


--

Gary L. Chefetz, MVP
"We wrote the book on Project Server
http://www.msprojectexperts.com

-

 

[Mark Carde]

Ryder has a very good system for managing resources (trucks/equipment) in
this manner. You may want to talk with them.

But with MS Project why can't you just give the appropriate person the
ability to adjust actuals for these resources and a Nextel phone to
communicate directly with the operators to record the time.

That helicopter stuff is a little too expensive and since the trucks can't
drive themselves why not ask the operator if the truck is done or not.