The threading concept in programmingis totally different. Firstly
threads are not predictable in that it is not known when they will
finish and consequently it is not known how much work is in each of
them. Also the objectives are entirely different in that the purpose of
threading is to ensure that each element of computation is given a share
of processing power according to some prioritisation scheme so that the
illusion of concurrent execution is given.
If you want to run tasks concurrently you can do this. You need to
ensure that the total work for all the concurrent tasks does not exceed
the maximum available effort at any moment in time. You can do this by
adjusting their duration as necessary (and moving resource allocations
around on the Task Usage view - although this could end up by being a
lot of work). You can then level those tasks on a week-by-week (or
whatever is convenient) setting.
The goal of having as many tasks completed as possible before some
status date can only be accomplished by completing all the shortest
tasks first because the pool of work available to use is limited and fixed.
Firstly you have to understand that the levelling algorithm is complex.
I normally use Priority, Standard because then the priorities that I
impose are given high importance in the decision process.
In simple terms, for the configuration you outline, Project will scan
through your project to identify each hour in which a resource has more
than 1 hour of work. Having done that, it will attempt to delay work so
that those overallocations are eliminted. So if it determines that
Resource A is on task A and task B for 45 minutes at 14:00 today, it
will try to delay one of those tasks so that that or a similar situation
does not exist. With your settings, it will look at things like the
slack on a particular task in order to determine which task is most
appopriate to slip.
If you don't allow splits to be made in remaining work then Project has
no alternative but to delay the entirety of one of the conflicting tasks
until the task with which it conflicts has completed. It may be the
case that a break of 45 minutes (in my example) on one of the tasks may
be sufficient. That is the effect of the "levelling can create splits
...." check box. If you don't check that, Project will keep all the work
together and move it around as a single chunk rather than breaking it
into smaller chunks which it may be easier to slot into the schedule at
points where the workload is low or lower.
If you have two resources on one of the tasks in my example, both
working at 14:00 then with your setting of "Levelling can adjust
indivudual ...", Project will always keep them together when delaying
the work. If you allow the assignments to be adjusted, then Project may
delay the work assigned to one of them and allow the other to work as
per the original schedule. So resource A could find themselves working
at 14:00 in my example and resource B could find themself on the other
task at 14:00 with his work on the conflicting task delayed to some
point in the future.
In your example, you didn't quote the effort for Task A but maybe that
isn't important. You also don't quote durations so we can't see the
level of effort needed as that will be significant in determining
whether or not overallocations occur.
Task B is split because you have allowed it to be in your settings. One
thing that has to be understood is that it isn't just the individual
tasks that affect the levelling engine, it is the tasks to which the
tasks are linked, the slack a task has and any constraints that can be
applied. So the picture is complex. If you are really interested, you
may wish to look at the resource countour as that may be affecting things.
Let's turn it around. You could accept the schedule thrown up by
Project. Is there any reason why you can't? If you don't like the
split, you could either disallow splitting, or change task priorities
(and level by priority/standard). One of the purposes of the
application is for it to develop schedules based on the information you
give it. It may be counter-productive (albeit entirely natural) to try
to second guess it or to try to understand the minutia of its calculations.
Probably the best approach in practical terms is to get it to produce a
schedule. If you don't like the results, then change task
priorities/durations etc and level again. I find that I have to iterate
to get an acceptable schedule on anything but the most simple projects.
Levelling is probably one of the hardest elements of Project to be able
to do effectively. Hopefully the notes here will help.
