Unwanted duration changes after leveling

[eugene76]

Hi,

I have a multi project MPD file. When resource leveling across all projects
in the MPD some of the task durations change. I cannot understand why this
happening.
Any help will be much aspprecitated. thanks in advance!

 

[Jan De Messemaeker]

Hi Eugene,

When a task has more than one resource and you have the "individual
assignments" leveling option on, leveling can postpone the work by ione of
the resources only, which will change duration of the task.
HTH

 

[eugene76]

Thanks Jan,

my 'Resource leveling Options are as follows;

-Manual
-Day by Day
-clear leveling values before leveling
-level entire project
-Priority, standard
-"level only within available slack--disabled
-"leveling can adjust individual assignment...---disabled
-"Leveling can create splits in remaining work----disabled

still the problem occurs. Thanks again for your time, any further assistance
would be much appreciated.

EM

 

[eugene76]

Oh, I should add,

the concerned tasks that change duration after leveling have 2 resources
assigned, with one using the standard calender, and the other a 24hr
calender, hope this helps.

 

[Jan De Messemaeker]

Hi Eugene,

With so many variables, it isn't easy to guess what exactly happens.
You mention MPD but that is irrelevant since leveling o,nly works on the
open (mpp) files. How it is stored doesn't matter.
I suppose you also have all files connected to a resource pool?
And the files are visible in a master file?
Have you looked at Task Usage - Timescale minor granularity set to hours to
see how the two assignments are scheduled?
Does the master file have the same Calendar options (hours per day...) as
the individual file?
Does the problem occur when you level the file individually?
These are things I would check if I had the file here before me.
I guess it's too big to be sent? If not you can mail it to
jandemesATprom-de.be

Greetings,

 

[Dave]

But you can look at where the resources are working pre and post
levelling and that will tell us what is happening.

If you can tell us the relative positions of the resources work and how
that changes as a result of levelling we can probably give more information.

 

[eugene76]

Hi,

pls allow me to partially ans/clarify your suggestions;

1) Yes, i have all files linked to a common resource pool.
2) Yes, all files are visible in a master file (option 3, when prompted
after double clicking 'resource pool')
3) Not sure what you are referring to when you mention the "timescale
granularity" although in the "task usage" view all resources work is in HOURS
4) Yes, the master file has the same 8 hour days selected as do the
individual files
5) No, the problem does not occur when i open the file on its own and level.


hope this helps, many thanks!

EM

 

[Jan De Messemaeker]

Hi,

Go To Format, Timescale
Set units in middle tier to days, bottom tier to hours.
Now you can see exactly where leveling may have shifted the work of the two
resources.

 

[eugene76]

Thanks Jan,

thanks for the offer of personaly checking the file. Unfortunately, I would
be in breach of the confidentuality agreement i have with my client, so cant
send..

Ok,

I have opened the master file. I will perform the same steps with 2
different tasks (from 2 different projects within the master file) that have
the same problem of Increasing Durations after levelling;

ID: 153
Part A
-selected one of the tasks that has a longer duration than the baseline
duration.
Task 153: / Dur:14d / Baseline Dur: 12d / Lev.Del:0ed / Srt:17.05.07 /
Fin:6/06/07 Gannt Bar ends, then has the "split" symbol (dotted line) for 2
days, then the normal linking/arrow line
-Unlevel selected task only
-no change to the above mentioned fields

Part B
-manually reduce the Duration (14d) to match the Baseline Duration (12d)
**this removes the above mentioned "split" symbol, and reduces the finish
date by 2 days (4/06/07)
-level
Part C
-Dur:12d / Baseline Dur:12d / Lev.Del:0ed / Srt:29.06.07 / Fin:17.07.07
**this moves the task right up to meet its successor (e.g. the 'Linking' line
between the task bars now has no split (as mentioned in part A) and no gap
(as mentioned in part B)

ID: 28 / Dur:61.13 / Baseline Dur:15 / Lev.Del: 0ed / Srt:3.10.07 / Fin:
27.12.07
followed same steps as above with Task 153... All results are the same as
mentioned as above. EXCEPT>> the duration changes back to its original value
(61.13) after leveling.

any advice would be appreciated,

thanks again.

EM

 

[Jan De Messemaeker]

Hi Eugene,

If confidentiality is the only problem, I would have thought that replacing
the task names and resoruce names by their respective ID would solve that...

By all means, I concentrated on the first case.
There seems to be some parameter that forces the finish of the task later
than what it could be taking into account resource availability.
This can be
an FF link
an SF link
an MFO constraint
a FNET constraint
an ALAP constraint
A fixed duration task type

Do note that leveling yields "curious" results when there are FF and/or SF
links.

Hope this helps,

 

[eugene76]

yes, i will consider sending if a few more checks are unsuccessful; (the file
is really big, so it takes a bit of time to delete all of the resource +
project names, etc...) thanks for the offer.

I have read your message, and i can say that these affected tasks are fixed
duration tasks. Haven't chercked all of the affected ones yet but, those that
i have are FS links.

Does the fact that they are fixed duration have anything to do with it? I'm
curious as to why you mention this in the same list as the SF, FF, etc...
links.

cheers,

EM

 

[Jan De Messemaeker]

Hi,

Fixed Duration tasks may have a trailing split when the work is done before
the fixed duration has ended; Project fills the difference with a split at
the end.

 

[eugene76]

Hi Jan,

Some more (hopefully_!) helpful information for you:

1) There are 2 types of resources (**both calenders are unchaged from default)
-Machines (24hr calender)
-people (standard calender)

2) Most, if not all of the tasks that have growing (after levelling)
durations, use a machine resource amongst their assigned resources.

3) A policy that our company uses is that the " percent complete " function
is used in a limited way as follows;
-If a task is finished it is entered as 100% complete
-If a task has started but not yet complete it is entered as 0% complete
**this applies to all of the above mentioned tasks. **this is taken into
account when projects are being created, and it works well, as long as the
work breakdown structure is done well.

3) About 95% of the duration changes are 2 days or less. (about half of
these are 1 day or less)

4) I have not yet (this is a massive file) looked at every single task, but
there seems to be a strong correlation between the changing durations and a
couple of overloaded resources (these represent both calender types as
mentioned in number 1.

thanks, Jan looking forward to hearing from you soon.

Greetings

EM

 

[Jan De Messemaeker]

Hi,

I still want to look specifically at ONE case (say the first one)
What is
-%complete
-Actual start
- Task Type
-Constraint type
?

 

[eugene76]

Task #28 (Duration: 61.13d, Baseline Duration: 15d)
%complete = 0%
Actual Start = na
Constraint Type = FNET
Task Type = Fixed duration

cheers,

EM

 

[Jan De Messemaeker]

Haha!!!
Fixed duration, FNET...
What does Project have to do when the work is done before the FNET date?
Yes, it will stretch the task to meet the Finish date
And it will keep the durartion as set
Perfect, you asked for it, so now you got it.

Is there really, really, a task that in real life that could have a FNET
constraint? FNET?
Hope this helps,

 

[eugene76]

thanks Jan,

by way of background;
The FNET's are automatically assigned to tasks that have had their finish
dates changed during our auto-update cycle. The client armed with new
information about the tasks, enters a new finish date to multiple tasks in a
repository. At the close of the update period, the repository is closed off
and no more changes are allowed until the auto-update cycle is complete. All
of the new finish dates (+ other changes such as resource assignments,
completions) are captured and entered into the project file. Project then
automatically assigns FNET's or SNET's to tasks that have had their finish
dates changed, causing the problems we have been talking about.

Does this sound correct to you?

Is there an easy way to avoid this? (i have just created a macro that
changes all of the increased durations back to the original baseline duration
finish date, as a "Work Around" for the time being)

Bear in mind; If we were to change all of the FNET's to ASAP's this would
result in unrealistic finish dates appearing.

 

[eugene76]

Put more simply,

some projects i am dealing with need (i think) to have the scheduling option
"Tasks will always honor their constraint dates" enabled because when this is
disabled, and the project is linked to a common resource pool that many other
projects share, it results in unrealistic finish dates that are nowhere near
their original dates, due to the fact that some predecessor tasks will
inevitably be entered as finished (entered as 100% complete) at a date that
is earlier than their original estimated finish date. From our discussion to
date, I am assuming that the unwanted duration changes that i am reporting to
you are a result of;
- the constraints (FNET, etc...) placed on some of the tasks
- scheduling options such as "Tasks will always honor their constraint
dates" enabled.

My question is;

Is it possible to set a project file that behaves in the following way;

- fixed durations never change, unless changed manually.
- Tasks always honor their constraint dates.

If so, which settings do i require?

If not, how can i configure a project file to behave as close as possible to
the above mentioned one?

Many thanks for all your assistance thus far,

Regards,

EM

 

[Jan De Messemaeker]

Hi,

Duration will always change when actual work data show a larger number of
days worked.
Task will always honor their constraint dates: I never did anything else.

But I am shocked by the following statement:

it results in unrealistic finish dates that are nowhere near

their original dates, due to the fact that some predecessor tasks will
inevitably be entered as finished (entered as 100% complete) at a date
that
is earlier than their original estimated finish date.

If the predecessor is finisg=hed early, why can't the successor end early?
If reality has changed why should dates still show the original plan?
Why are dates different from the original finish date "unrealistic"? If they
result from actual data, I would say they are more "realistic" than an
original estimate..

We're now leaving the discussion on how Project works and entering a
management discussion.. When real figures don't match the plan figures, you
have to change them... that is what you say?

 

[eugene76]

Hi Jan,

thanks again for your assistance!!! I feel like i am getting closer.
Bearing in mind your comment below, I have a question.

If revised finish dates are entered into the project for various tasks as
new information comes to hand and/or the task is entered as 100% complete due
to it finishing earlier than expected, project will automatically assign
constraints such as FNET's as a result of interdependancies that exist with
the revised task and other tasks.
How can these 'revisions' (changes to finish, and/or % complete status) be
applied to the project without the durations of the tasks changing after
leveling due to the reasons you mention below?

thank you,

EM