Collaboration use case best practices
Thanks for joining this session on the Collaboration Use Case. This session assumes that you have a good understanding of Jive and continues on from where we left off in the Information Architecture session. If you are new to Jive and have also not reviewed the Jive Basics and Managing Places sessions, please do so before this one.
The most important concept to understand about Jive is that collaboration can happen anywhere:
- Personal content
We recommend leaving the collaborative functions open to users to participate and collaborate wherever it makes sense to them, not just in specific places.
However, depending on your goal for creating a collaboration environment, it also sometimes makes sense to encourage users to collaborate in more formalised ways. That’s where this collaboration use case comes in.
Some variations of “directed” collaboration
- Team communication and collaboration: sharing meetings notes and discussing topics that are relevant primarily to this team
- Project management: this can range from Jive being the place where all project-related content is grouped together, to Jive being the place where collaboration and discussion happens even if the final project documents must live in another system
- Communities of practice: groups who come together around topics of interest. Sometimes called “centers of excellence”. These are groups where people across the organisation, no matter what department or location they sit in, can share best practices and tips and tricks, and ask questions of each other. These are mostly business processes or application topics like Agile Methodology, PMO, UX Design, etc
- Document collaboration: working on documents together in a closed environment before moving the final versions out to a more public place
- Affinity groups: these can be both company-sponsored or organically created groups around topics of interest that are less business-process-focused. An example of company-sponsored one might be a group for people interested in LGBT activities. Runner groups and sports club groups are also popular.
- Vendor or partner collaboration: using externally accessible groups allows employees to work with external people to share files and discuss things they are working on together
As a reminder, these are the types of groups:
- Public groups: All community members can participate equally in a public group - there is no membership aspect, but users can follow the group. Affinity groups and communities of practice are best created as public groups
- Restricted groups: Admins and selected members can create documents, blogs, and other content types. All other community users can only create a discussion or question or comment on other content. This is good for groups where document or blog creation should be controlled but you want the group to be open to everyone. An executive’s virtual office is a good example of how a restricted group could be used - the exec can blog - everyone else can ask questions and comment.
- Private groups: This is a closed group where members have to be approved by an admin. The name of the group is searchable but the content in the group can only be accessed by members of the group. Users can request access to the group from a request page. Private groups are good for topics that should be restricted but membership is open to those who fit certain criteria or is fluid
- Unlisted groups: This type of group is only known to members - it cannot be found in search unless the user is a member of the group. Document collaboration and team collaboration are good examples of where unlisted groups come in handy.
- Externally accessible groups: this is a special status where outside parties can have limited access to the community via this type of group. These groups are required to be either private or unlisted. This is where vendor and partner collaboration can happen within your community as outside users only have access to the content that is contained in the groups.
Recommendations for collaboration
You can certainly allow, and we recommend, allowing collaboration to happen in your storefronts by keeping the question and discussion content types enabled. But for places whose primary purpose is collaboration, we recommend using groups which are more egalitarian and easier to manage the membership of.
We also recommend allowing all users to be able to create groups. You may worry that you will end up with a lot of groups that are created and then abandoned. And you will - especially right after you launch. But if you limit who can create groups, you also limit the spontaneousness of a team being able to quickly spin up a group to start collaborating on a document. If they have to wait too long, they may just give up and go back to sending emails with attachments, leading to version control challenges.
Encourage group owners to leave their groups open unless they have a valid reason to close them. There is a big difference between “not interesting to other users” and “risky for others to see”. Of course, collaborating on a new HR policy needs to be closed - you wouldn’t want others to see a work in progress. But communities of practice and even some small team meeting groups can be left open. You never know when someone outside of your normal realm might be able to provide new insights and ideas! You may have heard of this concept: Working out loud! It can be a little daunting for some employees who are used to working in silos to get used to this idea, but the benefits far outweigh the challenges for the most part! Just keep working at it, and eventually you’ll see results.
Most groups can use the Activity page as the main landing page. Since the primary goal of these groups is to allow members to quickly see what is going on, the default activity stream on the activity page gives them the option to read and react right from the landing page. You can add calls to action and other tiles on the top and to the right of the activity stream. This makes it easier for group owners to take care of their groups and concentrate on the more important idea of keeping the activity in the group vibrant and up to date.
To combat the number of “dead” groups which can muddy search results, make sure you have a process in place to deal with them on a regular basis. Don’t wait a year and then review all your groups. Do it once a month or so so that it doesn’t become onerous!
Implementing the collaboration use case
We recommend starting with your own Jive community implementation team! Create a group in your community where the core team can work together on a project plan, tasks, etc. You can store your community structure and content inventory documents in this group.
Then identify at least one other group of people who you know have a need for a better way to collaborate. Possibly they are using a shared drive - and no one can access it from outside the office. Maybe they are using email to send a csv file around and keep updating the wrong version. Use them as your guinea pig to help understand the best way to use collaboration in your organisation.
Think about the different types of collaboration that are relevant to your company and create templates for them. (Creating templates is covered in Managing Places 2). Create guides and tutorials for group owners - you can even hold special trainings or lunch-n-learns for group owners.
Don’t try to create too much structure around group creation - this is where the organic growth of the community happens.
Thank you for joining this session today. You will now be well on your way to developing collaboration within Jive!