Calculations not making sense

[snetzky]

I'm in agreement about the regressive thing, but I gotta make a living.
<grin>

Bottom line is, I don't have time to do this at the granularity you
suggest, nor do I see it as being particularly useful, given the
structure of the project. As the majority of the tasks don't fit into
a particular task network, they just have to be done sometime between
the start and end of the project, I'm inclined to identify priorities,
which cranes (probably the most critical resource) are needed, and then
let the supervisors on the floor figure out the people resources and
which jobs to work on. The biggest thing here is whether or not they
are getting all of the work done and can finish it all by the deadline.

I have to admit, Project was not my first choice, and this experience
hasn't changed my mind any.

Larry

 

[Steve House [Project MVP]]

Well, you do need to remember that first and foremost Project is a schedule
development and work management tool, not a resource management tool. Its
function is so that you can go to that floor supervisor and tell him that
Monday night he needs to put a crew of 5 on using those cranes to position
the girders (or whatever) so they'll be ready for the wleders to secure
during the day shift on Tuesday. You don't need to try to tell him which of
his crew to use for the job and for that matter you've probably already
consulted with him as to how many men he thinks it will take to do the job
in the time required, but you do need to be task granular enough to be able
to tell him that the girders will need to be moved Monday night so they'll
be properly positioned to be welded in place on Tuesday. After all, how can
you identify and schedule resources if you haven't detailed out the tasks to
the point that you know exactly what needs to be done and what resources
have the capabilities of doing them? Without that level of detail, there's
nothing to schedule.

Just curious, what was your first choice? AFAIK, Project is no different
from any other PM software in the respect of fundamentaly being a critical
path task scheduling tool.

 

[snetzky]

In a perfect world, that's the way I would have done it. But having to
eat what was put on my plate, I approached it differently. The good
thing was that the parts of the project that had dependencies (other
than start and end of the project) had dedicated resources and were
already planned. My issue was to schedule the remaining work and make
sure that something didn't get missed.

The limiting resource in this case was cranes, so that's what I focused
on in trying to figure out the actual framework for the schedule and
I'll level resources on a shift by shift level.

My first preference in Project management tools is either P3 or
Suretrak from Primavera.

I've used both and while not as user friendly as Project, they both
turn out consistently explainable schedules even after leveling
resources.

Larry

 

[Steve House [Project MVP]]

Even if the limiting resource was cranes (or other machinery) and not people
I don't see how you could schedule them without detailing the specific tasks
that utilize them. But it is tricky to know how granular to make the WBS,
that's a fact. I try to relate it to the idea of a task being a continuous
block of work performed by a resource, even if it involves several discrete
steps. The example I use in my classes is painting the classroom - we need
to move out the computers, move out the desks, remove fixtures from the
wall, blend the colour, apply the paint, and move everything back in. If
the painter and his assistant will do it all, I'd just put in one task
"paint the room," let him figure out the details of when he does what part,
and be done with it. That's one resource doing one discrete thing that
involves several steps. But if we need to schedule people from IT to
disconnect the computers and a team of labourers to take out the furnishings
and union regs require it be a carpenter who takes down the wall fixtures
and a colour psychologist will come in to blend the perfect paint shade and
then the painter comes in to apply it, all of those individual tasks must be
detailed out under a "paint the room" summary task because we have several
resources each doing their own unique set of activities that all need to be
coordinated with each other.

 

[snetzky]

I understand how it's "supposed" to be done, but I didn't have that
option. In a perfect world, I would have done all of the things you
suggest. However, turnarounds are not software projects, and have
entirely different issues. What I find interesting is that on other
project management/scheduling/planning sites where I've discussed this,
the prevailing opinion has been that Project is not the right tool for
turnarounds because it doesn't do a good job of scheduling resources
over differing shifts, etc. This has borne out time and time again.

Frankly, I've never been able to get Project to make any kind of sense
when running a schedule for any kind of project once I started adding
resources, and I wouldn't have used it for this if I'd had a choice.
I've never had as much difficulty with either P3 or Suretrak in trying
to build a schedule.

At this point, I suspect that we are going to have to agree to
disagree.

Larry

 

[Steve House [Project MVP]]

It's intersting you say that because Project's behaviour is extremely close
to the ANSI standard practices for critical path scheduling methodology as
outlined in the PMBOK from PMI. It's not 100%, but the "Guide to the PMBOK"
publication is just about the closest thing you'll find to a design spec for
MS Project outside the confines of the MS campus. One thing that might be a
stumbling point for you is that MSP is designed with the idea that the
schedule of the tasks will be adjusted so they occur when the required
resources are available rather than scheduling the resources around the
demands of the tasks. It is a task scheduling tool, not a resource
scheduling tool, and the work schedule of the resources is normally
considered to be externally determined, fixed and immutable. If the only
resource with the skill to wax the widgets works nights, that's when you
schedule the widget waxing task to place. But if he works days, you
schedule the task during the day. What you don't routinely do is say "We
will be ready to wax the widgets by the end of the day Tuesday and we need
them to be ready by Wednesday morning so Project should tell me to find
someone on the night shift on Tuesday in order for him to work on it." You
can do that as an exception, but it's strictly a manual process when you do
and Project is based on the opposite assumption that the work schedule
follows the qualified resource 99.99% of the time. So in that vein you are
correct in that it doesn't do a good job of scheduling resources over
differing shifts because frankly it doesn't schedule resources at all! Your
resources' schedules are a given, determined by factors completely outside
of the project universe, and the fixed schedule they work becomes an input
into Project as part of the data that tells it when it is permitted to
schedule the work they need to do.

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

 

[snetzky]

I think the problem is that Project is indeed the wrong tool for this
kind of project.

 

[Steve House [Project MVP]]

I don't think its the type of project but rather the mind-set of the way the
PM approaches it and the culture of the organization that's doing it. I've
heard people say over and over "MS Project may be great for THAT kind of
project but it just won't work in my industry." The strange thing is, the
examples that people give as the type of project where it's "obviously" the
perfect tool are exactly the same examples other people give as industries
where it can never work. You contrasted your turnaround project with
software development and yet I've encountered PM's from the software
industry who swear the MSP is impossible to use for *their* special kind on
projects. <LOL> Fact is, it works fine regardless of the industry you're
working in IF you follow generally accepted CPM and PERT scheduling methods.
Every project regardless of industry or subject consists of one or more
discrete physical activities with observable start and end points taking
place over a finite period of time, performed by resources doing physical
work who are available during certain time periods and not available during
others, and that ultimately result in a unique tangible deliverable. IF you
list out the work that needs to be done as activities (I suggest starting
each task name with an action verb to keep it focused on the idea that it is
always a physical or creative activity) and the resources possessing the
skills to do it broken out as individuals groups identified by skill sets it
works out.

 

[snetzky]

I would be glad to take your point if there weren't so darn many people
who say otherwise. Having been through more project scheduling
classwork than I care to think about, I believe I have a pretty good
feel for the principles of CPM and PERT. One of my past jobs was
supporting a team of 10 project managers in using P3. I was always
able to explain to the person I was working with why P3 was doing what
it is doing, and what it did always made sense. I don't think I would
have been able to do that had I not effectively understood PERT and
CPM.

I have never been able to decipher how Project was doing it's
calculations once resources were added to the mix. That may be a short
coming on my part, but frankly, the number of people saying similar
things on the project management/planning forums I read tells me that
Microsoft needs to spend some time in improving the resource leveling
functionality to the point that it's actually usable by more than a few
"gurus".

Frankly telling users they "just don't understand" is not a
particularly good way to make friends and influence people.

By the way, Do you know someone who has effectively managed a
turnaround using Project?

I'd love to be able to gain from their experience.

Larry

 

[snetzky]

I would be glad to take your point if there weren't so darn many people
who say otherwise. Having been through more project scheduling
classwork than I care to think about, I believe I have a pretty good
feel for the principles of CPM and PERT. One of my past jobs was
supporting a team of 10 project managers in using P3. I was always
able to explain to the person I was working with why P3 was doing what
it is doing, and what it did always made sense. I don't think I would
have been able to do that had I not effectively understood PERT and
CPM.

I have never been able to decipher how Project was doing it's
calculations once resources were added to the mix. That may be a short
coming on my part, but frankly, the number of people saying similar
things on the project management/planning forums I read tells me that
Microsoft needs to spend some time in improving the resource leveling
functionality to the point that it's actually usable by more than a few
"gurus".

Frankly telling users they "just don't understand" is not a
particularly good way to make friends and influence people.

By the way, Do you know someone who has effectively managed a
turnaround using Project?

I'd love to be able to gain from their experience.

Larry

 

[Jan De Messemaeker]

Hi Snetzky,

The pronblem with Project's leveling is that it is extremely simple and very
straightforward, but people (and that is incredibly enough indeed a vast
majority) seem to expect it does something different, and even when I
explain, simply don't believe me.

I dare say that I can always explain (what's more, predict) the sequence
leveling puts the tasks in - and that is ALL it does, putting tasks in a
certain sequence.

HTH

 

[snetzky]

I think I'm going to have to do more work with Project before I'm
convinced. All I know is what I've experienced.

Perhaps you're right, the problem is that Project's levelling algorithm
isn't capable of handling the types of situations I was throwing at it.
Bottom line at that point, is that it's the wrong tool for this
particular situation, which is what I said earlier. No shame in that,
but insisting that Proejct is the right tool for project planning
regardless the project is somewhat disingenuous, given the statements
made in its defense.

As I'm not "getting it" as far as trying to get Project to help me come
up with a workable or sensible schedule, I think I'm going to let this
go for now and do the best with what I have.

Larry

 

[Steve House [Project MVP]]

What do you expect resource leveling to do that Project isn't doing?

First of all, all resource leveling does is delay a portion of the work when
several tasks are in conflict. In its simplest form, Joe who works 8 hours
a day is booked Monday at 100% effort on both 8-hour task A and also on
8-hour task B, both scheduled at the same time before leveling. As a
result, he's somehow expected to do 16 man-hours of work during a single
8-hour workday. But he's not scheduled for anything on Tuesday so resource
leveling takes the lower priority task out of those two and moves it to
Tuesday. And that's all it ever does. Even in the most complex situation,
it all boils down to just that simple a shift.

Joe is booked as above and also Bill is booked with him on task B (but only
on B). Joe is booked for two tasks Monday but Bill is only booked for the
one. Joe is overallocated but Bill is not. Depending on your preference
settings as to whether it can split up the work or not, leveling will either
move the entire 16 man-hours of work on task B to Tuesday, moving both Joe
and Bill's work contribution together thus preserving the task duration but
changing its start and finish dates, or it will leave Bill's 8-hours of work
as it was originally scheduled on Monday while moving Joe's 8 hours over to
Tuesday, leaving the start date as it was before leveling but changing the
duration, the duration in such cases where the resources don't work together
extending from when Bill starts until when Joe finishes. In this case the
duration changes from 8 hours to 16 hours, reflecting that Bill's 8 and
Joe's 8 are done sequentially rather than simultaneously.

That's all resource leveling does - delay part of an assigned resource's
work so that multiple tasks are no longer in conflict. It doesn't adjust or
calculate anything else. It doesn't change or diagnose resource assignment
levels so it won't tell you that if your have 3 resources assigned and the
task is taking 3 days and you need it done in 2 days, you need to add
another resource. It won't see you've booked Joe 200% on 8 hour duration
task A but he's only allowed a maximum of 100% so it changes the task from 8
hours to 16 hours duration for you. It won't take the first example above
where Joe is booked 100% on each of two tasks occuring at the same time and
reduce him to 50% on each, doubling the duration of each of them in the
process. Nope, all it does is shift work as a block so that when two or
more tasks are in conflict because they occur at the same time, some of them
are rescheduled so that they no longer all occur together.

 

[Jan De Messemaeker]

Steve,

Let's be clear on this.
90%+ of the users expect the combination of two tasks allocated at 60% to
end after 1,2 days whereas leveling day by day makes it end after 1,6 days.
That is the main reason why so many people stop using leveling.
The answer (as I explained in an other post today) is that assigning people
to nything else is in fact leveling by hand, and oince you start with that
you can no longer expect Project's leveling to properly take over.
Want to level? Only assign the max units, and never anythong else.
HTH

 

[snetzky]

The problem with this is that it doesn't reflect all projects. The
example I'll use is the one I'm trying to do now:

I have tasks in my project that require a crane and an operator and 3
or 4 mechanics on the ground to move a vessel into place.

I am pulling my mechanics from a pool of 60.

Now rather than enter 60 people's names into the system, which would be
silly, since I won't know who these people are on a day to day basis, I
would like to say that I need 4 units of mechanic and 1 unit of crane.
Problem is, that Project will then proceed to schedule my 4 units of
mechanic and 1 unit of crane at different times of the day.

I gotta ask, why doesn't Microsoft fix this? It would seem to me to be
to their advantage in gaining marketshare.

 

[Jan De Messemaeker]

Hi,

Don't convince me.
It has been my #1 request for the past 6 years now.
First some people replied that "Project's way is more productive since it
allows a more free scheduling" - a plane flying without a pilot is what they
consider productive no doubt;
Then along came Server and improvements to the scheduling engine became ever
more rare...

 

[Steve House [Project MVP]]

I'll second Jan's comments whole heartedly but note that your scenario is
not really a resource leveling issue at all. If you have 1 crane (24 hour
calendar) and 1 day-shift operator (working 8-5) each assigned to an 8-hour
task and only one of them is overallocated, leveling can delay the operator
or the crane separately from the other if "leveling can adjust individual
assignments to tasks" is turned on or it will shift both the operator and
the crane together if that option is turned off. But it doesn't know to
replace a day shift operator with a night shift operator if the crane is
overallocation during the day but available in the night nor does it know
that the crane and an operator always have to stay together. Even before
leveling, the above scenario will have the crane running 8 to 4 while the
operator works 8-5. The crane, because of the 24 hour calendar, doesn't
break for lunch while the operator does take a lunch break! I'd love to see
that, the crane working by itself! There's no way for the system to know it
should choose between Day and Night operators in response to the movement of
the hours that task is scheduled on the crane or that the crane can't work
without an operator being present. (And don't forget it's the task that is
scheduled to the crane's availability, NOT the crane that is scheduled to
the task's requirements.) Tasks are always scheduled around the assigned
resource's work schedules, not the resources assigned and scheduled to meet
the task's requirements. The assumption is that tasks requiring specific
skills are assigned to resources posessing those skills and the work will be
scheduled during the times the required resource is available to do it.

You don't need to detail out all 60 mechanics by name. But in most cases
you do need to break them down by shift so you might have resource list
entries of DayMachanics-4000% and NightMechanics-2000% indicating 40 and 20
mechanics on the day and night shifts respectively. Of course each aggregate
resource would have its own resource calendar indicating the hours that that
group of people actually works. Even so, I don't see how any software could
know that the day mechanics and night mechanics are freely interchangeable
and a substitution would even be possible.

 

[snetzky]

I tried that, but the problem is that you then end up manually leveling
the resources because you have to then decide which tasks will be done
by the day crew and then which by the night crew. That really limits
the amount of time that I'm saving or benefit I'm gaining by using a
planning tool. The real benefit of a planning tool is in leveling
resources and tracking costs (which are directly tied to resources).
If the tool won't do both of those at a sufficient level, then I can't
recommend that anyone spend the money to use Project, when there are
other tools that will build Gannt charts much more cheaply and
calculate critical path. There's already a Linux tool that does that,
and it's free!

So let's talk about perfect worlds for a minute:

In a perfect world, the scheduling engine would allow me to input not
only the calendar for a resource, but also allow me to have varying
levels of resource available at different times of the day as well as
during different date ranges.

So for example, if I have 60 mechanics, during the day, but only 30 at
night, I would be able to enter a generic resource called mechanics
with 60 units between 6PM and 6AM and 30 units between 6PM and 6AM and
it would help me identify when a task should be scheduled based on
resource availability (which meets your criteria above).

It would let me identify "Equipment" resources that have a 24 hour
schedule, but should be allowed to "split" time when the Work resource
has a break in working hours. (to address your lunch issue) I thought
about using Material resource in this way, but I couldn't find a way to
enter maximum units available for material resources.

So for example, it would recognize that the resource with the lower
quantity of available units on a global scale is most likely the
driving resource and other resources on a task need to be scheduled
around its availability.

It would default to multiple resources working on a task doing the task
at the same time, and prompt me or allow me to say "you don't have to
work this job simultaneously."

This is what I wish Project would do, but doesn't. Therefore, I stand
my statement that Project is the wrong tool for projects where multiple
resources need to work simultaneously on the same task.

 

[Steve House [Project MVP]]

You're absolutely correct that material resources don't do it. Project
defines a material resource as a consumable, something that is used up by
the task like fuel for your crane or incorporated into the deliverable
itself, like bricks for a wall. So your cranes are not materials even
though they're not biologic entities. Equipment is a work resource and is
handled just like a person.

Project does level resources and it does an excellent job of estimating
resource costs but as I said, what you're asking it to do here is not
resource levelling. You're asking it to manage resource scheduling - do
resource optimizing, which is something quite different from resource
levelling - for you and you're correct that that's not something that it
does. For instance, it flags clearly when a resource is overallocated but it
is silent when a resource is underallocated.

I'll reiterate something I said earlier - the calendars shouldn't be thought
of as describing your hours of operation. They describe the various hours
that specific warm bodies, or a freely interchangeable group of warm bodies,
are present and able to do work. You may choose or not need to distinguish
between the mechanics in your plant, but when the foreman sends one guy to
do one specific action, he sends a particular individual who is there some
hours and not there others. Work on that one task will proceed when he's
there and stand down when he's not. When he's not there, it doesn't matter
if there might be 100 other mechanics standing around - they're not assigned
to THAT specific task and their presence doesn't create any progress towards
that deliverable's conclusion. If work does continue with another resource
picking up where the first one left off, that's actually a separate task.
While you might have mechanics present 24/7, ultimately one job of work
resulting in one deliverable is assigned to a single individual or a group
of individuals who work together as a team. When they leave at the end of
their workday, work on that specific task ceases until they come back on
their next shift at which point it resumes. Project works fine for that
scenario. Where it is more limited is where you have a task running
continuously over a long period with different resources coming and going on
the task as their shifts begin and end. Strictly speaking such an entity is
not a task but an activity (PMBOK 2000, p 197) which should be subdivided
into its component tasks, a task being "the lowest level of effort in a
project," "a..decomposition of the work by the individuals responsible for
that work" (PMBOK 2000, p 209). So if the activity is done partly by 4
mechanics from day shift and continued by 4 mechanics from night shift as
the shift changes, for Project to schedule it properly the activity needs to
be entered as a summary task which is further broken down into its two
component tasks, one task scheduling the work done by the day shift
resources and the second task scheduling the portion of the work done by the
night shift resources. You might choose not to do that or it might be
impractical for you to go into that much detail but that's not due to a flaw
in Project. If you were willing to detail it to that level, many of your
objections would vanish.

Don't misunderstand me - Project does have some real issues with multiple
resources on tasks and there are several areas that need improvment. But
most of what you describe as the problems you're having aren't among them.

 

[snetzky]

I think we can agree that it's not a problem with Project per se, as
much as it's a problem that Project does not fit the needs I have.
Which was my point previously that Project is not the right tool for
what I need to do.

It may be that Project works fine for what it is capable of doing, but
it doesn't have sufficient functionality to fulfill the needs I have
for not only critical path scheduling but also critical resource
scheduling, so I know whether I have enough resources to finish the job
on time.

I don't believe that I'm expecting too much, just that Project cannot
meet those expectations and isn't the right tool for the job. Which is
what I said several posts ago.
Larry