A
anovak
After pondering for quite some time about how we were going to account
for support activities in Project 2007, I believe I've found really
only one option that is consistent, bullet-proof, and does not require
a great deal of maintenance.
First, we tried is this...
1. Created a Support project with one or more support task categories
- each with a fixed duration of, say, 60 months.
2. Assigned each enterprise resource on the programming team to one
or more categories (tasks) on the support project according to their %
availability for support. That is, if the programming team was
dedicated 15% to support, then they would be assigned at 15% to the
support category. Now, if there were more than one support category
(more granular), the total units assigned for each person had to add
up to 15%. That's why the strong recommendation was to have only one
general support category and use the 15% per team member.
3. So far, so good -- so many hours were assigned to the team members
across a 60 month period based on % units (e.g., 6240 hours over a 60
month period - 1.2 hours a day for 4 team members).
4. We would keep their max capacity at 100% and let the support work
show up in the view availability chart as a portion of scheduled work
which in turn impacted availability (8.0 - 1.2 = 6.8 hours per day for
each team member).
5. As team members are assigned to "real" projects, the PM has to
deliberately assign them at 85% (15% dedicated to support) in order
for the effort to be realistically spread across the Duration.
--What I noticed during testing was that as actual work is entered, if
its not right on the mark (exactly the amount allocated each day),
work would either be added or subtracted from some of all of the
remaining days during the 60 month period. Moreover, in some cases,
if the actual work booked against the support project was
substantially higher than scheduled, scheduled work in the future
would be wiped clean. So, that 15% per day allocation would be lost
in the future (and really it doesn't matter if its 60 months or 6
months - the same thing happens conceptually). What's more, it would
be extremely tough to deal with having to reconstruct the original 15%
allocation from the point that actual work was overriding the original
work estimate.
--Then I got the idea to have a Support task in the support project to
which all the resources would be assigned at 15%, but the actual work
would be booked against other lines in the project that were only for
the capture of actual hours (0 duration, 0 work assigned). However,
it seems there's a snag there in that since actual work actually
becomes work, the total work for the project is overstated because the
work numbers for the "actual" tasks roll up with the work number for
the "assignment" task.
--I'm beginning to face the fact that Project Server 2007 was never
meant to track ongoing work that never ends. It naturally continues
to calculate Remaining Work. Here's what I think is the only
approach that can be taken that doesn't have any big gotchas after its
implemented.
1. Create support project as above with 0 Duration and assign all
team members at 0% (or at 100% - it doesn't matter if still 0
Duration - but I'd still have them assign at 0% to keep things
consistent). This is just for the purpose of capturing actuals
only. This will result in a milestone that shifts forward as actual
work is booked in the future. These tasks will also be flagged as
completed the first time someone posts actual work but we'll deal with
that (they are flagged as "Support" projects with a custom field and
can easily be filtered). I think that as long as you have booked
time against an assignment in My Tasks within 10 days, even if its
flagged as completed, it still shows up in My Tasks.
2. Instead of booking support tasks to reduce resources availability
in the system, just set their max capacity to 85% (or set the max
individually based on manager input). This way the PM doesn't have to
think about that 85% (or other %) when assigning to project tasks in
the future but they can override if they wish if they see additional
projects scheduled for them in the view availability chart in the
resource center or they know the won't be working on support that
week.
3. Capacity is now shown at below 8 hours for these resources (the
red line in view availability) and the only activity you have to
proactively look for in the view availability chart are other "real"
project assignments.
4. If actual support work pushes them above their (< 8 hour) capacity,
then its old news because only actual support work is captured.
5. This way, there would be virtually no on-going maintenance
required of the support project tasks other than adding new employees
@ 0% and removing terminations (in other words, the support project
assignments would just keep rolling along in the future without a need
to augment the work scheduled, etc.)
6. We will follow the same rule of thumb for leave of absence and
administrative work (both different project types), but we will not
reduce enterprise resource maximum capacity due to these assignments
(you can't really predict leave of absence and admin work). Again,
just capture actual leave of absence and admin work.
7. Finally, for teams that are STRICTLY support and provide that
support through responding to requests (no ongoing support to speak
of), keep their resource capacity at 100%. This would be different
from the programming teams which "balance" on-going support with
projects.
Dale / Gary, or my other friends at the forum, please comment on this
and let me know if my thinking is sound. This has been a huge
challenge and this is the only real answer I can think of that doesn't
have holes all in it. Scheduling this on-going work as a % of
availability just doesn't seem to work and using separate tasks for
work scheduled and actual work reported isn't a good idea either.
Best Regards,
Andy Novak
UNT
for support activities in Project 2007, I believe I've found really
only one option that is consistent, bullet-proof, and does not require
a great deal of maintenance.
First, we tried is this...
1. Created a Support project with one or more support task categories
- each with a fixed duration of, say, 60 months.
2. Assigned each enterprise resource on the programming team to one
or more categories (tasks) on the support project according to their %
availability for support. That is, if the programming team was
dedicated 15% to support, then they would be assigned at 15% to the
support category. Now, if there were more than one support category
(more granular), the total units assigned for each person had to add
up to 15%. That's why the strong recommendation was to have only one
general support category and use the 15% per team member.
3. So far, so good -- so many hours were assigned to the team members
across a 60 month period based on % units (e.g., 6240 hours over a 60
month period - 1.2 hours a day for 4 team members).
4. We would keep their max capacity at 100% and let the support work
show up in the view availability chart as a portion of scheduled work
which in turn impacted availability (8.0 - 1.2 = 6.8 hours per day for
each team member).
5. As team members are assigned to "real" projects, the PM has to
deliberately assign them at 85% (15% dedicated to support) in order
for the effort to be realistically spread across the Duration.
--What I noticed during testing was that as actual work is entered, if
its not right on the mark (exactly the amount allocated each day),
work would either be added or subtracted from some of all of the
remaining days during the 60 month period. Moreover, in some cases,
if the actual work booked against the support project was
substantially higher than scheduled, scheduled work in the future
would be wiped clean. So, that 15% per day allocation would be lost
in the future (and really it doesn't matter if its 60 months or 6
months - the same thing happens conceptually). What's more, it would
be extremely tough to deal with having to reconstruct the original 15%
allocation from the point that actual work was overriding the original
work estimate.
--Then I got the idea to have a Support task in the support project to
which all the resources would be assigned at 15%, but the actual work
would be booked against other lines in the project that were only for
the capture of actual hours (0 duration, 0 work assigned). However,
it seems there's a snag there in that since actual work actually
becomes work, the total work for the project is overstated because the
work numbers for the "actual" tasks roll up with the work number for
the "assignment" task.
--I'm beginning to face the fact that Project Server 2007 was never
meant to track ongoing work that never ends. It naturally continues
to calculate Remaining Work. Here's what I think is the only
approach that can be taken that doesn't have any big gotchas after its
implemented.
1. Create support project as above with 0 Duration and assign all
team members at 0% (or at 100% - it doesn't matter if still 0
Duration - but I'd still have them assign at 0% to keep things
consistent). This is just for the purpose of capturing actuals
only. This will result in a milestone that shifts forward as actual
work is booked in the future. These tasks will also be flagged as
completed the first time someone posts actual work but we'll deal with
that (they are flagged as "Support" projects with a custom field and
can easily be filtered). I think that as long as you have booked
time against an assignment in My Tasks within 10 days, even if its
flagged as completed, it still shows up in My Tasks.
2. Instead of booking support tasks to reduce resources availability
in the system, just set their max capacity to 85% (or set the max
individually based on manager input). This way the PM doesn't have to
think about that 85% (or other %) when assigning to project tasks in
the future but they can override if they wish if they see additional
projects scheduled for them in the view availability chart in the
resource center or they know the won't be working on support that
week.
3. Capacity is now shown at below 8 hours for these resources (the
red line in view availability) and the only activity you have to
proactively look for in the view availability chart are other "real"
project assignments.
4. If actual support work pushes them above their (< 8 hour) capacity,
then its old news because only actual support work is captured.
5. This way, there would be virtually no on-going maintenance
required of the support project tasks other than adding new employees
@ 0% and removing terminations (in other words, the support project
assignments would just keep rolling along in the future without a need
to augment the work scheduled, etc.)
6. We will follow the same rule of thumb for leave of absence and
administrative work (both different project types), but we will not
reduce enterprise resource maximum capacity due to these assignments
(you can't really predict leave of absence and admin work). Again,
just capture actual leave of absence and admin work.
7. Finally, for teams that are STRICTLY support and provide that
support through responding to requests (no ongoing support to speak
of), keep their resource capacity at 100%. This would be different
from the programming teams which "balance" on-going support with
projects.
Dale / Gary, or my other friends at the forum, please comment on this
and let me know if my thinking is sound. This has been a huge
challenge and this is the only real answer I can think of that doesn't
have holes all in it. Scheduling this on-going work as a % of
availability just doesn't seem to work and using separate tasks for
work scheduled and actual work reported isn't a good idea either.
Best Regards,
Andy Novak
UNT