Why few of my tasks were pushed too far during levelling

[Hung]

Hi there,
I did not use resource levelling so much, since I could not predict the delay.
I have some tasks linked together into a branch (a feature), and I have many
branches within a tree (a products). And I have some trees like that.
A resource can be responsible for a whole branch. And one resource can take
some branches across different trees. I dont have links between branches, and
between tree. The dependencies set inside the branch only.
But within each branch there are some fixed milestones that I used to set as
dependencies, where the tasks in that branch could not start earlier than
that.

When I use levelling to resolve overallocated of the resources, I saw that
some of the tasks inside a branch suddenly push to a very far starting time
(say in year 2020!) then come back to start on 2006 for the next task which
linked to it .

For ex of a branch:
Task 1.1: Material availability : 0 day, start at day A (eg. 10/20/2006)
Task 1.2: Task AAA: 2 days, linked to Task 1.1 (asap)
Task 1.3: Task BBB: 2 days, linked to Task 1.2 (asap)
Task 1.4: Task CCC: 1 days linked to Task 1.3 (asap)
....

After levelling, for some branches,
Task 1.2 can be pushed to (11/01/2020) !
then Task 1.3 come back to 10/26/2006

I had to remove the predecessor from Task 1.2, then retype the same
predecessor back, then the date will be back to normal again.

Do you have any idea about this issue? Is this a bug ?

Thanks
Hung

 

[Rod Gill]

Remember that a computer has an IQ of zero. Consider also all the
information you have in your head when you manually level resources and then
realise that Project has hardly any of this data! Project can therefore make
only very crude decisions.

If you have all resources assigned at 100% then yes your delays will be
massive, but if you have 4,000h of work assigned, then even working at 40h
per week a levelled resource will take at least 100w to complete the work.

So first ask your resource managers how many hours per week your resources
can spend on your project, then assign your resource at that availability
only. If you have 10h per week and the resource needs to work on three tasks
at the same time, how will you share the 10h/week across the three tasks?

You need to make these decisions. project is probably only doing what it can
based on the information you have given it.

--

Rod Gill
Project MVP
Visit www.msproject-systems.com for Project Companion Tools and more

NEW!! Project VBA Book now in stock, for details visit:
www.projectvbabook.com

 

[Hung]

Thanks Rod,

I understood the basic that we must have somewhat reasonable allocation for
the resources before asking for MsProject to do levelling.
The wierd thing is that regardless of dependencies between the tasks, ie.
Task 1.3 was supposed to follow Task 1.2, Ms Project still pushed Task 1.2 to
be start very late (some illogical years such as 2020, 2039, 2042) then come
back to Task 1.3 in the current year 2006.
If it is required to delay Task 1.2, then why not pushing the whole branch,
including Task 1.3, Task 1.4 to follow?

I suspect some bugs here rather than just the blind logic of delaying tasks.
Or maybe it's because of choosing Priority,Standard levelling method?

Any help is really appreciated.
Thanks
Hung

 

[Gary L. Chefetz [MVP]]

Hung:

No bugs. In fact, it's too simple to have bugs. Just the very blind logic
that the leveling algorithm uses. There's an explanation for the behavior,
but I can't tell you what it is without knowing your leveling settings and
seeing how the tasks are setup.

 

[Steve House]

I suspect you have a lot of manually entered dates, ie, constraints on
tasks. A common trap is to think a "Must Finish No Later Than" contraint
sets a required finish deadline - it doesn't. Look down the left hand
column of the task list, the Indicator column. If you have lots of little
calendar icons, there's trouble a'brewing.

Of course I'm just guessing here, but if I'm right, in your example, task
1.2 needs to be delayed but 1.3 has a FNLT constraint on it. The delay on
1.2 should move 1.3 but the constraint prevails and prevents 1.3 from
moving. But there is no constraint on 1.2 that similarly prevents it from
being moved. Depending on what else the resource was assigned to and the
priorities of the tasks, 1.2 could be moved way out into the future until
the plan shows your resource has nothing else booked, even if it mean it's
delayed for years, all the while 1.3 stays put because the constraint
prevents it moving. The link will show traveling backwards in time, with
1.2 later than 1.3, an obvious impossibility. But using the constraints you
told Project to create a bogus plan so it dutifully followed your
directions.

Like I said, I'm just guessing and I don't know if you used constraints or
not. But hopefully this will give you some ideas of what you should be
looking for.