Managing Workspaces

From Projectivity Documentation

Go back to workspace help section

Contents 1 Overview 2 Assigning Resources 3 Roles 4 Artefacts 5 Responsibilities

Overview

If the user has owner access level to a workspace (see Workspace_Permissions), he/she can manage it by:

• editing the workspace metadata attributes
• creating a sub workspace
• deleting the workspace

These commands are available (if the user is Owner) from the "Manage this Workspace" menu.

• Create Workspace allows to create a workspace under the currently selected one. The user is allowed to create workspaces of the types that are mandated by the framework. The selected framework type might also lead the creation of a set of nested workspaces in order to enforce a common structure. For instance, creating a Phase might also create a set of standard Activities under it.
• Edit Workspace allows to edit the workspace metadata attributes.
• Delete Workspace allows the deletion of a workspace. The user is warned that this operation is irreversible.

Assigning Resources

If the user has owner access level to a workspace, he/she can manage the resources by defining:

• the resources assigned to it
• the resources access levels
• the resources work roles
• the assignment load (for dynamic workspaces)

These commands are available (if the user is owner) from the "Manage this Workspace/Manage Resources" menu.

• Assign Resources and Roles allows the user to specify the set of resources assigned to the workspace and their work role (click here to have more information on work roles). The user can only assign the resources that are already assigned to a workspace he/she has OWNER access level on. This allows to limit the user to use only the resources he/she was explicitally given.
• Edit Access Levels allows to specify the access level for each assigned resource(s) (click here to have more information on access levels).
• Edit Resources Load (available on dynamic workspaces only) allows the definition of the resource load. For instance, given an activity that spans from 2/7 to 7/7, the activity manager, i.e. the user that owns it, could specify workloads as follows:

1. 25% from 1/1/ to 15/1
2. 50% from 16/1 to 31/1

This workload definition affects the resource's available work time. When a resource is allocated on parallel activities or to more than one project this feature easily allows to check if the resources are overloaded making the plan non realistic.

Roles

When a resource is assigned to a workspace, he/she can be given the roles that are defined by the workspace type.

Each workspace type allows to:

• Define its own roles
• Declare the usage of roles defined in other workspace types
• Set the cardinality of roles, i.e. how many resource(s) can be given a specific role
• Define autoassignment rules

Let's take the following, easy-to-understand, example.

A Project Managment Framework defines two workspace types: Project and Activity. Activities can be created under Projects.

The Project type defines the following roles: Project Manager (cardinality 1.1) and Project Team Member (cardinality 0..*).

The Activity does not define any role but uses the two Project roles. It also defines that the resources with role Project Team Member at Project level should be automatically assigned to itself.

When a owner user assigns resources to a workspace of type Project he/she can specify the two roles. As a direct consequence of the autoassignement rule, when a resource is assingned to a Project with Project Team Member role, he/she will be automatically assigned to any Activity under it.

Artefacts

The framework defines the default document structure of each workspace type.

This means that when a workspace is created, its corresponding document repository is automatically organized on the basis of a well defined rule. Folders are created and populated with document templates.

This allows the standardization of the way documents are organized thereby leading to a value-added documents repository.

Responsibilities

Responsibilities are used to define what each role should take under control.

Responsibilities can be defined against both workspaces and documents.

An effect of a responsibility is that the system automatically notifies the user in role via email of any business event on any controlled entity.

For instance, if the Project Manager role is given the responsibility of the Requirements document, the resource(s) in role Project Manager will be notified via email of any changes made to this document.