9 Replies Latest reply on Oct 25, 2011 8:34 AM by disaacs

    Wanted your experience on why to enable groups and why not to


      Now that we can control private vs public groups (ie prevent private ones), we are re-looking at enabling groups.  I wanted to collect your experience using them to see what the advantage and disadvantages are.


      While initially, allowing any one to start a group and invite people sounds like it will off load that task form the community manager.  But that also means that a new task to clean out dead groups is added to the list.


      What have yo seen?  Do you get more usage and adoption?



        • Re: Wanted your experience on why to enable groups and why not to

          Gia Lyons has a great blog post on patterns and she documented some  of the key points of our decision in one of her blogs. The part 1 in her series reflects our thinking perfectly (we used  the "Emergent Approach (few Spaces,  many Groups)")


          http://www.giatalks.com/2009/09/jive-sbs-structure-best-practices-part-1/   <--- CSC used the "Emergent" Approach described here


          http://www.giatalks.com/2009/09/jive-sbs-structure-best-practices-part-3/  <--- CSC's lobby pattern is referenced in this blog here


          CSC's Emergent Approach

          At CSC we opted to avoid any policy that would inhibit or be a barrier to emergent collaboration. That meant out of the gate, we did not allow spaces to be set up. Instead, we allowed users to create groups in a self-service, on demand way. We don't dictate or approve  whether someone 'ought' to gave a group. This gets IT out if the business of setting up or second guessing the approval process of  spaces, which can be time consuming and a barrier to collaboration when  your users want it.


          We have a collaborative culture and have allowed self service long before our Jive platform came along. So we knew how to do this well. We knew we needed good "group manager" terms of use and we knew rather than being a gate keeper - we needed to be good group gardeners (watch for old sites, ask and nudge to close down dead groups). We also knew that we didn't need to worry too much about whether there  was duplication, we let our users influence each other.


          Trade offs? Like I mentioned above, as as Gia describes at lenght, instead of investing in being a gate keeper, you  need to invest in watching patterns and weeding out old groups. To me, I'd say your users prefer you to do than  get in their way.


          Over time - at a 90K employee company it's interesting to see how little patience folks have for redundant spaces. We see the community self policing itself and encouraging groups to merge where there are like topics. That doesn't mean there's not duplication. I feel (and we've seen), sometimes your members will vote with their feet even  inside your tool.  So the vibrant communities will surface naturally, and  the others will  wither. As a program lead- try to be patient and let  the crowd decide  (think survival of the fittest here - and let natural  patterns emerge).


          Hope that helps!

            • Re: Wanted your experience on why to enable groups and why not to

              Thanks.  I was wondering about training and “help”.  In a self service model, if the expectation is for minimal training, it would not add an extra demand on the community manager.  Have you seen the need to train or at least provide some overview?  I was also wondering if people that were not familiar with what can be done or how to use the features and functions could end up spreading negative comments based on  a bad impression.



              From: cflanagan17 communities@jivesoftware.com

              Sent: Wednesday, April 14, 2010 5:52 PM

              To: Crocker, Michael

              Subject: New message: "Wanted your experience on why to enable groups and why not to"




              Wanted your experience on why to enable groups and why not to

              reply from cflanagan17 <http://www.jivesoftware.com/jivespace/people/cflanagan17> in Internal Collaboration - View the full discussion<http://www.jivesoftware.com/jivespace/message/384130#384130

                • Re: Wanted your experience on why to enable groups and why not to

                  Ah you raise more good questions and points.


                  Truly, I give full talks on this And Jive has a professional services engagement team that can help you with deciding best practices for you.


                  However, here's the short summary (until I actually get around to writing it up on my public blog):


                  • Yes you need to think about enablement
                  • You can locate/find champions or advocates (before launch) and consider them part of your extended team
                  • You do need to think about posting help materials (again see part 3 in Gia's series where she describes some of the things we did in using a "lobby" for guiding users through the space
                  • You do need to think about seeding use cases ---> so that it's obvious what users should do. When it's obvious - and there are good business samples - users just start reading and clicking
                  • You do need to think about webinar series, training video bites, email communications, good support desk enablement, etc


                  So basically, you still need to do all the good things you would normally do for training and support. BUT if you get an extended team involved with you, and really think of how to leverage them, support them and get them excited early, they can be your killer weapon in going wide and going viral.


                  In our case 12 "champions" brought on board 110+ early advocates who helped us "seed" 200+ groups for business before our launch. These advocates were also so jazzed about the tool, they supported new users when they asked questions in the "Give Feedback" space. Peer to peer support proved to be powerful - and addictive. When users got their questions answered right away, they continued on in the site and got more users invovled.


                  There are so many ways you can thinking of finding advocates, leveraging them and working with them.


                  Stewart Mader has some great material on people adoption patterns. If you haven't do so yet, take a look at Wiki Patterns http://www.wikipatterns.com/display/wikipatterns/Wikipatterns

                  • Re: Wanted your experience on why to enable groups and why not to

                    Hi Mike -


                    Here are a few things that have worked well in our community which is an employees/partners/customers community.  Self-service and distributed administration are key to our system but we do have some direct training and we certainly did more of that when the system initially kicked off 4.5 years ago.



                    1. We have either in-person or web session training for all "leaders" in our spaces.  These are the people responsible for the health and quality of the area as well as the home page and membership to the area.  These people have domain knowledge and answer questions and participate directly in their area.
                    2. We have a Help space that contains documents, videos, FAQs etc. about using the system.  We present the Help area via a Getting Started graphic on our home page and a persistent graphic near the search box.  Coming in our next deployment will be a feature where users are presented with a Getting Started video on their first login to the site (after they accept a usage agreement).  Users can post questions on how to use the system in the Help space and there is a link on the main page of the system for "Ask a question about how to use the Mesh."
                    3. In our Help area we also created a small image library that people can use to help with wayfinding in the system.  This area has images for things like "Start Here", "Roadmap", "Documentation", and status oriented images.  We've made it easy for people to use the images in their pages so we have some consistency in how people find certain kinds of information - even though all different teams present the information.
                    4. We have a space called "Sandbox" where everyone in the community has full permissions.  The area tells them this is "the place to play and try out system features".  I think this has helped prevent a lot of bogus Groups being created by people who are just curious about how to do things.  It also allows people to create and delete content in a "safe" place if they just want to get comfortable with the editor or adding images or whatever.  I monitor this space but there has never been any abuse.
                    5. We have established patterns for our space home pages as well as what we call "landing pages".  The patterns evolved organically - they were not dictated.  Teams are not forced to follow the patterns but most do as they like to know what to expect as they navigate around from space to space.  We use space home pages to guide users to content and also present the latest status on things.  The space leaders are responsible for determining what is important to guide users to from the home page.  A "landing page" is usually a document that summarizes and gives higher level information on a large topic.  It also has links to other relevant content on that topic.  These have been considered very useful for people trying to get a comprehensive understanding of something.  Most of our spaces and home pages present information from both a time-based perspective and a topic/feature based perspective.



                    Have a great weekend!

                  • Re: Wanted your experience on why to enable groups and why not to

                    Hi Claire!

                    This "lobby pattern" is a simple but compelling approach that I've started to see develop  organically in a few corners of our internal community.  From a navigational/organization perspective, have enountered (and/or documented) any disadvantages or considerations related to that approach?