I had the best time writing these. Enjoy.
Structure
- Make the login process as painful as possible.
- Assume that your Jive Social Business Software (SBS) environment is only about delivering and consuming content, and not also about connecting and collaborating.
- Ignore the fact that adoption happens virally – make your SBS environment an unwelcome and confusing experience for ad hoc joiners.
- Create a space for every permutation of your organizational hierarchy – try to mimic your intranet structure.
- Assume that structure is immutable.
- Assume seasoned participants look at the All Content page or space hierarchy a lot.
Communication
- Never let executives express their support publicly or repeatedly.
- Don’t get the word out to executives or general users – just build it, and let them come.
- Ignore middle managers – they will put a stop to all this “social nonsense” and tell their employees to “get back to work.”
- Just send out one email to everyone. That should do it.
- Call it a “collaboration tool” and not a “collaborative networking environment.”
- Be secretive.
- Don’t involve your Legal department until you’re about to launch.
- Avoid the Sharepoint zealots in your organization.
Training
- Don’t bother showing users when to use Jive SBS vs. some other application. Give them too many choices. They’ll just use email that way.
- Make sure all the help content is in extremely long text documents, and doesn’t include any images or videos.
- Don’t bother mapping “how we used to do it” to “how we do it in Jive SBS” in any of your help content. Users love change, and they pick up on new ways of doing things overnight.
- Actually, don’t create any help content at all.
Managing and Monitoring
- Don’t bother with real use cases – fluffy goals, like, “collaborate and innovate better” are just fine for measuring business value.
- Make sure to enable moderation on everything. People love it when they’re micro-managed.
- Disable blogs. Nobody wants to share their opinions, anyway.
- Force participants to request new groups. Self-serve capabilities are too enabling.
- Don’t do anything about lagging participation metrics. Let things slowly die.
- Never report on progress to anyone. They don’t think what you’re trying to accomplish is important.
More from my colleague, Greg:
- Only grant login access to one department at a time
- Have 27 required profile registration fields
- Turn off reply by email
- Misconfigure your email server so all invitations end up in Spam folders
- Allow everyone to setup private communities with little or no resistance (or even asking them why.
Deploy social tools over an established silo.
This is a great post. Here are a few more – they are related to some of the ones you already posted, but with a slightly different spin:
- Focus a lot of your feedback on people who do “stupid” stuff to make an example of them, because you certainly can’t trust the community to do it for you.
- Spend a lot of time working on large taxonomies of content, communities and people that require tedious maintenance by a team of KM professionals.
- Don’t bother with publishing guidelines – everyone will know the perfect use case for when to blog, use wikis or discussion forums.
- Discuss your results in email…a lot.
“Discuss your results in email… a lot.” ROFL! Love it! And Laurie, totally get that all the time. Deploying to a group of people who already know each other and collaborate with one another isn’t going to garner the best success stories.
And Mark, the “let’s pretend to share but really let’s don’t” nature of private communities can be stepping stone to working in the clear, but yes, a very public statement about transparency should constantly be reinforced.
Hrm, your article is kind of amusing and brings up some good points – but it’s not very useful. Wouldn’t it have been more productive to make a list of potential pitfalls in rolling out SBS, with suggestions as to how they can be avoided/worked around?
Just saying, it’s a lot easier to snipe on the sidelines than it is to help improve a process. I can’t help but wonder if any of your concerns and observations were expressed to your IT department or if you’re just venting.
Never under-estimate the ability of sarcasim and irony to attract attention. Well done to Gia for making these points interesting – a skill most IT departments could do with learning!