Building Collaborative Tools in a company

Since I am exploring other career options, I thought it would be good to share some stories from the trenches. Specifically about internal collaboration — meaning how a group of people share ideas within a company. As a consultant, I worked with a major software company to drive the recommendation and implementation of internal communities of practice. This entailed finding the right solution for them vs just deciding to implement what’s popular — or just implementing discussion forums or wikis, etc. My focus was to assess their needs, develop a plan, and then implement an internal “collaboration and communication” platform for its employees. They had used a wiki before I arrived, but no one was contributing to or reading the wiki.

For that company, I recommended hybrid approach, using WordPress to implement a simple blog format but with extensive discussion thread functionality instead of having just traditional blog comments. This provided enough playing field (real estate for a thought leader) to share his learnings, provide guidance via How-Tos, sprinkle in some video or audio, and jump start a discussion. To be honest, I learned this format during my days at Intuit. The discussion threads hanging below the initial post provided a forum for great collaboration and problem solving. I have to admit that one of the keys was creating a robust search solution so that users could find what they were looking for. Why didn’t the wiki work. Despite it being a great collaborative tool, very few wikis are easy to use and are designed in a user friendly manner. I would say is an exception.

In working with that client, here are some high level learnings about building collaborative tools to be used by individuals in the same company:

  • One approach does not always work for everyone
  • You need internal buy in from all the different key stakeholders
  • Keep it simple (people tend to focus on the technology — and they usually focus on what they think is the coolest technology
  • Be clear on how teams want to collaborate, communicate and share information (what are they really solving for)
  • Offer extensive opt-in training – Focus on a clearly defined on-boarding process (and know that it doesn’t end after the training)
  • Create guidelines and guardrails ™– to help people understand what they can do and can’t do
  • Don’t under-estimate the value of moderators
  • Understand budgets and identify potential areas where cost-creep (upwards) might happen.. etc.

Maybe all of this sounds obvious. Sorry if it does. I am just sharing what I am learning. To be honest, I prefer the hands on approach vs. the ‘develop strategy and leave’ approach. It is important for me to leverage my experience as a builder, problem solver, and someone who is consistently focused on continuous improvement. This last point is key — because as you all know, whenever you build a community platform, you are constantly leveraging user feedback, analytics, and other learnings to improve your service.

More on this later on..


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s