Scheduling Recurring Meetings
in [Project]
|
From: Sean on 1 Feb 2010 03:36 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
From: Rob Schneider on 1 Feb 2010 03:42 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 On 01/02/10 08:36, Sean wrote: > 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
From: "Steve House" sjhouse at hotmail dot on 1 Feb 2010 06:51 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. -- Steve House MS Project Trainer & Consultant "Sean" <Sean(a)discussions.microsoft.com> wrote in message news:5CC12A1F-7F62-47CD-BFDA-65F65612AF4C(a)microsoft.com... > 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
From: &e7 on 2 Feb 2010 07:33 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!) "Steve House" wrote: > 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. > -- > Steve House > MS Project Trainer & Consultant > > > > "Sean" <Sean(a)discussions.microsoft.com> wrote in message > news:5CC12A1F-7F62-47CD-BFDA-65F65612AF4C(a)microsoft.com... > > 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 > > . >
From: Larry Christofaro on 2 Feb 2010 09:00 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 "&e7" wrote: > 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!) > > > "Steve House" wrote: > > > 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. > > -- > > Steve House > > MS Project Trainer & Consultant > > > > > > > > "Sean" <Sean(a)discussions.microsoft.com> wrote in message > > news:5CC12A1F-7F62-47CD-BFDA-65F65612AF4C(a)microsoft.com... > > > 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 > > > > . > >
|
Pages: 1 Prev: Applying filters simultaneously Next: changing settings to non-standard work week |