Changing Roles within EPM

[RichC]

This question is regarding Project Server 2007.

I'm a newbie user of Project Server and understand the groups and
categories. It seems to me however that the permissions assumes a person is
always performing in the same role across projects. For most of our
enterprise projects this makes sense and the existing groups and categories
work well.

But I have a requirement where certain people want to use the project server
interface to manage their own projects and don't necessarily want to make
them visible to anyone. Or they want to choose who can see their projects.

How do you set up the groups and categories such that you can manage the
security on a project by project basis?

For example,

Project A might include the following hypothetical members and roles:

Member A = PM
Member B = Resource Manager
Member C = Executive
Member D = Team Member

While Project B might include the same members in the following roles:
Member A = Executive
Member B = PM, Resource Manager
Member C = Team Member
Member D = Team Leader

Any suggestions on the steps I'd go through to implement this?

 

[Marc Soester [MVP]]

That is an interesting request. Generally security is attached on a group /
role basis. you cant give project managers the ability to choose which users
can or cant see their projects. This will generally be managed by
administrators ( unless you would give PM's the ability to amend security,
and I doubt you would want to give them such power).

As you know, you can give "project by project" access using the categories.
You can implement a process where a PM communicates to an Administrator which
user groups ( or users) can see their project, but this will be a high
maintenace pocess.

the idea of having an enterprise project mangement solution is to give
organisations the abiltiiy to see what projects are actual, it gives them one
set of truth. By not allowing anyone to see the projects would defeate the
purpose of having an EPM solution.

Lastly, if a PM only wants to save the project in Project Server without
publishing it, would at least give the PM the ability to manage a project
without giving access to PWA. ( of course you would not have the workspace if
you would use EPM like this)

I hope this helps

 

[RichC]

Thanks for your response.

I know its an "ironic" question. And from my review I see that it will be a
high-maintenance process. And no, I wouldn't want to give away admin rights
to anybody/everybody.

But in regards to the role question, how would you facilitate a member being
a PM on one project and an executive on another project?

Its looking like I'd have to create groups and categories that are specific
to projects in order to be able to accomplish this. So, I'd have one set of
groups and categories for my regular epm projects which work well for our
engineering efforts as the roles are well defined, although many perform
several roles. Then create another set of group(s) and categorie(s) to
manage "other" projects where I might have, for example, I might want to as a
President of a company, create my own projects for managing investing,
financing, marketing "activities", etc., that shouldn't be visible to any but
those he wants to partipate in.

I guess the fundamental reason for the request, is that others see the
features within Project Server 2007 (for example the pushing of tasks to
Outlook, linking documents form SharePoint, the Issues, Risks, and the
collaborative features) and want to use it as a replacement for Project Pro
or other PM software. But they don't want to necessarily make their projects
"public" to an audience greater than themselves, one other, or their team.

There are other reasons. For example, in some development shops I've been
in, some developers may be forbidden from seeing certain projects due to IP
concerns and other legal/regulatory/organizational issues.

Once again, thanks for your response.

 

[ahelp]

I believe you're correct--you'll need separate categories and perhaps groups,
depending on how complex your situation becomes. However, another option you
might want to look at is to create separate instances of Project Server for
each situation. See
http://www.pptspaces.com/msprojectr...st=cea5da16-0c29-40a7-845e-4eea7cbc844d&ID=32.

 

[RichC]

I like this second approach. Looks very simple. Certainly provides clean
separation. And if projects become "enterprise" in scale, we can always
import them into the main project server.

Thanks for your time.

 

[Ben Howard]

Creating a second instance is NOT the way to go. Users will have to log on
to seperate instances, the resource pool will not reflect what users are
doing, Resource managers will not be able to make decisions...

If a user doesn't want anyone else to see their project, then don't add any
resources! Only add the people to the execs that need to view all projects.
If a PM is a member on another project, then that PM won't be able to open
the project in Pro, as he is not the PM.

I'd revisit your view of categories and do some testing with different
users, basically users only get to see projects in which they have an
interest, and then only the permissions that the role gives them. Worth
reviewing just what exactly different users require, rather than pigeon
holing them as execs etc.

Let us know how you get on.

-
Thanks, Ben.
http://appleparkltd.spaces.live.com/

 

[/pd]

Uno rule !!

Don't bring "stealth projects" into the EPM !!

/pd

 

[Jonathan Sofer]

There are different ways to dynamically control visibility and access to
particular projects using Project rules (Access to or using RBS rules. Take
a look at each of these rules to try and understand how they might work to
achieve your goal.

The User is the Project Owner or the User is the Status Manager on
assignments within that Project
The User is on that project's Project Team
The Project Owner is a descendant of the User via RBS
A resource on the project's Project Team is a descendant of the User
via RBS
The Project Owner has the same RBS value as the User

 

[Mark Everett | PMP]

There are different ways to dynamically control visibility and access to
particular projects using Project rules (Access to or using RBS rules. Take
a look at each of these rules to try and understand how they might work to
achieve your goal.

The User is the Project Owner or the User is the Status Manager on
assignments within that Project
The User is on that project's Project Team
The Project Owner is a descendant of the User via RBS
A resource on the project's Project Team is a descendant of the User
via RBS
The Project Owner has the same RBS value as the User











- Show quoted text -

I have done this using the RBS and not using the RBS (in the latter
case, the client didn't want an RBS). I created separate Categories
and Groups. Then I copied all the enterprise views and put in a
filter preventing people from Group A from seeing projects published
by Group B. The way I did it was to filter on project name since the
client had a naming convention that started with the client name. It
works very well and is easy to maintain.