RE: Leveling by ID vs. "Standard"
- From: Jim Rodgers <JimRodgers@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 22 Dec 2006 13:26:00 -0800
I have run out a couple of threads on this forum
to find out why tasks sometimes become split --
even when the "Can Split" flags everywhere are
set NOT to split.
Now the plot thickens.
-THIS- thread is about why does "Standard" leveling
get worse results than the "By ID Only" leveling.
Now I am finding some connections.
Mike Glen, MVP, points out in his tutorial...
"Microsoft Project: 19 – Levelling for Results,"
http://pubs.logicalexpressions.com/Pub0009/LPMArticle.asp?ID=489
that leveling can get different results on different
PCs or on the same PC if tasks or resources are
entered in different order [and maybe for other
reasons]. And he points out that MS is, as one
would expect, secretive about the algorithms they
use in the Project leveling engine. So, these
differences are hard to anticipate.
Now, I'm thinking this is a two-way street. After
talking to MS Support, I am thinking there may be
a leveling "bug" (undocumented feature) in Project
that INTERACTS with the project data, perhaps
via the file data structure.
Here's why:
I get splits sometimes, despite setting them not to
happen. At first, it seemed the splits simply could
not be cleared away by clearing the leveling. NOW,
I find that clearing the leveling sometimes actually
CAUSES the splits! Bummer.
So I wrote a routine that scans all tasks to find all
the splits. I learned that I can kill off the splits (most
of the time) by changing the duration to one minute
and then back to what it was. (I am using Fixed
Units with Effort Driven turned OFF, so resources
are not modified in the process, etc.) Don't know
why, but (usually) it works. While doing this, I get
a message box for every split it finds.
Here's the code:
Sub RepairSplits()
Dim iTask As Integer
Dim vTemp As Variant
For iTask = 1 To ActiveProject.Tasks.Count
If ActiveProject.Tasks(iTask).SplitParts.Count > 1 Then
MsgBox "A split was found in task: " & vbCrLf & _
ActiveProject.Tasks(iTask).Name
vTemp = ActiveProject.Tasks(iTask).Duration
SetTaskField "Duration", "1m"
DoEvents
SetTaskField "Duration", vTemp
End If
Next iTask
End Sub
Armed with this tool, I have been leveling and
clearing and leveling, over and over again. If I
level "By ID" nothing funny happens. But if I
level by the "Standard" method, it -sometimes-
generates splits in about 5 of the approximately
500 tasks. And sometimes, Project will error
out of my "de-splitting" macro because it won't
let me change the duration at all. Interestingly,
I -can- change it from the Project interface. And
dig this: after restoring the original duration,
Project moves that task into non-working time.
Well, actually, it's nonworking time for one of
the resources, but ok time for the other resource.
Could having two resources assigned to the task
be a problem if the two resources have different
working time calendars?
Well, I know I'm an idiot and all, but that can't be
it, can it? Project lets me enter these resources
that way.
Oh yeah. Resources. I am getting an occasional
"contribution" there, too. It's not repeatable enough
for me to characterize just yet, but I have had a
couple of assignments develop special Work Contours
that I did not give them. The default is Flat, right?
(Thanks to MVP Jan De Messemaeker for finding
the first ones in my project for me.)
Being a habitual dumb@$$, I don't really know
the correct way to check for inadvertently mis-set
Work Contours in a project with 500 tasks. So
here's another code I wrote to detect this
aberration:
Sub RepairContours()
Dim iTask As Integer
Dim iAsgn As Integer
Dim vTemp As Variant
For iTask = 1 To ActiveProject.Tasks.Count
For iAsgn = 1 To ActiveProject.Tasks(iTask).Assignments.Count
If Not ActiveProject.Tasks(iTask).Assignments(iAsgn).WorkContour
= pjFlat Then
MsgBox ActiveProject.Tasks(iTask).Name & vbCrLf & _
" has a non-Flat Work Contour in an assignment involving
" & vbCrLf & _
ActiveProject.Tasks(iTask).Assignments(iAsgn).ResourceName
ActiveProject.Tasks(iTask).Assignments(iAsgn).WorkContour =
pjFlat
End If
Next iAsgn
Next iTask
End Sub
From now on I am NOT going to use the "Standard"leveling -- at least not on this particular project. It
seems to cause incorrect function of the program
and damage the data I entered for the tasks and
resources.
What am I not telling? Most of the tasks were VBA-
generated by copying and pasting "model" tasks and
then programmatically editing them to have certain
predecessors, durations, resources, etc.
It would be nice if Project 3000 had an object model
that allowed the user to enter "leveling rules sets" and
even manipulate them programmatically.
That would be way cool.
Does any of this rambling stimulate anyone to mention
similar experiences or, especially, ways around some
of this strange behavior? Are there any MSDN, TechNet,
or KnowledgeBase articles about this stuff? (My searches
have fallen on hard times. MS Searches are not what
they used to be.)
Thank you in advance for the support I have been getting
from the MS Project Community.
-- Jim
.
- Follow-Ups:
- RE: Leveling by ID vs. "Standard"
- From: Jim Rodgers
- RE: Leveling by ID vs. "Standard"
- Prev by Date: Re: Nonworking hours
- Next by Date: Re: Leveling by ID vs. "Standard"
- Previous by thread: Re: Leveling by ID vs. "Standard"
- Next by thread: RE: Leveling by ID vs. "Standard"
- Index(es):
Relevant Pages
|
