Quote:
Originally Posted by bfranci  We're about to implement Project Server at my company. I'm the manager of our PM group.
I'm excited to use the feature where resources will be able to provide task updates. However, I'd like to have a little more control over who those task updates get sent to. Am I correct in saying that the RBS determines exactly who the task updates roll up to? That sort of forced 1 to 1 relationship doesn't exactly work for me, because depending on the project, I might want a resource's task updates published to one PM or another, it won't necessarily always be the same person.
Is this simply a limitation of Project Server I can't work around? |
Welcome to the forum!
There are two distinct time submission features in Project Server 2007. One of them is Timesheets, and the other is Task Updates. Neither of them have their approver defined by the RBS.
Task Updates are sent to the Status Manager of the Task that the user has an assignment for. This is determined by a setting in the Project Plan. It is possible to have many Status Managers within one Project Plan, but you may only have one Status Manager per task.
Timesheets are a time submission facility where users may enter time for a project, an assignment, admin time, or custom timesheet lines. However, this information is not automatically transformed into a Task Update (without the implementation of custom code). There are ways to create timesheet approval chains, but in general, a Timesheet is submitted to the user's Timesheet Manager.
Does that help?
__________________
Stephen Sanderlin
Founder/Owner -
EPMFAQ
Principal Consultant -
MSProjectExperts If you found this message useful, please click the Thanks button in the post!
This electronic message, along with any information, advice, and opinions it contains, are mine alone and are not representative of my employer. All information is provided in "GOOD FAITH" and on an "AS IS" basis only. I provide no presentations or warranties, express or implied, including implied warranties of fitness for a particular purpose, merchantability, title, and noninfringement. I strongly advise you to extensively test any changes, workarounds, or techniques described herein on a development system prior to implementation in a production environment, and you are hereby notified that I bear no responsibility whatsoever for any loss, harm, or otherwise negative outcomes resulting from your actions, whether or not said actions were a result of this electronic message, directly or indirectly.