Requested feedback on 3 issues (contractors, project team sitestandardization,custom field descripti

[anovak]

1. Contractors - we will need to occasionally deal with contractors
that are onsite but only those that are here for large projects and
for a significant amount of time (several weeks or months). My
opinion is that you would just add those folks as individually
enterprise resources for the period of time the project is executed
and then either inactivate them or delete them once completed. If
short term I suppose they could be added as generic resources (Local,
right?)

2. Project Team Site value standardization - Do you see any need to
attempt to standardize the values in Issues, Risks, etc. as far as
priority levels, etc.? I was thinking about trying to learn how to
customize the central Project Team site template to do this as well as
create a standard project management library pre-populated with
artifact forms so that when a new project team site is created, they
will automatically have a full set of PM forms to use (InfoPath,
etc.). On the values for Issues, Risks priorities, categories,
status, etc. do you tend to allow each PM change those values to what
best suites them or standardize?

3. Custom field code descriptions - Do you typically use the
descriptions? Seems like a lot of data entry, especially if concise
but meaningful short names can be developed for the codes.

Thoughts?

Thanks,
Andy Novak
UNT

 

[Marc Soester [MVP]]

Hi Andy,

Regarding 1. Yes thats what you can do. If the contractor is required to
contribute to the project and he/she is working on site for a long time, I
would add them as a global resource ( but please also ensure that the
contractor receives the right training to contribute on workspaces for
example). Otherwise you simply use a generic resource and the PM needs to
update the Project Info.

Regarding 2. The idea is to standardise your process. This essentially means
that everyone is speaking the same language accross your PM organisation (
how cool would that be). Also, if you are after consolidated organisational
wide reporting, you want everyone to use the same termonology. Essentially it
means you compare "apples with apples". I would not allow a PM to change the
content of workspaces ( e.g. Risk, Issues or Deliverables).

Regarding 3. As you suggested, it depens if you require the description. If
you never use it ( e.g. for reporting or additional explanation), then why
use it? If on the other hand you need to explain short names or may even want
to profide additional explanation, then the description is great.

I hope this all makes sense

 

[anovak]

Hi Andy,

Regarding 1. Yes thats what you can do. If the contractor is required to
contribute to the project and he/she is working on site for a long time, I
would add them as a global resource ( but please also ensure that the
contractor receives the right training to contribute on workspaces for
example). Otherwise you simply use a generic resource and the PM needs to
update the Project Info.

Regarding 2. The idea is to standardise your process. This essentially means
that everyone is speaking the same language accross your PM organisation (
how cool would that be). Also, if you are after consolidated organisational
wide reporting, you want everyone to use the same termonology. Essentially it
means you compare "apples with apples". I would not allow a PM to change the
content of workspaces ( e.g. Risk, Issues or Deliverables).

Regarding 3. As you suggested, it depens if you require the description. If
you never use it ( e.g. for reporting or additional explanation), then why
use it? If on the other hand you need to explain short names or may even want
to profide additional explanation, then the description is great.

I hope this all makes sense

Sounds like on the outline codes that if you can use a short name for
the Value that really is self-explanatory, it would be better to use
that than have to pre-define codes and enter the descriptions, correct?