REMINDER

Check in on the

COLLABORATE mobile app

Primavera Unifier in Action

Prepared by:

Greg Colf

Business Systems Analyst, Senior

Qualcomm Incorporated

User, Group, and Template Administration and Security - Best Practices for a Successful Implementation

Session ID#: 15460

Presenter Background

■ Currently

▪ Qualcomm Real Estate

and Facilities (1 year)

▪ Oversee all Unifier

development and

operations.

▪ Two additional staff

members

— Development/Cost

Controls/Support

— Training/User

Management/Support

■ Previously

▪ University of Utah

Facilities Management

— Unifier Development and

operations (6 years)

— FM Webmaster

— Application Training

▪ Southern Utah University

— Taught Information

systems and networking

courses. (10 years)

▪ Construction Management

Experience

Company Background

■ Qualcomm Facts

▪ 220+ CDMA licensees

▪ More than $22.35 billion in

cumulative R&D

▪ Approximately 26,600 full-

time, part-time and

temporary employees

▪ 188 worldwide locations,

with 78 US locations

▪ FORTUNE’s 100 Best

Companies to Work For

▪ FORTUNE’s Most

Admired Companies

■ Qualcomm Real Estate and Facilities

▪ 600 + Employees

— San Diego

— Domestic

— International

▪ Unifier for Construction

Management

— 2008

— 400+ Users

— 80~90 active projects

Agenda

• User

• Group

• Project/Shell

Review Template Structures

• Project Permissions

• Document Permissions

Examine Complexities

Establish Best Practices

Objectives

■ Abstract: User, Group, and Template administration in Unifier can be complex

at best. Key to the successful implementation and ongoing administration of the

Unifier environment is a well thought out and systematic approach that includes

the consistent application of project and permission templates. This session will

explore how these templates can be established and maintained throughout the

system life cycle.

Objective 1: Understand the user, group, and project templates

Objective 2: Examine the complexities involved in managing project and

document permissions

Objective 3: Establish an approach for managing security & administration

through the use of standards & templates

Objective 1: Understand the user, group, and project templates

User Management

■ Company Workspace User Types

▪ Company User

— Created and Managed by Company Administrator

— Company Password Policy Applies

▪ Partner User

— Created by Site Administrator, Assigned by Company Administrator

— Default Password Policy Applies

■ All user accounts are initially created at the Company Workspace

■ User status at Company Workspace

▪ Active, Inactive, On-hold

▪ Controls access to system

▪ Inactivates in all projects

User Management

■ User Attribute Form

▪ Configure Company User Log

▪ Configure Partner User Log

▪ Add user data elements to

attribute form

■ User Preference Templates

▪ configure the default user

preference settings for new

users

▪ update existing users’ user

preferences options.

▪ establish a standard for user

preference settings.

User Management - Permissions

■ Two Categories of Permissions

▪ Access Control Permissions

▪ Document Manager Permissions

■ Permissions can be granted at

▪ Company Workspace

▪ Project/Shell Template

▪ Project/Shell

Permissions versus Access Control

■ Manage individual user or

group permissions in the

Permissions tab

■ Quickly view or adjust

permission settings for a

particular user or group.

■ Copy a permission template

to quickly set permissions for

a new user or group

■ Save an existing user or

group’s permission settings

as a new template

■ Displays the permissions

granted to all users and

groups per module.

■ You can add, remove or

adjust permissions for

multiple users or groups

■ Generate and print an Access

Information table summarizing

permission settings.

■ Updates group at working

level but not templates

Permissions Access Control

Access Control

User Management Company Workspace Permissions

■ Permissions are granted to users to allow them access to Unifier features.

■ A user can be granted permissions individually, or can inherit them from the group(s) to which the user belongs.

■ Users can be granted individual permissions in addition to group permissions. If user-level and group-level permissions are different for a module, the highest level will be granted to the user.

■ If you grant permissions to project or shell level User Mode features from the company-level Permissions tab, the new permission settings will take effect on future projects or shells

■ Permissions in a project or shell template from which the project or shell is created override Company level permissions.

User Management Project/Shell Template Permissions

■ Users are identified by their unique User ID.

■ Any Active, Inactive or On-hold users can be pushed.

■ If the user does not already exist in the shell, the user will be added

to the shell with the permission settings and group membership.

■ If the user already exists in the shell, the user information is updated

(replaced) with the user information as entered in the shell template.

This includes permission settings and group membership.

■ If a group that the user was added to doesn’t already exist in the

shell, the group will be added, and the user will be added to the

group. Group permissions are not updated; this is done by updating

groups.

■ If the group already exists, the user will be added to it. Group

properties and permissions will not be affected.

User Management Project/Shell Permissions

■ At a minimum, a user must be a member of the project/shell

■ Once added to a project/shell

▪ cannot be removed

▪ can be inactivated at project/shell level

■ Permissions can be:

▪ Granted on an instance-by-instance basis

▪ Pushed through shell templates

▪ Users can be managed through groups or added individually to

instances

Group Management

■ Groups are a way to collect Users together so that adding new team members to the project and assigning permissions can be done quickly and efficiently.

▪ members of the same project team

▪ share the same access control privileges.

■ At the company level, groups can span projects. At the project level, all members of a group are members of a given project.

■ Different members of a project may have different access to Unifier functionality, depending on their role on the project.

■ Company level groups cannot be copied into a project.

■ Groups cannot contain other groups

Group Management

■ As users are added to a Group, they will inherit the Group’s permissions. If they are in more than one group, then the highest level of permissions granted in any group for a module will prevail.

■ When adding users to the group, you can choose eligible users from the sponsor company and any partner company users. The company short name will be listed in the User Picker window next to each user.

Group Management Updating Groups

■ Groups are identified by their unique Group Name.

■ All group properties, including permission settings, will be added or

updated in the shells that you selected.

■ If the group does not already exist, the group will be created with

the permission settings. Group membership (user list) will not be

updated in the shell.

■ If a group of that name exists, the properties and permissions of that

group will be replaced with the new group, but not the list of users.

■ Users are not automatically added to the group; they need to be

added by updating users (group membership).

■ Changing a group name will update group in template, but will

create a new group when pushed

■ Groups cannot be pushed to Document Manager Structure

Project Management

■ Projects can be created

▪ Manually

▪ Template

■ Advantages to using a template include

▪ Ease of individual project setup

▪ Consistency across projects

▪ Ability to update project configuration

■ Challenges to using templates

▪ Multiple project types increases number of templates

▪ Potential for inconsistent configuration

Templates

■ Permission Templates

▪ All levels of permissions

▪ All modules

■ Can be copied in to

— Company Workspace

— Project/Shell Template

— Project/Shell Instance

■ Cannot be pushed

Templates

■ Templates used in Project/Shell Templates

▪ Cost Sheets

▪ Folder Structures

▪ Funding

▪ General Spends SOV

▪ Reports

▪ Rules

▪ Schedule Sheets

▪ Activity Sheets

■ Cannot update Project/Shell Instances

Templates Shell Template

■ Used to build shell instances

■ Users can be inactivated and removed

■ Holds BP Configuration(s)

■ Document Folder Structure and Permissions

▪ Assigned through

template users/groups

▪ Built at Project Creation

▪ Cannot be pushed

Objective 2: Examine the complexities involved in managing project and document permissions

Project Templates

■ BP Configurations used in

multiple templates

■ User permission changes

and user pickers

■ Permissions are difficult to

track

■ Cost and Schedule Sheets

are difficult to update

■ Create “master” template

■ Maintain group consistency

between stage and prod

■ Use User/Group Export/Import

to avoid overwriting group

assignments

■ Assign permissions only

through groups

■ Plan for consistency across projects – easier reporting

■ Plan for added business processes (logical sources)

Project Document Manager

■ Initial Structure and Permissions flow from template

■ Groups added to template are not added to projects

■ Folder/Document Permissions are not as granular – No “View Company Records”

■ Users need permission for auto publish

■ Build a comprehensive folder structure, lock first level

■ Create more generic DM-specific groups

■ Limit access to DM node or folders . View attachments from BP record

■ Provide “Add Document” permission for folders

Objective 3: Establish an approach for managing security & administration through the use of standards & templates

Managing User Accounts

■ Users should be assigned to groups at all levels

▪ CW, P/ST, P/S

■ Assign permissions at group level – not Individual

■ Use caution when pushing user accounts from Project/Shell Template

▪ Consider project-specific assignments that might be overwritten

▪ Use User/Group Assignments Export/Import where appropriate

■ User must have appropriate folder structure permissions to publish/autopublish documents to a given folder

Managing Groups

■ Maintain consistency across Company Workspace, Project/Shell Templates, and Projects/Shells

■ Leverage Permission Templates

▪ Create 1:1 relationship between template and group

— Update Permission Template

— Copy to Project/Shell Templates

— Push group permissions from Project/Shell Template

■ Plan any group name changes carefully

■ Use caution when granting administrative mode permissions

Managing Project/Shell Templates

■ Create only as many as you need

■ Create a “master” template for business processes

■ Maintain group consistency across templates

■ Update processes and permissions consistently

■ Plan Cost and Schedule Sheets with care

▪ Updates are possible, but challenging

Document Folder Structure Permissions

■ Plan shell and document folder structure permissions separately

■ Document Folder structure permissions may need to be narrower or broader depending on design

■ Create groups for

▪ Document Publishers

▪ Document Managers

Reports

■ Create common reports at report template level

■ Copy report templates in to P/S Templates

■ Push reports from P/S Template

■ Turn off report permission notification before push

▪ User preferences template

■ Apply User-Defined Reports permissions with caution

▪ Create = Create user-defined reports

▪ Full Access = Access to all UDRs created for the project,

regardless of owner. User can edit, change permissions, or

delete reports.

▪ Users with Create permission can generate UDRs against

records they cannot see.

Questions?

Contact Information

Greg Colf, Qualcomm, Inc.

Business Systems Analyst, Senior

gcolf@qualcomm.com, (858) 845-8915

Please complete the session evaluation We appreciate your feedback and insight

You may complete the session evaluation either

on paper or online via the mobile app