eProject is a Sohodojo Research Sponsor, find out more...

Sohodojo and Communities of the Future proudly host...
The Center for Community Collaboration Technologies
M2: Analysis of Comparable Project Planning/Management Offerings

M2 Section Summary: Role Support

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

Associated project: Specification Writing for Web-based Project Planning Software

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

sXc Project detail: http://sourcexchange.com/ProjectDetail?projectID=24 (SourceXchange is out of business.)

Project coordination: Sohodojo

Sponsors: Position open

Sponsors (M1-3): 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:

Note: The HTML versions of the deliverable use bullet lists with more readable prefix identifiers than the two-character source identifier used in the text versions.

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 [ All assessments, this topic ]

5.1 What is the 'person/role' model?

  • Enact Enterprise System [ Full data ]

    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.

  • eProject Express [ Full data ]

    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.

  • FastTrack Schedule [ Full data ]

    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.

  • ManagePro [ Full data ]

    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.

  • Microsoft Project 2000 and Project Central [ Full data ]

    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.

  • Opendesk.com [ Full data ]

    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.
  • SourceForge [ Full data ]

    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.

  • WebProject [ Full data ]

    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.
  • X-Community [ Full data ]

    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?

  • Enact Enterprise System [ Full data ]

    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.

  • eProject Express [ Full data ]

    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.

  • FastTrack Schedule [ Full data ]

    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.

  • ManagePro [ Full data ]

    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.

  • Microsoft Project 2000 and Project Central [ Full data ]

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

  • Opendesk.com [ Full data ]

    Functionality not supported.

  • SourceForge [ Full data ]

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

  • WebProject [ Full data ]

    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.
  • X-Community [ Full data ]

    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.)

  • Enact Enterprise System [ Full data ]

    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.

  • eProject Express [ Full data ]

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

  • FastTrack Schedule [ Full data ]

    By default, no.

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

  • ManagePro [ Full data ]

    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.

  • Microsoft Project 2000 and Project Central [ Full data ]

    Yes and yes.

  • Opendesk.com [ Full data ]

    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
  • SourceForge [ Full data ]

    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.

  • WebProject [ Full data ]

    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.
  • X-Community [ Full data ]

    Not applicable.

5.4 Reviewer Comments

  • Enact Enterprise System [ Full data ]

    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.

  • eProject Express [ Full data ]

    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.

  • FastTrack Schedule [ Full data ]

    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.

  • ManagePro [ Full data ]

    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.

  • Microsoft Project 2000 and Project Central [ Full data ]

    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.

  • Opendesk.com [ Full data ]

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

  • SourceForge [ Full data ]

    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.

  • WebProject [ Full data ]

    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.

  • X-Community [ Full data ]

    None

DOCUMENT HISTORY

Version 0.9 - Draft
Version 1.0 - Final

### end of sxc24-m2-02sect-comparables.txt (Version 1.0) ###


© 1998-2010 Jim Salmons and Timlynn Babitsky for Sohodojo except as noted for project deliverable and working documents. Our Privacy Statement
"War College" of the Small Is Good Business Revolution
Website design and hosting by Sohodojo Business Services,
A Portfolio Life nanocorp

Support Sohodojo, the Entrepreneurial Free Agent and Dejobbed Small Business R&D Lab exploring Open Source technologies to support 'Small is Good' business webs for social/economic development
[ Support Sohodojo ] [ Translate page ]
[ Search site ]

Sohodojo home

About Sohodojo

BIG IDEAS for small business

TechSIG area


CCCT home

Community Collaboration Platform Project

OSS Project Planning Project


LegalSIG area

Nanocorp reading

Links/Resources

Donor/Sponsor Information


Go to the Visitor Center

 Go ahead, we can take it... Give us a piece of your mind. Complaint? Irritation? Suggestion?
Tell us, please.