PROJECT PLANNING/MANAGEMENT TECHNOLOGY REVIEW - SECTION SUMMARY

SECTION: Role Support

Copyright (c) 2000 Jim Salmons and Frank Castellucci
All Rights Reserved

Associated project: "Specification Writing for Web-based
		    Project Planning Software" (sXc ID: 24)

Project URL: http://sohodojo.com/techsig/project-planning-project.html

sXc Project detail: http://sourcexchange.com/ProjectDetail?projectID=24

Project coordination: SourceXchange

Sponsors: Opendesk.com and Collab.Net

Core Team: Jim Salmons and Frank Castellucci


1 Introduction

	This document aggregates the feature and underlying model analyses of
comparable products and services in the domain of the project specification
requirements. During the comparables analysis phase, nine product and service
offerings were examined.

1.1 Format and Key to Abbreviations

	Each of fourteen sections of the Comparables Analysis Data Capture
Outline has a Section Summary file such as this one. Section 1 of each data
collection form is an Introduction statement explaining the project and the
assessment. Section 16 is a reviewer profile. Since all data was produced by the
core project team members, section 16 does not have a summary section.
	
	In a Section Summary file, we aggregate the analysis data within each
subsection of the raw data collection forms. Each data point from the raw
assessment outlines is presented in the following alphabetical order and
prefixed with the following identifying abbreviations:
	
	EN - Enact Enterprise System 4.2 by Netmosphere/CriticalPath
	EP - eProject Express by eProject.com, Inc.
	FT - FastTrack Schedule 6.04 by AEC Software Inc.
	MP - ManagePro 4.0 by Performance Solutions Technology LLC
	MS - MS Project 2000 by Microsoft Corporation
	OD - Opendesk.com by HBE Software
	SF - SourceForge by SourceForge (VA Linux)
	WP - WebProject by Novient
	XC - X-Community by X Collaboration Software Corp.

	The aggregated section data in each Section Summary file is the last
section of the file. In addition to the aggregated data, each summary file has
an optional section for the capture of summary insights or comments.

1.2 Section Summary Insights and/or Comments


====== SECTION SUMMARY DATA ======


5 Role Support

5.1 What is the 'person/role' model?

** EN **
	Enact has a relatively rich Person/Role and Organization/Group model.
Persons in Enact are what would generally be called Users other systems. A
Person is a relatively 'thin' model element. In addition to the username and
password, a Person's properties include an Organization affiliation, a
description, email address, cost per hour, work calendar and settings for
whether the Person can manage Enact user accounts and/or assign tasks to users.
	
	The ActionAdmin tool manages both Users (Persons) and Roles. The Users
tab presents a view that manages Person, Group, Organization and Alias model
elements. The Roles tab presents a view which maintains the Roles defined
globally in the Collaboration Server Workspace.
	
	Role model elements are relatively light-weight with a Name,
Description, Comments and Cost Per Hour attributes.
	
	Enact has a relatively simple and effective mechanism for handling
Person assignments to Roles within ActionPlan. The Project Planner is encouraged
to create plans with assignments abstracted to Role assignments. When a Task's
People field is edited in ActionPlan, a multi-select drop-down combobox presents
items clustered by Persons, Roles and Other Users (which is a button to pop up
the LDAP interface for accessing Users. The drop-down list includes a 'percent
involvement' text input for each Person or Role assigned to the Task.
	
	When a Project goes 'live' and then throughout the life of the Project,
the Project Manager uses a simple dialog view to associate Persons to Roles. One
or more Persons can be associated with each Role. For each Person assigned, a
'percent involvement' attribute is maintained. This underlying model allows
multiple Persons to fill multiple Roles with varying degrees of involvement in
each.
	
	Role/Person associations are made at the global Project level. You
cannot assign many different Persons to specific Task/Role assignments.

** EP **
	In a word for this release, minimal. There is a very limited sense of
Roles, being Team Member and Project Manager roles. However, the assignment to
either of these 'roles' has few implications in the current implementation. Team
Members can create and 'manage' Projects. The Team Member's 'Person/User'
Directory is limited to new entries he/she creates within this 'scope'.

	In addition to the 'explicit roles', there are 'implicit roles' that
Person/Users dynamically assume as they create tasks, create document resources,
create events and messages, etc. For example, a Task has a Task Author and a
Task Assignee. In the same way, there are Document Owners and Editors.

** FT **
	If you create a new, 'clean slate' schedule (that is, don't use any of
the numerous template 'starting points'), Activities have a 'Responsible'
attribute (field in the default database representation of the graphical
schedule). In earlier versions, it appears that this default field was called
'Manager'. The more general 'Responsible' allows users to think in terms of
manager responsibility or the more fine-grained team member 'work assignment'
responsibility.
	
	FTS does not have first order Persons or Roles. FTS is
'project/activity'-centric.

** MP **
	There are no Role model elements as part of the default underlying model
of ManagePro; Goal/Subgoal/To-Do (G/S/TD) elements are associated with one or
more People (Person/User) 'instances'. The default associations that can relate
G/S/TD elements to People include 'Assigned to' (Who), 'Show to', 'Editors'
(those with 'write' access). Users can define additional associations that
relate People/Users to G/S/TD elements.
	
	The reviewer is 'role-oriented' and has used customized ManagePro
configurations to give a role-based flavor to this solution. ManagePro's
configurability allows users to redefine terminology used throughout the
program.
	
	The 'Relationship' field of Person/User records includes a number of
typical terms to relate People to Goal-oriented elements; Self, Direct Report,
Boss, Peer, Customer/Client, Vendor/Supplier. These terms can be changed,
deleted and expanded. By adding a 'Role' term to the Relationship term list, you
can create 'shell People' which give all the filtering, context views and
'discrete assignability' that an 'actual Person/User' has. The Project Planner
then can build a plan around Role abstractions that help structure the plan in
ways that direct Person assignments lack.
	
	In the 'Few Heads, Many Hats' management dilemma of a very small
business, where few people fill many roles concurrently and sometimes sharing
loads in 'informal load-leveling', this can be a very useful configuration.
Since ManagePro supports one-to-many associations for its People-associating
fields in its Goal elements, the Project Manager (or a shared self-organizing
'what needs to be done now' assignment procedure) can add 'Joe' or 'Jane' to a
Role-assigned Goal to indicate that a 'real Person' will be the Actor of a
specific Role assignment.
	
	For example a To-Do, 'Mail press kits', might initially be assigned to a
'Campaign Manager' Role. When 'Jane' accepts this assignment, the Who field
maintains the two-element list, 'Campaign Manger; Jane'. (By resisting the
temptation of replacing the Role name with a 'real Person/User' name, you
maintain the 'Role-context' views which would be diluted by assignment
replacements; IOW, the Project can still be looked at through 'Role abstraction'
pseudo-Person/User views built into ManagePro while the actual Users maintain
all the Person/User-specific views which help to organize and facilitate their
specific work assignments.
	
	Since ManagePro does not provide advanced 'resource overload or
load-leveling' features, these double assignments are not problematic. But since
the Role 'objects' are Person/User data records with a 'meta-meaning' within the
customized context, some of the advantages of separately modeled Role model
elements are lost.

** MS **
	There are four (4) general roles defined in the tools:

	* Project Manager - responsible for planning and scheduling and for
 	maintaining the project plan.

	* Team Members - workers identified as resources within the project
 	plan, with the primary goal to deliver on commitments.

	* Resource and Team Managers - those responsible for assigning resource
  	to a project or to a summary task within a project and/or assessing
  	organizational staffing needs. In addition, the tools provide features
  	that enable assignment and delegation of work among functional teams
  	in support of a larger, multidisciplinary project.

	* Senior Manager/Stakeholder - anyone with an interest in the status
  	of one or more projects accross the enterprise.

** OD **
	Opendesk predefines two (2) roles in the system:
	
	1. Administrators - All privileges of other user types. Granted full
	  access to both project data and project configuration, as well as
	  creating new users.
	
	2. Users - Can modify only personal data, calendars, files. Can
participate
	  in group discussions and e-mail other intranet users.

** SF **
	SourceForge pre-defines four (4) roles:
	
	* Project Administrator - Can administer all aspects of the project.
	
	* Technician - can be assigned Bugs, Tasks, Support and Patches
	
	* Tool Administrator - All the permissions of Technician, and can
administer
	  changes to the specific tool area where assigned.
	
	* Editor - Can update, edit, and remove documentation in the
Documentation
	  Manager.
	
	These assignments are set for individuals that are part of the project
	team. There is no notification given to the person(s) when their roles
	change.

** WP **
	WebProject predefines four (4) roles in the system:
	
	1. Administrators - All privileges of other user types Granted full
	  access to both project data and project configuration, as well as
	  creating new users.
	
	2. Leaders - Project managers or team leader access. Leaders are limited
	  to manage users that meet Group and RBS codes that it has been granted
	  authority over.
	
	3. Team Members - Can manipulate tasks that it is assigned, participate
	  in discussions and chat, as well as configure it's own calendar.
	
	4. Users - Can be assigned to projects but cannot access the tools or
	  projects themselves.
** XC **
	The X-Community offering is Person/User-centric. There are no explicit
Roles in the basic feature set. See MS Project for more in the case where MS
Project integration is used.
	
	While there are no modeled Roles, per se, there are three User Types
that are a kind of implicit role assignment. An X-Community Member has access
privileges to a Business Center and is eligible for assignment to Teams in that
Center. A Center User can be one of the following types:

	* Administrator – Able to access all information units and able to
change the following business center parameters; Center users, User groups,
Search tags, Workspace types

	* System Users – Able to access units where they are Team Members, they
can be assigned read/write or read-only access.

	* Guest Users – Able to access units where they are Team Members on a
read-only basis (cannot be given read/write access).

	The Person creating a Business Center is automatically designated an
Administrator and invites other X-Community Members to use the Center.


5.2 How are 'person/role' elements related to 'organization/group' elements?

** EN **
	Organization model elements are composite elements that allow you to
create 'Organization/Sub-organization' hierarchies. Persons are associated
one-to-one with Organizations. Alias model elements create an Association
between a Person and Organization. Aliases allow Users to more flexibly reflect
the matrix and otherwise dynamic relationships which relate Persons with
Organizations.
	
	Groups are 'non-organizational' collections of Person/Users.

** EP **
	Person/Users are created as either Project Manager or Team Member roles.
This assignment is made within the User Management subsystem. But as described
elsewhere, this 'role' assignment is of limited implications.

	Organizations do not apply at a model level. In the Person/User data
record, there is a field for the User's company/organization affiliation. It is,
therefore, a 'thin' one-to-one element in this release.
	
	There are Groups which are subsets of Person/Users. Groups can be
applied to assignments of Events and Documents. Groups are NOT assignable to
Tasks. (I thought this might be a 'work-around' for the current limitation of a
Task being assignable to only one Person/User.

** FT **
	Simplicity rules here. The default schedule has no organization/group
model elements. However, FTS is highly configurable and extendible. Scripting
interfaces, built-in computations, hyperlinking, etc. allow the user to tailor
FTS to his or her conception of what a project is and how it works. So, in a
sense, you can add virtually anything you want in terms of data associated with
activities and projects. However, such extensions are not the same as having
these 'strategic elements' of the problem domain represented as first class
model elements.

** MP **
	Person/Users are rich, configurable data records as far the underlying
database model is concerned. The default configuration assumes that Person/Users
have a one-to-one relationship to a 'Company' or Organization. No separate model
element is maintained to represent Organization elements.
	
	Groups are named, arbitrary collections of Person/Users. The Project
Planner/Manager has complete freedom to create Groups to organize or cluster
collections of Team Members. Once created, the People 'data cloud' becomes a
hierarchically-organized network data structure; individual People/Users are
always at the 'top' level but may also appear in one or more 'sub-levels' of
Team organization. Teams are a bit awkward because they are collections of
elements that 'look and feel' like an element of the collection. This makes the
'behavior/use' of Teams consistent with Person/User elements, for example, you
can assign a Team to the 'Who' field for performance responsibility. This single
Team assignment 'propagates' the assignment to the views/reports for each member
of the Team, so there is certainly a convenience factor to it. But the logical
modeling contraction (is it a thing or a collection of things?) can lead to user
confusion and limit extensions where the two elements would need to be treated
independently.

** MS **
	Through resource groupings, resource pools, enterprise codes, and custom
fields.

** OD **
	Functionality not supported.

** SF **
	Outside of the pre-defined roles, the functionality of organizational
roles are not supported.

** WP **
	When preparing the WebProject server for use, there are various
configuration codes that are used to define organizational elements into the
system, the three (3) primary codes are:
	
	1. Group Codes - Organizationally specific codes used to describe a
	  particular department/group/team that is populated by a given
resource.
	
	2. Resource Breakdown Structure (RBS) codes - A unique identifier given
	  to each resource to define people (labor), materials, goods, CPU,
	  etc.
	
	3. Types - defines a organizational type that can be used for filtering
	  and reporting.

** XC **
	There are no Organization model elements although a Member's
organizational affiliation can be maintained as a data attribute of the member.
	
	Collections of Center Users can be added to a User Group which can be
assigned in the same way as a Member to Information Unit (Whiteboards and
Notecards) Teams.


5.3 Can one person fill many roles? Can one role be filled by many persons?
  (resource/skill pools, etc.)

** EN **
	The Project Manager uses a simple dialog view to associate Persons to
Roles. One or more Persons can be associated with each Role. For each Person
assigned, a 'percent involvement' attribute is maintained. This underlying model
allows multiple Persons to fill multiple Roles with varying degrees of
involvement in each Role.

** EP **
	No. But as mentioned, roles in the current release are more like 'Access
Permission Level' assignments rather than Roles.

** FT **
	By default, no.

	But again, as Picard says, you can 'Make it so' in that FTS encourages
customization.

** MP **
	Well, by default, no, since there are no built-in Role model elements.
But using the 'Role as Relationship descriptor' extension discussed a section
5.1, yes, a Person/User may play many Roles.

** MS **
	Yes and yes.

** OD **
	Yes, the Administrator can assign administrator control over the various
tools in the applications list. Applications include:

	* All Applications
	
	* News
	
	* Polls
	
	* Contacts
	
	* Educational Expenses
	
	* Office Supplies Request
	
	* Company Directory
	
	* Group Discussions
	
	* Check Voucher
	
	* Expense Report
	
	* Purchase Order
	
** SF **
	On a per tool basis in the context of a project, one member can have
different role access based on the tool areas. So, while a person can be the
Administrator of the message forums, they may only be the Technician for
BugTracking. There is no organization of resources.

** WP **
	Yes, there are a number of ways this is supported:
	
	1. When creating the user profile, they can be marked as User, Team
	  Member, Leader, or Administrator, which can be combined.
	
	2. Leaders can authorize a Team Member to be the leader of a summary
	  task. A summary task is a composite of multiple tasks within its
	  group.
	
** XC **
	Not applicable.


5.4 Reviewer Comments

** EN **
	While Role objects are rather lightweight model elements, they provide a
very powerful abstraction within Enact. Some system use Roles as placeholder
assignments until a Person is allocated to the Task. Once this substitution is
made, the Role/Task association is lost. Enact, on the other hand, preserves the
Role assignment and provides a rich 'many-to-one' and 'percent involvement per
actor' dimensions to these model elements relationships.
	
	Starting point Project plans with Role-based Task assignments provide a
very nice template system to increase project planning productivity.

** EP **
	It will be interesting to see what the 'second generation' Express
offering is this Fall. At present, the current design limitations make the
Express service of limited value in a complex domain, like software development
project planning/management.

** FT **
	Don't look here for insights into modeling Persons, Roles, Organizations
or Groups, etc.

	FTS excels in the intuitive, graphical construction and presentation of
time-oriented descriptions of projects. Persons, Roles, Organizations, Groups;
all these things are relegated to optional, user-configurable data fields to be
associated with Project Activities. So, we don't look here for insights or
inspiration regarding the implementation modeling of these model elements.
	
	However, when it comes to easy-to-use UIs related to the graphical
display of time-related data, FTS is a fountainhead.

** MP **
	Just like AEC's FastTrack Schedule, ManagePro makes some simplifying
assumptions to remain a practical and useable solution. In this case, ManagePro
puts Person/User 'bandwidth' requirements outside its domain. While ManagePro
provides configurable constraints on the work schedule for date-related
computations, there is no built-in resource assignment conflict detection or
load-leveling features. This is due to its design-point of being a
goal-oriented, people-centric tool rather than a full-featured 'project
management' tool.
	
	It seems ironic to say that ManagePro ignores Person/User assignment
conflicts and overloading issues yet is still 'people-centric'. This is because
the People-strengths of ManagePro are oriented around communication and
facilitating 'people management' through collaboration exchanges. The built-in
tools structure performance reviews, issue management, skill development, etc.
rather than provide 'nameless, faceless' resource management features such as
load-leveling.

** MS **
	While there are no suprises here, the addition of the Project Central
fully facilitates the inclusion of all stakeholders of the project(s) across the
enterprise and user community. This is essential functionality. But this also
emphasis the need for more intelligent role modelng and support for
internet/extranet access on a global scale.

	While the Project 2000 roles are clearly fundemental to project planning
and status, and the many "types" of these that truley exist, roles such as
analysis,and design and requirements are but a taste of what else should be
considered.

** OD **
	The lack of recognizing that even a small business concern (the
marketing identified target audience) has roles defined in their organization.

** SF **
	SourceForge, historically, has had more of a project management as it
relates to the implementation phase of development, rather than a project
management as exists across the full life cycle perspective. The staff is making
changes to enable more useful features for the latter, but there does not seem
to be an indication that SDLC Roles are being addressed.

** WP **
	While I would have liked to see Role modeling, where the access levels
of one 'role' can be extended and specialized, they have provided at least the
flexibility of copying existing definitions, which reduces setup time.

** XC **
	None

DOCUMENT HISTORY

Version 0.9 - Draft
Version 1.0 - Final
 
### end of sxc24-02sect-comparables.txt (Version 1.0) ###