Using OG for Project Management Support

This article looks at Drupal's Organic Groups module configuration and access setting for a project management support scenario. I chose this scenario because it doesn’t naturally fall into the social media and networking conventions for which organic groups naturally fits. Drupal and many of its contributed modules are designed to work the way you want them to.

Scenario Goal

Imagine you are running a business with employees and consultants working together for a client. Your client has multiple people working on the project as well. Your business and client form a project team. Projects require communications and the exchange of information. Email is often used but does not create a sense of place where team members can go and see the project resources all together. You want to create a sense of place or a central repository where the project team can collaborate, share resources, learn what is happening, make decisions, report issues, and ask questions of the team.

Requirements

In this scenario, you create a section on your business website that will host project related groups. These are your requirements:

• Groups are set up by the contracts manager when an agreement has been made between the business and the client.
• The business can have more than one client.
• Clients might not want other clients and site visitors to know they have an active project, let alone see the posts associated with the project.
• The project has a start date and an end date so the group will need to be opened and closed at the appropriate time.
• Members are added to project groups by the business project manager.
• Members of one project team can be members of other project teams.
• The project will have team members that might come and go during the life of the project.
• Content shared in the groups should be placed in categories such as announcement, issue, question, or meeting.
• Members can use the group space to collaboratively write reports using a wiki page.
• It is assumed that resources and discussions on one project will not need to be shared across multiple projects with one post. If that need occurs, such announcements will be made to a Generic Projects group where everyone is a member and can share information that is not specific to one project.
• Private discussions will not be part of the group environment. The idea of project groups is for sharing. If there are issues that are “eyes only” in nature, those issues should be discussed and resolve offline and the resolution posted to the group.
• Team members will be notified by email when someone posts content to a group.

Getting Set Up

This is a multi-step process and assumes you have installed OG. The focus of this article is to consider OG configuration and access settings via a scenario. I will note other steps briefly. It is assumed that the scenario above represents a base-line for all project groups and therefore can be used to make decisions regarding the site level OG settings.

Roles and Permissions

In order to meet these requirements, you will probably want to set up a role for contract manager and project manager. The contract manager will need permission to create a group and user accounts. The project manager will need permission to add and/or approve group members as well as add users.

Taxonomy

In order to accommodate categorizing group posts, consider setting up a taxonomy vocabulary just for group posts content types.

OG Configuration

Group Posts: In order to support collaborative writing, a group content type will be created with the wiki setting. Another group content type will be created for all other posts. The standard posts and wiki posts can be organized using taxonomy terms.

Group Directory Control: The contract manager is the person who will create the groups.  Because some clients might not want their project listed for others to see, groups will not appear in the directory by default. When a project should be made available, the group creator can add the group to the directory. Once the group is created, the contract manager will add the project manager to the group and make him/her a group admin.

Registration Form Control: The need to have a generic group that all project team members can join means that the group creator needs to be able to decide if the project group should appear in the registration form. By default, the setting is no but the group creator can add a project to the registration form if the project is open to all site members. In our scenario, the generic project group will be available in all group registration forms (allowing two tasks to be performed with one step).

Audience Check Box: In order to limit inappropriate content sharing between clients, group members will not be able to include their group posts across projects. The check box is left unchecked.

Audience Required: Because this is a business site, posts made by group members should be placed in the group and not be part of the general site. Therefore, “required” is be selected.

Group Home Page View: The default home page view is being used at this time.

Messaging and Notifications: The default settings for this scenario are okay at this time.

OG Access Configuration

Visibility of Posts: In order to prevent group members from using the project group space for private discussions, the members will not have the option to make their post private. And because projects are not for public use, posts will only be visible with the targeted group.

Private Groups: There is a difference between private groups and private posts. In this case, because clients don’t want their business open to the public, group home pages will be set to private by default. Since there are projects that are open to all team members, the group creator will have the option to make the group homepage public. Note: a group that nobody knows about (not listed in the directory or registration form) might not benefit from a public homepage.

Managing Groups

In order to accommodate the need for project team members to receive notifications, the group creator and/or project manager can check the “Automatically enable notifications for any groups that I join.” box when they create a user. OG comes with several blocks that you can enable. Each block provides different information and access options for the group members. For this scenario, the only block active is the group details block. This enables group members to post content to the group and to see who is on the team.

Summary

The intent of this article was to think through the process of configuring a group site using requirements based on a scenario. The key is to make a list of what you want to be possible, be detailed. You may find that one requirement conflicts with another and compromises will need to be made. Good luck with your set up. I hope this helps.