Private projects are highly sensitive projects that require more tightly restricted user access than the normal SLIM-Collaborate permissions rules provide. To understand how access to private projects differs from the built-in access rules that govern normal projects, a short review of SLIM-Collaborate’s default permissions hierarchy may be helpful. For non-private projects, ensuring access to project data in SLIM-Collaborate is a two-step process:
•First, generic access
to projects in each stage is granted (via a user’s default role). For
example, before a user can be granted access to even one project in the
Estimation stage, his default user role MUST have View, Contribute, or Full
Access permissions to the Estimation service. These permissions can only
be granted by Site Admins. Note that access to the Estimation service is only
a prerequisite – by itself, Estimation Service permissions do not grant
permission to even a single project in the Estimation
stage.
•Next, specific access
to individual projects is granted (by editing each project’s Access
settings). Users can gain access to projects through being
assigned Primary Responsibility for the project (requires Manage Projects
permissions in the user’s default role), via membership on the project’s OBS
node, or by being added to the project’s User Access list. Because
the permissions in each user’s default role may not match the access required to
work with every project, SLIM-Collaborate provides a way to “overrule” a user’s
default access for one or more projects:
o At the OBS Node Level. When a user is assigned to an OBS node, his default
role can be overridden to grant a different set of permissions
that only apply to projects assigned to that OBS node. Because
the override applies only to projects assigned to the OBS node, it is not
possible to grant system-level permissions (like Manage Projects, Back Office,
or Manage Site) via OBS node assignment.
o At the Project level (via the user access list). A user’s default role may be manually overridden when granting individual project access via the User Access List (Edit Project or Template | Access tab). In this case, the override applies ONLY when working with the individual project.
There is one notable
exception to the rules summarized above: Site Admins (users with Manage Site
permissions in their default role and responsibility for configuring and
maintaining the site’s settings) can see ALL projects in the portfolio,
regardless of each individual project’s user access settings. But for
highly sensitive projects, this kind of universal, automatic access may violate
corporate non-disclosure policies. For this reason, SLIM-Collaborate has a
“private project” status that follows a more restrictive set of access rules.
Essentially, the “private project” status overrides two of the regular
project access rules in SLIM-Collaborate. Unlike regular projects, private
projects:
•Are NOT automatically visible to Site Administrators.
Normally, site admins are the only users who can see every project in the
portfolio, regardless of project-level access settings. This ensures that there
is always at least one user who can see and access all projects, providing
global oversight of the site’s usage and project data. But for private projects,
Site Admins will have access to a private project ONLY if the site admin is
explicitly designated as the person with Primary Responsibility. Site
Admins cannot be added to a project’s user access list, so unless a Site Admin
happens to be the user with Primary Responsibility for a project, he or she will
not have access at all.
•Are NOT visible to users who belong to the project’s designated OBS
Node (or higher nodes, if this box is checked on the project’s access
tab).
Private projects provide an extra level of security, appropriate for highly sensitive bids or contracts. But this added security comes with a few tradeoffs and restrictions. Because they are accessible ONLY to (1) the user with primary responsibility and (2) users on the project’s access list, extra care must be taken to ensure that proper access to private projects is maintained when users leave the organization or are transferred. Additionally, because private projects are not directly accessible to Site Admins, Admins must take special care when disabling user accounts or reporting on the number of projects in the portfolio. To provide some oversight of private projects and users responsible for them, a separate count of private projects (by users primarily responsible) is available via the Admin site’s user list by selecting Browse Users from the Admin site menu.