what is best practice for support project timesheets?

[yeliab]

We are the beginning stages of a PWA 2007 implementation. We are using
timesheets to manually track progress at the project level; the "my tasks"
page is only used to communicate task info. (This works very well in our
earned value environment using a 0/50/100 reporting method.)

Now we have to deal with support work that is completely ad hoc. Admin
projects are not an option because we cannot capture custom info for
reporting purposes, so we need to use either projects or activities to
account for roughly 100 to 200 various combinations of business unit,
product, customer, etc.

What we want:
1. an easy way to provide users with timesheet lines for reporting work on
support activities.
2. scope control by having a list of predetermined support items to choose
from (no task adding scope anarchy)

What we don't want:
1. 100+ support lines on everyone's timesheet
2. resource availability affected

So, what's the best way to proceed?

 

[Marc Soester [MVP]]

Hi yeliab,

this is an interesting one and I understand the difficutlies that you are
facing.
Within Project Server you have 3 options ( the 3 you mentioned )

1. you can create admin tasks within the timesheet ( not an option from what
I understand)
2. you can create a proposal and Activities Project within PWA, but be aware
of the limitations.
3. You can create a Project ( e.g. support project ).

These are the only ways ( without custom development ) that Project Server
offers for users to enter time against it.

I believe you will need to think about option 1 or 2. Make sure that you
understand how you need to report. Once you knnow that you will be able to
determin how many projects ( or tasks within a project?) you will need to
create. An imidiate option would maybe something like a "Monthly Support
Project" That you can close by the end of the month and create a new one. As
I mentioned it very much depends on your reporting requirements.

If you let me know what reporting requirements you have, I may be able to
give you some assistance and insights how we usually would handle this for
customers.

I hope this helps

 

[yeliab]

First off, thanks much for the offer to assist Marc. It's much appreciated.

As far as reporting goes, I need to be able to associate project and support
time entries with the following enterprise custom fields (and their
associated lookup tables): type, client, product, version, and business
unit. This is an initial list of custom fields; there may be more in the
near future.

Oh, and this whole timesheet solution needs to be easy to use or it will
fail terribly. Ideally, the timesheet would have:

1. project lines autopopulated based on assignments (done)
2. admin time for true admin tasks like vacation, training, sick, etc (done)
3. a drop down list of support projects the user can select from as ad hoc
support work arises (need help here)

Keep in mind that my original list of wants and want nots must be met as
well. So, where do we go from here? Easy, right?

 

[Frank J.]

I faced similar issur here (we also just rolled out Project Server 2007). We
have about 90 employees here and each one has about 20 non-project related
repetitive tasks that management wants to track.

I played with differt option under PWA and Project Pro to handle. Setting
up a project for each employee for their unique repetitive tasks, or One
project with repetitve tasks option for each person.

Both of these seem difficult and time consuming to set up, and very
confusing to team users in entering time. I suggest it aslo distracted the
focus on project work.

My assumption is Project was developed to track projects, not people.

But I still needed a solution. I found a product on the Web called Web
Timesheet by replicon. It is easy to install and very user friendly to those
that need to track their time. Best of all it has a two way interface with
Project Server. I can import the hours loged towards repetive tasts into
Project, or transfer Project hours recorded into Replicon. Bottom line, mgmt
gets a complete recap of what each employee worked on over the month.

One item you need to keep in mind the interface to projcet only currenly
works with Project Server 2003. The 2007 version is promised for mid-January.

Hope that helps

Fj

 

[Curt Finch]

every time you buy a replicon product, god kills a kitten. buy from
journyx instead

 

[Marc Soester [MVP]]

hehehehehe, Oh yes that sounds very easy

yeliab, all these things may be possible by custom developing project
server, but in order to achieve this you will need expert help. check out the
microsoft partner site and see if you can find an EPM partner. If not let me
know where ou live and I will try to find someone for you.

My oppinion.........you have a challanging task ahead of you. I whish I
could help you more.

All the best
--
Marc Soester [MVP]
State Manager: EPM
http://marcsoester.blogspot.com

 

[HMH]

Sorry for late post.

Each situation is unique. This is what we did regarding support projects.

Each manager that has an area of support sets up a project. The project is
assigned the project identifier and put into the project system. Support
projects run for one calendar year, then are replaced by a new project
(probably identical) for the next year and so on. We have been doing this for
8 years and it works pretty well.

A support project can be internally subdivided by various tasks, if that
level of detail is required. Some areas had to do this.

Last year we started using project server 2003 and kept the same practice as
above.

One difference we applied to assist with the project leveling in other
development projects. We found that having one person assigned to each task
works best for the full-year support projects. Putting several people on the
same task interfered with our leveling in other discrete, time-limited
development projects. So if three people were working on XYZ support, each
would have their own task.

Also, each task has a drop-down list (custom field) that selects it as a
financial category: support, enhancement, capitalized enhancement, etc. This
is a requirement since we capitalize some projects. And even within a
capitalized project there are tasks that cannot be capitalized. It was
convenient to add the "support" designation at this level.

In the previous system, we even had three types of support (required by
contract). This was dropped in favor of one general type of support when we
moved from that system (and the contract expired).

Typical administrative tasks -- group meetings, status reports, timesheets,
etc. -- are also considered support and are tasks in the support projects.

Just one way of doing this. Hope this helps.