Some key points here
->16 hours of data management is going to occur over this 4 week period, but I'm not sure when.
Put it at the end of the 4 week period. If you are not sure when, then you also do not care when.
And even more importantly, you do not know that data management must be completed before any other
task.
See the abstraction in the logical model here. You know that at some point somewhere along the 4 weeks
some data management will get done. Where exactly segments (divide it into as many imaginary bits as you want)
of that task are going to occur, you don't know, so just accept that you do not know this, and leave it at the
resources discretion when to do data management. But require them to record actuals when they do that work.
The reason here is obvious. Say you have a project due tomorrow but the final task is datamanagement and there
is 24 hours left on it. that's 3 days. Your resource says Oops, I did that along the way over the last 4 weeks,
sorry I didn't update it.
The reality is the first day right out of the gate your resource DOES DO some datamanagement.
There is nothing preventing him/her from recording actuals against this task. No matter how far in the future it is scheduled.
You can even train them to give you their best estimate of remaining data management say half way through the project,
or everyday which is best or better best is when one of the three tracking rules kicks in.
On task completeion
On task change
On end of shift
Then you can see that their latest estimate combined with their other work load will result in an unfavourable
delay in project completion. And you get up to date budget cost stuff. But please always try and differentiate the dynamic
piloting and traking in Project server from the reporting/auditing aspects of what you want from the product. It's almost like
you need to think differently about the two parts. Estimates vs actuals will always fall out of the act of planning vs tracking
and that is all you need.
Ok so what if you have continuous projects of indefinite duration and an unknown net quantity of work. A running project or a
manufacturing
type situation. Well again apply the concept of abstracting tasks into logical discrete units. Ever 4 weeks plan a task of 16 hours
datamanagement.
at the end of a four week cycle. As time moves on the PWA resource will see a persistant data task at the top of their sheet that is
overdue if they did
zero datamanagement. Tell them that it is their job to evaluate that task as being within the "time chunk" of applicability.
If it is no longer a slot that serves any practical purpose because we have moved on to the next chunk.
Drive the remaining work to zero and record data management on the next one that will appear somewhere down the task list.
Ok, convinced of the importance of understanding what an abstracted idea of a task can do for you, Now about this putting the task
at the end of a project
business. Well it works because you are going to allow task splitting.. Where does the actual work recorded against the data task
end up after you update the status,
there are various options for how to handle it. move it back to status date, etc. the dreaded calculation options.
The only hurdle you have is the PWA user has to have knowledge that these rouge ongoing tasks, part of what they do for a living are
their responsibility
to seek out and record against. It's a simple pattern, not difficult to figure out.
That kind of addresses your point . 1) PWA is going to tell resource X to spend 3 hours on this task on a specific day.
Edumacation, routine and disciple.
They have to be in there somewhere
Not to be too harsh with point 2) and 3), ..... but "yeah so".........
change the stop lights and or filter out the ongoing type tasks.
However, Project Server changed all that that. Now we have a tool that can be a fundemental part of the work process.
Yes indeed but not everyone sees it as profoundly as that. I think it is the most meaningful thing Project brings to the table.
Microsoft themselves might have missed the significance when they did not include an level of resource ownship at the reporting
level.
That is, I will report on behalf of other resources as their agent. One would think that limits they came up against were desktop to
enterprise convesion
ones and datamodel issues. But after reading the documents, scenerios there isn't even a hint that the concept was even thought of.
To bad, it is crucial.
Jan,
I understand that assigning 10% to a task like "data management" may be causing the problem. In reality (and we use Project with
Project Server and timesheets are completed on a daily basis ), I'm not interested in assigning 0.5 of an hour per day on data
management. In practice, I want to have a budget of 2.5 hours/week and in truth, I don't really care when it is done during that
week. Using the example, what I am trying to plan is that 16 hours of data management is going to occur over this 4 week period, but
I'm not sure when.
If I move away from my simplistic example and to the real world, we have a number of overhead tasks on projects - one being the
Project Manager himself, and another being QA, etc. I've always scheduled these as fixed duration tasks with a low assignment rate.
For example, I might have 120 hours of project Management on a twelve month project, 150 hours of QA. These are continuous, on-going
tasks which need to be correctly budgeted and scheduled.
But if I follow what you are saying, this is probably a really bad way of doing it - from a budget management and schedule
management perspective. What I really want to do is to say "Resource X can spend 3 hours this week on this task".
Any suggestions on how this is best implemented?
One thought is that I set up these types of activities as recurring tasks - i.e. a weekly task of say three hours. But this has
downsides. 1) PWA is going to tell resource X to spend 3 hours on this task on a specific day. 2) If he doesn't do it, my
stop-lights are going to go yellow/red everywhere, and 3) we use SPI as a Metric which may result in incorrect escallation of
delayed tasks.
I guess what I am saying is that historically, tools like MS Project were primarliy planning tools. Once the project went live, the
effort required to keep a schedule "live" was so huge, many did not do it. However, Project Server changed all that. Now we have a
tool that can be a fundemental part of the work process. If I have to fudge things, then I lose the ability to generate "exceptions"
that are meaningful. I think that counts as going off on a tangent...
Regards,
Simon
"Jan De Messemaeker" <jandemes at prom hyphen ade dot be> wrote in message Hi,
Let me answer the why.
Project assumes that you know what you ask for when you ask for 10% of the resource for the small task.
It will never change that.
And that you know what you want when you ask for 100% on an other task.
It will never change that.
For all Project knows that resource may be a machine that you cannot use at 90%.
So the two tasks cannot run in parallel because that yields an overallocation.
In anothe rpost you say I hesitate to assign 90% to the other task because than I am leveling by hand and not by Project.
You are absolutely right, and I am glad somebody made that remark, it is the reason for 99% of the compaints on leveling not working
properly.
Thre problem is "you started the war" when you defined the small task as being done buy somebody at 10%. That as such is already
leveling by hand, and your chances of having a properly leveled result have gone.
If you want the best results for lmeveling DON'T use percentages.
When people work they are supposed to word at 100% of their brain.
Introduce "many slmal interventions" as many small taks (maybe a recurring task) with 100% allocation, in othe rwords don't start
leveing by hand.
Leveling will work nicely.
Hope this helps,
--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
http://users.online.be/prom-ade/
+32-495-300 620
"Simon Dullingham" <
[email protected]> schreef in bericht I'm trying to performing leveling on a project, but it's clear to me that I don't understand how this works as it is not doing what
I want it to.
I'm going to use a simple example which hopefully will enable someone to tell me why does not do what I expect.
I have three basic tasks - a) My main task, b) my back up task, and c) my weekly meetings. I have one resource, ME. Tasks are
defined as
My main task "A" - ME assigned 100% (160 hours over a 4 week period); priority 500
My backup task "B" - ME assigned at 10% (16 hours over a 4 week period); priority 600
My weekly meetings "C" - a reoccurring task set weekly; ME assigned for 2 hours at 100%; priority 1000 (no leveling).
If I level, no matter what the settings, it pushes the 4 week main task to the end of the 4 week period. The daily resource load
looks like:
M T W T F M T W T F M T W T F M T W T F M T W T F
0.5 0.5 0.5 0.5 2.5 0.5 0.5 0.5 0.5 2.5 0.5 0.5 0.5 0.5 2.5 0.5 0.5 0.5 0.5 2.5 8 8 8 8 8 ...
This is obviously not want I want. I want each day's total to be 8 hours. I want task C to be assigned first (2 hours on friday),
Task B to be assigned next (0.5 hours per day), and then task C to use the remainder of the day that is free. i.e.,
Day M T W T F M T W T F
A 7.5 7.5 7.5 7.5 5.5 7.5 7.5 7.5 7.5 5.5
B 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5
C 0 0 0 0 2.0 0 0 0 0 2.0
So I guess the question is, why is not doing this? Or, am I missing something dumb that will make it do this?
Thanks in advance
Simon
