Teams vs Groups

[Mohini__Mini_Si]

I'm looking for any information/advise on how Teams are different from Groups. When should Teams be used and when should Groups be used?

[KatherineHa1]

We use Groups to restrict access/security, and Teams for assigning work.

[DavidCo3]

The only thing I would add to this is that we have had to synchronise the naming of our Teams and Groups (i.e. Team A has a corresponding group of the same name). The reason we did this is because we needed to be able to filter down to the Team name in the Team Builder, however it only allows you to filter by the Group name....go figure! Hopefully we can un-wind this and consolidate the Group names once the new Resource Management and Scheduling tools are released with hopefully better filtering functionality.

[Mohini__Mini_Si]

Thank you Katherine and David!

[NRYNR]

Some things I've learned about Teams and Groups: Teams: can have issues routed to them in the routing rules of queue topics, and a "Team ID" field gets populated on the when this occurs. It gets cleard if you remove the team and name a person as the assignee. However, if you leave the team and add the assignee, then the team ID field remains populated. tasks/issues can be assigned to teams (all members get a notification) You can use teams to control access/sharing, just as you can groups. Teams can be managed (membership) by users in the tool without Admin or elevated rights. Groups: Projects can have a group (preset when a user creates a project based on the user's home group) People can have a group Issues and Tasks inherit the Group of the Project they're in Groups can now (or very soon) have sub-groups, which we look forward to testing. Custom Forms can have groups (allowing users within those groups access to add them) Custom Statuses (I believe) can be customized by Group. This is a feature coming to GA soon. Overall, we try to use teams for assigning work and groups for security and affiliation. However, we sometimes deviate and use teams for security.

[LindaWa]

we love using Teams. Groups are specifically managed based on the departments and for better security. Teams are for many efforts. ie: Approval Teams for various processes in requests/issues. Teams working on long term projects for ease of communication. Teams for sending Announcements specificially targeted.

[MelindaLa1]

I like to think of groups as long term building blocks. Departments, management hierarchy, slowly changing entities. Teams are dynamic and more ad-hoc. The Initiative X team. Cross-Department teams. Product teams. Etc. Teams are here today and gone tomorrow. Put together for a function and disbanded when no longer needed. Teams have a specific goal in mind. Groups build your company. Teams get specific things done. Melinda Layten mlayten@gmail.com Independent Workfront Consultant

[EricLu2]

Hi: I agree. We use Groups to model our organization. We use Teams to model the assemblages of people who get things done. Team definitions are generally transient, where Groups are perm (until we re-org). Eric

[Mohini__Mini_Si]

Hi Eric and Melinda, Thank you both very much. Those are very helpful descriptions.

[AnthonyIm]

Hi,

At LEAP, Audrey and Armen had a great graphic that might help you.

[MackMo]

Has anyone done any further investigation on groups vs. teams - potentially putting together a spreadsheet of the factors that each impacts? If so, would you be willing to share? Any help would be appreciated. Mack Moore National Heritage Academies, Inc.

[VicAl]

Per our consultant when we implemented almost 3 years ago, we use Groups as our Divisions (IT, Engineering, HR, etc.). This is how we can apply permissions to projects, reports, layout templates, etc. And now Custom Forms �� We use Teams as a team within divisions (though they have no true tie to the Division/Group). So within IT we have a PMO Team, a Helpdesk Team, etc. We use those to actually assign work to the team and their Backlog, and also to send directed updates to the team. Obviously we can also apply the above permissions using Teams as well. Vic Alejandro, PMP, CSM | IT | Sr. Technical Project Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT