1 person found this helpful
Long time! I hope you're well.
Looking back, I'd say that Criticalmass' CM1 community did both. We spent a lot of time considering what the "1" was all about and it was definitely a GSD community but ALSO the voice of the company.
1.yes, CM1 was that. I think it really started as a GSD but also had the messaging aspects of comms.
1.2. I know this might put some managers into a stroke but we did most of this by using spaces. The GSD stuff was definitely designed with hierarchy in mind so navigation could be easy. "Work" was put in spaces, "Culture" in groups. That allowed us to really make messaging rules and engagement points.
1.3. The GSD didn't really face many challenges once adoption was done. After all, it's about GSD. The biggest challenge was the dilluted argument: if CM1 did all this so easily what was the value. That was really hard to answer and resources played a big role there. We did have analytics back then (on-prem and no resources/budget) so the leadership never saw "value"
That was a while ago now. I think a lot of organizations step into the GSD early because comms is so much more ethereal and harder to quantify. I think your challenge is really exciting and can breathe life into your community.
All the best,
Hey Doug - That is really helpful. Thank you! I'm also thinking if we can transfer our current communication avenues into our Jive site, we can then shut those down and there is a substantial cost savings that goes into it at that point.
Yep. Cost savings always works out well, for the first year (warning here...executives will forget that value in year 2...so what's the value after all that crap is shut down?)
Try also to push value-add-to-revenue. If you can tie your community messaging to increased revenues, however slight but valid, then you'll have no problem.
3 people found this helpful
We use Jive for a mix of purposes. In fact, when someone is wanting my help setting up a group or space, I usually go through a "triage" exercise with them based on what we've seen as the three primary use cases in our company.
Is the primary goal of your place:
- to share information with the broader organization? In that case we focus on developing a home page that emphasizes navigation, featured content, categories, etc.
- to collaborate (i.e. GSD)? In that case we focus on dynamic widgets or tiles that help users see the latest conversations and activity.
- to provide support for some tool or business process? In that case we focus on FAQs, question widgets, and ensuring the right people are set up to be notified when questions are asked.
So far it's almost always been one of those three situations. I think it's important if you have more than one use case to not muddle them together too much in home page design because it can start to get confusing for users. That's one reason I was happy to see Jive giving us the ability to have multiple custom activity pages.
I think most Jive customers see groups as for collaboration and spaces for social intranet, information sharing kinds of purposes. We follow that somewhat although we don't have any set rules, so we seem to have evolved into a little bit more nuanced distinction when it comes to collaboration. When I look across our community, I see that people tend to want to have subspaces for departmental collaboration or for teams within the same organization, and groups for cross-functional collaboration or for communities of practice.
So for example, we have a top-level R&D space where R&D information useful to the whole company is shared. Under that are subspaces for the development teams working on various unannounced products. But we use groups for things like learning new programming languages or technologies. I think there are two advantages in using subspaces rather than groups for collaboration in scenarios like the one I described:
- If you have a top level social intranet space like the IT space, the HR space, the R&D space, etc., having collaboration going on underneath them makes it a little easier to publish content when it's ready for primetime. Employees in each business function are mentally and psychologically working in the same general "area" of Jive and can navigate back and forth between the places they need to work in. Whereas cross-functional teams and CoPs use groups because they don't have a natural "home" space to associate with.
- The ability to inherit permissions means you don't have to worry too much about it once it's set up. For example, we try very hard to work out loud, so we want our development organization to all be able to see everything going on with every project. But because these are unannounced products, not everyone in the company should have that same access. So in our case, out of an employee population of 12,000 about 2,000 have access to these spaces. This would be a nightmare to manage if we were to use social groups, but because spaces can leverage LDAP user groups and inherit permissions, it's still painful but doable.
This is a really interesting concept. I'm curious, how do you help manage these permissions, etc? Do you do a training with them? Citi has about 230,000 members in it, so scalability is incredibly important. And while I really like the idea of spaces for organizations, I'm fearful there would be a lot of overhead management taking place.
I have some instruction docs and videos, but it is challenging. One of the funniest things I see happen (for me, not the space admins ) is that an admin will have a subspace with custom permissions. They will be editing the permissions to add or remove somebody and inadvertently click the link to inherit from the parent space. But that parent space doesn't have them as an admin! So they essentially lock themselves out of their own space and I get a panicky call -- "My space disappeared! What happened to it?"
For our R&D teams, we customized our LDAP so that it builds departmental user groups and updates them automatically based on the relationships in PeopleSoft. Then those LDAP groups are synced over to Jive, and the R&D teams then use those user groups for permissions instead of individual names. But it's a little kludgy and the sync sometimes quits working.
In some other conversation on here awhile back (but I can't remember where), I remember someone saying Jive was working on being able to populate user groups based on profile field values in addition to just listing names. (Curtis Gross, was that you?) I don't know where that stands, but it would really help solve the problem of having to deal with that middle ground where you want to provide access to a large group of people but not everyone, and where the membership of that large group is constantly changing.
Hey Dennis - That may have been me. Taking the concepts of 'admin groups' and expanding the functionality is something we have been looking into. It isn't in the short term roadmap, but I would place it in the medium term. The concept would be to give the 'admin groups' a bit more functionality akin to the community permissions, and what I mean by that is having whitelist / blacklist functionalities for adding users automatically rather then relying on manually maintaining the 'admin groups.' Sounds a bit like the work you have done to customize LDAP as well.
Thanks for the story as well, it's interesting how a story from a real scenario can highlight where there is a need / flaw in a product. Great way to get a point across.