2 people found this helpful
We tried to look at it from two different angles: (1) open vs. restricted places and (2) groups vs. spaces in terms of feature differences.
For the first condition, we wanted to promote as much openness as possible so we set our Jive instance up so that anyone can create an open or members only group on their own, but if they want a private or secret group or space they need to fill out a short form providing name, purpose, admin, etc. and then we create it for them. (Of course, once they have a space they are free to create their own subspaces which has been the one flaw in our process ). The form does two things. It acts as a speed bump that causes some people to rethink their security concerns and go with an open group immediately rather than take the little extra effort it takes to fill out a form and wait. It also gives us a chance to look at existing spaces and groups before we create a new one to see if the requester can work within an existing one. We have never directly turned down any requests but we often connect the requester with the admin of an existing group or space to see if they fit, which happens around 30-40% of the time.
Groups vs. spaces is a little murkier. We don't have any hard and fast rules, but we have some training documents that outline the key differences. The main attractors for people wanting spaces are that either they need different sets of permissions because they are "official" spaces where only a few people create content and everyone else reads it, or they need to use user groups to manage access. We have a number of R&D groups who collaborate on new products in spaces, and so they need to provide access to hundreds of employees but not everyone. It's a lot easier to manage the access list as an LDAP group that is synced with Jive than to keep track of all those people individually.
Our biggest problem is people who think "subspace = folder" and go crazy creating subspace hierarchies with only a few docs in each subspace. (You know you're in trouble when you see subspaces titled Jan 2014, Feb 2014, Mar 2014, etc.) I think this will clear up over time but it's taking a lot of education and reiterating of best practices for a user community whose prior experience was mostly shared drives, eRooms, and other folder-based systems.
Thanks Dennis! Awesome information! We chatted briefly at Jiveworld14! Good to talk to you again.
Hi Barbara - here is how we work -
Spaces - are created only by community managers, and must be 'wide open spaces' - meaning all are open; we actively discourage subspace creation; and yes, we do get the 'subspace = folder' or 'subspace = page navigation' issue too! Categories are your best bet.
Groups - anyone in our organisation can create a group for any reason - business, social, operational, and there are no restrictions on this. We do need to get more in the habit of tracking these, to make sure that they are being maintained.
In terms of one frustration you will find - Jive only reports on those who created the group, rather than the current owners, which makes it difficult to communicate with Group owners. We are working on this with Jive, and will let you know if they come up with a a solution. The workaround is to have the group owner create the group, so you don't have a lot of groups in admin ownership.
We have a very similar set up. We did find that people ignored our guidance
on not creating sub-spaces. To overcome this we have a space request
procedure and any spaces created without prior approval are deleted.
We could do with taking some time to prune the groups but it hasn't been a
priority our large number of groups is because one training tactic we have
suggested is for people to have secret groups to test in, play around and
generally get comfortable with being a group/space admin.
On 29 Oct 2014, at 10:09, Tanya Burak <firstname.lastname@example.org>
1 person found this helpful
Employee Facing Guidelines
Our process is fairly simple, all initial spaces and groups are created through our central team to prevent duplication and to ensure applicability. A simple form allows them to request a group (They can specify open, members, or private.) If our team notices special circumstances in the comments or description, we'll consider creating a space. Similar to Dennis's point above, we lock try not to create spaces so that we don't run into the "a Subspace is a page/folder" dilemma.
Internal Team Guidelines
We provide some general guidelines to our team to help them qualify whether or not a place should be created. The content below isn't a legal or compliance snippet, just some questions we thought would make sense to ask.
Does this place...
- Solicit employees for money or donations?
- Attempt to sell personal or company owned property?
- Encourage gambling or solicit bets from other employees?
- Have a religious, political, or negatively racial motivation?
- Promote racial, religious, political, or otherwise negative intolerance towards others?
- Provide little to no business or culture building value?
- Share private, confidential, trade secret, or proprietary information?
- Share customer data or personal information?
- Violate the company's Social Media Policy or the Jive Community Usage Policy?
If the answer to any of these questions is "Yes" the place should not be created. If you are unsure of any of the answers, please contact the Enterprise Community Manager.
As Dennis Pearce mentioned we have a form that users complete to request a group/space. When I created the usage guidelines, I borrowed heavily from Melissa Rosen Best Practices: Creating a Group/Community
We use that type of document to help users evaluate what type of place they want and then added a link within the document to complete the form.
In addition what has been said,
We looked at this from a slightly different perspective. Spaces were used to support hierarchy, these were aligned to the organisational structured and created 2 or 3 levels down as part of the "seeding". Space owners were trained in their responsibilities and their freedom. We also gave them (albeit later) a space template. That ensured the layout of spaces was consistent to a degree as people started to complain about usability when common elements were moved to different places on the screen or removed altogether. We adopted an open policy from an access point of view and only had a secure space when the content required it.
Groups on the other hand were for cross functional activities or time limited ones. Everyone can create a group. Similar to spaces we provided a template although this was optional. And Group owners could opt into a special training session, too. Our biggest challenge was and is, tracking groups in respect to double ups, "dead" ones, and groups where the owner left the organisation.