Scheduling Recurring Meetings

[Sean]

Hello All-

I'm sure this is a very basic question, but I'm looking for
thoughts/suggestions/experience. When scheduling the availability of project
participants, I always schedule below 100% to account for the fact that
resources are rarely devoted to a project full time (and even when they are,
they have sick days, e-mail to check, etc). My question is about how I
should schedule project-related recurring activities that involve project
participants (such as a recurring project status meeting). Is that something
I should put in Project, or should I just reduce everyone's availability by
that amount of time? Any recommendations would be much appreciated. Thanks,

-Sean

 

[Rob Schneider]

You'll get various opinions on this. The answer probably depends on the
culture of the company, how the company/team recovers costs and bills
customers, and the purpose of having the project modeled in Project.

Unless the meeting is a "deliverable", I would not put project team
recurring meetings into the plan. I also probably would not bother
reducing availability to account for meetings since going to meetings
and communication is a fundamental (and ultimately billable) part of
doing projects.

The main reason I would reduce availability would be for a high level
recognition that a) the people may not be avialable full time on this
project due to other projects, or b) account for
vacations/holidays/sickness.

The purpose of Project is to help deliver the project. Project not good
at accounting for all time in the day.


--rms

www.rmschneider.com

 

[Steve House]

My view is that generally I would not adjust availability for such drains on
people's time as email, etc. The reason looks back to how one comes up with
duration estimates in the first place. If I have to put a task "Wax
Widgets" into my current project plan, I'm going to look back to previous
projects and see how long it took to wax a comparable number of widgets.
Let's say last year we had 50 widgets and it took us from Monday to Friday
to do them. That means we typically wax 10 widgets a day. This year we
have 100 to do so it will probably take 10 days. But I'm working with gross
amounts here - I don't have the detailed info to tell me during last year's
project the 40 hours Joe Resource spent waxing the widgets was really 34
hours widget waxing, 2 hours water cooler conversation, 2 hours answering
email, and 1 hour meeting with his boss, and several potty breaks. So when
I assign him 100% to the task this year, it's understood that the 10 day
duration estimate already includes the allowance for a reasonable amount of
non-widget waxing activity that will take place during the 10 days. We
don't actualyl know how much of the 10 days is really waxing widgets versus
other drains on his time, nor does it matter. What we care about is if
widget waxing starts on Monday, it will be finished a week from Friday so
the guy who needs to work on the widgets once they're waxed can be told when
to be ready for them. Sick days, OTOH, should go into the resource calendar
as non-working time before posting in progress so the task durations adjust
appropriately.

Note that the assignment percentage is not really the amount of the
resource's time that can be devoted to the project. Rather, it is the rate
at which the resource does project work as compared to the time it takes him
to do it. 50% does not mean you have him for 4 hours. It means that when
you assign him to a task lasting 8 hours, he will only do 4 man-hours of
work on it.

 

[&e7]

I usually just pepper my schedule with "Contingency" tasks, often at the end
of the month for "stuff" like meetings and other unaccountable things. That
way I have less surprises.
As a rule of thumb, I find that I need to assign 25% of the time to that
kind of thing - that's the creative nature of the work we're doing rather
than bad project breakdowns (I hope!)

 

[Larry Christofaro]

Good suggestions all around. I've used recurring tasks (and like it for my
own PM work), meeting tasks (but few get this right especially with Project
Server and it creates maintenance), and setting aside a task per phase (so
that work per phase comes out correct). What I really like is the Keep it
Simple approach...at least as long as it doesn't go against a client policy.
That is to increase all tasks by a fraction to take into account status, time
tracking, and the like. This does not include contingency as I wouldn't give
someone more hours than what was planned. That's very important (people will
use whatever hours you give them). I then tell them to put the status
meeting, time entering time, etc. to that/those tasks. It is easy for them
and easy to manage. And besides, the time they spend in a status meeting is
all about them communicating to others and others communicating to them about
those very tasks. It is truly to the benefit of what they are working on.
Hope that helps..
Larry Christofaro
Digineer