Max units vs. tasks with specific resource availability

[soniva]

Hi!

I have described my problem here
http://www.positivistene.org/2008/01/14/MSProjectAndResources.aspx

(sorry for the introduction on the case).

My main concern is that the developer's "non-productive-work" i
ignored in the project, and therefor the project when initiated i
already wrong. Programmers do not work 100% 37,5 hours a week, the
work closer to 75%.

But does this mean that an initial 10 hour assignment is going to b
completed in 12.5 hours, or will it take almost two full days calenda
time rather than a bit more than one.

I did a small test in project. In the resource view I created
developers working 65%, 50% and 100%. I then created an "implementatio
phase" and a "test phase" - I gave the developers 20 tasks to carry ou
- amount of work everything from 2h to 35h.

The result? Project uses my % input, but not for calculation in an
way. In theory (I believe) my 50% working developer _should_ spend 1.
weeks calendar time on set of tasks making out 37.5 hours (1 wor
week). But project ignores this fully and says that this well start o
monday and be complete following friday.

So my quesion is; how do I make sure that project uses the "max units
that I set and places a task over the actual available time, instead o
how it now works, basically just ignoring it fully

 

[soniva]

Well - doing some additional searching on this page gave me a hint to
the solution
(http://forums.techarena.in/showthread.php?t=776459&highlight=change+formula).


The duration is the time the work will take in, what I call it,
calendar time. Work however is the _real_ estimate of the work.

So I started a new test. Added the "work" column and provided the
estimates there. The estimates where kept as I hoped - duration changed
drastically for my 65% programmer.

So - adding column "work" and using the estimates there seems to do the
trick.

 

[Jan De Messemaeker]

Indeed!

--
Jan De Messemaeker
Microsoft Project Most Valuable Professional
+32 495 300 620
For availability check:
http://users.online.be/prom-ade/Calendar.pdf

 

[Steve House]

I like to think of the assignment percentage as representing the rate at
which a resource converts time into work. If someone is assigned to a task
requiring 8 man-hours of FTE (full time equivalent) work @ 100%, the task
will take 8 hours of duration to do. If he's assigned to that same task at
50% it will take him 16 hours of duration time to get the same job
completed. The percentage does not represent the percent of their workday
or their workweek that they're spending on the task except in a very rough
sense. Better it represents the "distraction factor" the amount of other
stuff on their plate that means it'll take longer to finish this task than
it would if they didn't have anything else to do.

In the case of your programmers, they may not work all of their workweek on
programming but when they DO write code I'll bet you expect them to get an
hours worth of writing done for every hour of time they put in on it. When
you assign them to a task that requires 8 hours of work that could start
Monday morning at 8am, I suspect you expect them to get it done in 8 hours
and finish Monday afternoon at 5 (100% assignment) and not dilly-dally with
it and stretch it out for the full week to turn it in Friday at 5 (20%
assignment).

When you assign resources to a task, Project assumes that whatever
assignment percent you use was what you had in mind when you came up with
the duration estimate in the first place. Have a 1 day task starting Monday
at 8 and finishing Monday at 5? Assign Joe at 100% and the duration will be
one day. Take him off and assign Bob at 50%. The duration stays at 1 day.
Take him off and assign Mary at 10%. The duration stays at 1 day. What
does change then between those three assignments? Not the duration but the
calculated value of the FTE work man-hours, 8 man-hours for the first one, 4
man-hours for the second, ~50 woman-minutes for the third.

Tasks should not expand or contract to fit the available time - task are
always finite. They produce a tangible, measurable result and take exactly
as long as it take to produce that result, no more and no less. The task's
duration is NOT the time allowed for the resource to produce his results -
it is your best estimate of the time that it will take him to produce them.
They can't stop before 100% of the deliverable is achieved and they have no
reason to schedule them last any longer than it takes to reach the
deliverable.

 

[soniva]

In the perfect world I would hope that a developer getting a 8 hour
assignment start to work on the task 08:00 monday morning and complete
it 16:00 later the same day.

In the real world it is not like this - we help out with support cases
we drink coffee, we use the facilities, we discuss a problem wit
another developer, we have lunch, etc. On a good day we might use 80
of the time doing actual coding - on a "normal" day I would believ
that the number is closer to 70%.

"Tasks should not expand or contract to fit the available time - tas
are always finite. They produce a tangible, measurable result and tak
exactly as long as it take to produce that result, no more and no less
The task's duration is NOT the time allowed for the resource to produc
his results - it is your best estimate of the time that it will tak
him to produce them.

Not beeing a native english-speaker I am unsure what you mean with thi
and with your post as a whole.

Do you mean that one should _not_ include the "distraction time" a
all? Or do you mean that it is ok to include it - but make sure that
task that takes 4 hours and is done by 1 guy at 50% is done in one da
instead of getting 2 hour done over 4 working days

If you mean that it should not be included - how would you get th
project to meet the mileston(s) and release? People will never wor
100% focused day in, day out. In optimal cases you might get 90% - bu
at the current time, that is not available in my organization. So i
this is not calculated (one can also include it as part of th
estimates of course) - your project will most likley be off targe
after day 1, and additional working time (overtime) needs be initiated

Br


Iva

 

[Steve House]

Look at it this way - when you estimate the task's duration what is your
mental process? Most of us would say to ourselves something like "I think
it will take Joe about 2 days to do that because last time we did a project
like this, Joe started a similar task on Monday and finished it late Tuesday
afternoon." OR we go to Joe and ask him "How long do you think it will take
you to write that user interface?" and he'll answer "Should be about 2 days
I imagine." But we have no idea of how much of that estimated 16 hours was
or will be actually spent doing the task and how much was spent in the
facilities, getting coffee, chatting with another developer, etc, (lunch
should be accounted for in the working time calendar so that's not a
factor). The question I have to ask is, does it really matter? We know that
Joe started Monday morning and finished Tuesday afternoon and in terms of
scheduling when the next task in line might be able to start and in terms of
how long it will take to do the entire project that's really all we NEED to
know. Why do we really care if during that 16 hours Joe actually did 16
man-hours of work or 14 man-hours plus 2 hours of coffee or 12.37 man-hours
plus an hour of coffee and 2 hours in the bathroom plus some time doing
something else, etc? It took him 16 hours start to finish working at what
for him is a full-time effort for all intents and purposes, we paid him for
16 hours man-hours of work, and in terms of managing the project that's all
we really need to be concerned with. In this project I'd just ignore
bathroom breaks, coffee breaks, chatting with a partner, etc and assign him
100%. Now if he had something else on his plate he had to work on at the
same time, THEN I'd reduce the assignment percentage to take into account
the fact that it will take him more than 16 hours to do the same amount of
work he would have 16 hours to do without the other simultaneous work on his
schedule. It just doesn't matter that "100%" is really 88% work and 3%
bathroom and 5% coffee and 4% email and 1% wandering aimlessly. Don't fall
into the trap of thinking you need to micromanage every moment of the
resource's workday - that's his responsibility, not yours.
--
Steve House [Project MVP]
MS Project Trainer & Consultant
Visit http://project.mvps.org/faqs.htm for the FAQs

 

[soniva]

I think we might be moving out of scope of the initial post

My programmers have additional tasks that cannot be put into any
project plan, helping with support cases is one of these (I cannot
wait to get this removed from the team). I know they will have to do
support every other day during one week - so I plan for that - this
also removes the chance of a "I had to spend 2 hours on support today,
so we have to reschedule the project". I might have been focusing to
much on the "using the facilities" part I include that part as well
to make sure that everything is taken into consideration, and that the
project plan that is ready when things start is as close to the truth
as possible.

I have worked with 100% before - and had some negative experiences with
that. Different developers estimated differently. Someone included
everything in their estimates, some only included code, etc, etc. Here
I tell them to estimate the code work only, and we'll plan some
overhead for the rest.

Anyways - I have found the solution to my initial question. So
everything is good for now

 

[Steve House]

My intent was to give you some food for thought - hope it helped.