project to manage consultants (aka calendar vs hours worked)

[Brad Langhorst]

I've been lurking here a bit and am surprised that this does discussion does
not occur frequently...

My developer group of about 6 people are all consultants.
I don't have any control of when or how often the work.
I certainly don't expect them to be on an 8 hour M-F schedule.

I assign a task and a deadline and that's it.

I'd like to use project to track my estimates of how long a task will take
relative to how long it actually takes (so i can learn about my developer's
skills)

I also want to use project to sequence tasks and schedule them over time.

So it sounds like i want both elapsed and work time.

How do others handle this situation?

brad

 

[Steve House]

You may not control when they work nor expect them to work 8-5 but they
certainly aren't working in a random walk. While they may work 8-5 9-6
10-7 etc, 6 hours some days, 10 hours on others, they probably put in
more or less regular workdays and hours. So set up your Project and
resource calendars to reflect the general case and go with that.
Project management is not about micro-managing people's workdays anyway
and IMHO it's just plain silly to see a project plan that says "Bob is
going to work on polishing widgets Tuesday from 10:17 to 14:33"
especially if the widget polishing isn't scheduled to happen for 3
months down the road. But using the general case, you can say with some
confidence something like "We have to do Task X before we do Y because X
produces a module that is needed for Y. Task X should be about 25
man-hours and if we get it started Monday morning and I put one person
on it, we'll wrap it up by Wednesday evening or Thursday morning and so
we can plan on starting the follow-on Task Y on Thursday and Task Y is
about 80 hours of work but with only one person on Y that means it'll
take about 2 weeks and we'll miss our contract deadline the following
Friday so I better put 2 people on it working together to get it done on
time." That sort of planning and budgeting is what Project is all
about and all the tracking stuff is really just a reality check to see
how well you did the planning, whether it's progressing according to
plan, and forecasting the future performance of the project early enough
to allow you to take corrective action when it starts deviating from
plan for some reason.

Note that elapsed time, duration, and work are three different measures.
Elapsed time is the time between when a task starts and finishes as
measured by normal clocks and calendars. Duration is the number of
minutes that have been defined as "working time" by the task's governing
project/resource calendar between when it starts and ends. Work is the
actual staff hours devoted to doing the task. With the default 8 hour
day calendar, a task that begins Mon at 8, ends Fri at 5, and has two
full-time employees on it has 104 hours elapsed time, 40 hours duration
time, and 80 man-hours work.

 

[Brad Langhorst]

thanks for your response - but I don't think your suggestion will work for
me... see below for why i say that.

You may not control when they work nor expect them to work 8-5 but they
certainly aren't working in a random walk. While they may work 8-5 9-6
10-7 etc, 6 hours some days, 10 hours on others, they probably put in
more or less regular workdays and hours.

nope - sometimes i get 20 hours of work in a week sometimes 2
there is very high variance and the average is a profoundly bad predictor of
how much availability a given resource wil lhave.

So set up your Project and
resource calendars to reflect the general case and go with that.

I'm not interested in micro managment - but i do want to say
this will take 2 hours of work and is expected to be completed by december
31st - it seems like i can only do one of those things in project

project is still useful for scheduling which tasks should happen when
but it seems like I lose a bunch of project's value by not being able to
track how things are going.

all the tracking stuff is really just a reality check to see
how well you did the planning, whether it's progressing according to
plan, and forecasting the future performance of the project early enough
to allow you to take corrective action when it starts deviating from
plan for some reason.

yeah - that's the part i'm missing i think

Note that elapsed time, duration, and work are three different measures.
Elapsed time is the time between when a task starts and finishes as
measured by normal clocks and calendars. Duration is the number of
minutes that have been defined as "working time" by the task's governing
project/resource calendar between when it starts and ends. Work is the
actual staff hours devoted to doing the task. With the default 8 hour
day calendar, a task that begins Mon at 8, ends Fri at 5, and has two
full-time employees on it has 104 hours elapsed time, 40 hours duration
time, and 80 man-hours work.

i think I understand this - in my situation the duration concept useless
right?

I want to enter both elapsed and work time for a given task - that way i can
both improve my ability to estimate how long things take.
If I use 24hour days then project estimates that the project time estimation
will be profoundly inaccurate. If i just use elapsed time then i have no
way to esitmate cost or assess how closely a consultant's bill matches my
expectation.

brad

 

[Steve House]

As far as duration being useless for you, it's just the opposite.
Actually it's elapsed time that is of limited use in project planning
and duration will be far more useful. Duration is an indicator of how
many hours people are working and if you know how many hours a day
people work, the master scheduling formula W=D*E will relate the effort
they put in to the time it takes to do the task. If I have a task that
starts 15 Dec and ends 31 Dec, the duration is 12 days while elapsed
time is 17 days. The difference is due to the 2 weekends and the Xmas
holiday being non-working days so there are 5 elapsed time days that
don't count as duration days.

If you have a task that will require 1 person working 2 hours that can
start today, 15 Dec, and is due 31 Dec, the duration is NOT 2 weeks.
The start is 15 Dec, duration is 2 hours with a deadline constraint of
31 Dec at a resource level of 100%. If they can only work 50% of their
time the duration is 4 hours. If only available 25%, 8 hours. And so
forth. Just because there's a deadline of 31 Dec you don't expect them
to wait until the last possible moment to do their work.

You say that sometimes you sometimes "get" 20 hours per week and other
times only 2. What determines how much time you get? Surely it's not
left to your resource's whim, only letting you know after-the-fact when
they bill. I work on contract myself and control my own schedule but
it's totally appropriate for my clients to tell me how much time they're
going to need or at least to ask for an estimate of how much time I'll
be able to devote to their project. So when you give Joe the assignment
above, ask him when he thinks he'll start and how much time he'll put
in. The absolute deadline may be 31 Dec but you still would most likely
prefer to get it done ASAP so if something goes wrong you've got a
cushion that will still let you get the project completed on schedule.
Explain to Joe that work being done by someone else is dependent of when
he will finish his bit and you need to be able to tell them when to be
ready to go.

At 2 hours of work you may be refining your WBS too tight. A rule of
thumb especially useful in knowledge work projects is the 8/80 rule. If
a task is less than 8 hours you're micro-managing and it should be
rolled up into a higher level task. If it's over 80 hours duration
you're not splitting the work into small enough packages to be
manageable.