Comments on: Team-based communities are about change, commitment and tasks http://libraryclips.blogsome.com/2009/03/09/team-based-communities-are-about-change-commitment-and-tasks/ sharing ideas thoughts and feedback Fri, 10 Feb 2012 01:30:09 +0000 http://wordpress.org/?v=1.5.1-alpha by: John Tropea http://libraryclips.blogsome.com/2009/03/09/team-based-communities-are-about-change-commitment-and-tasks/#comment-32830 Mon, 09 Mar 2009 22:32:53 +0000 http://libraryclips.blogsome.com/2009/03/09/team-based-communities-are-about-change-commitment-and-tasks/#comment-32830 Thx for that lengthy comment on your adoption experience. As I said in my first post on team-based communities, it's definitely all about leads being a role-model for successful adoption. It's not something you try half-assed with a team, it's actually serious, as it's about changing behaviours, so it should be treated both as a program and a process. In my post I guess I'm talking about teams making the most of software designed for communities to share and learn, rather than doing tasks. If the teams were really serious they would look into a more suitable package like Basecamp, Traction or the hundreds of others...as these more deal with projects/tasks. A great example is the Traction case study with the ShoreBank http://public.tractionsoft.com/traction/permalink/Public1146 http://www.fastforwardblog.com/2007/08/15/another-enterprise-blog-and-wiki-success-story-from-traction-%E2%80%93-shore-bank/ And another example http://www.fastforwardblog.com/2007/01/16/an-enterprise-20-poster-child-in-the-it-department/ Thx for that lengthy comment on your adoption experience. As I said in my first post on team-based communities, it’s definitely all about leads being a role-model for successful adoption.
It’s not something you try half-assed with a team, it’s actually serious, as it’s about changing behaviours, so it should be treated both as a program and a process.

In my post I guess I’m talking about teams making the most of software designed for communities to share and learn, rather than doing tasks.

If the teams were really serious they would look into a more suitable package like Basecamp, Traction or the hundreds of others…as these more deal with projects/tasks.

A great example is the Traction case study with the ShoreBank
http://public.tractionsoft.com/traction/permalink/Public1146
http://www.fastforwardblog.com/2007/08/15/another-enterprise-blog-and-wiki-success-story-from-traction-%E2%80%93-shore-bank/

And another example
http://www.fastforwardblog.com/2007/01/16/an-enterprise-20-poster-child-in-the-it-department/

]]> by: jon http://libraryclips.blogsome.com/2009/03/09/team-based-communities-are-about-change-commitment-and-tasks/#comment-32829 Mon, 09 Mar 2009 11:02:07 +0000 http://libraryclips.blogsome.com/2009/03/09/team-based-communities-are-about-change-commitment-and-tasks/#comment-32829 In 2006 as part of a team with responsibilities including Tech Infrastructure, I tried to advocate the use of team based wikis for many of the reasons you have mentioned, including enabling team reporting & facilitation of internal transparency. Some wikis were to be open to the (progressive large corporate) organisation and others limited to relevant players. Use of RSS type feeds were to be a key feature. One of the significant aims was also to migrate valuable data off the tangled corporate filesystem and into a wiki where the users could define & refine the structure as required. Perhaps most importantly, responsibility for data could be allocated via a hierachy thus hopefully avoiding the "save & forget" mentality that had clogged the existing corporate filesystem. Reluctance was significant from local management for a number of reasons (including focus elsewhere, lack of recognised outsourcing partner to hold responsible), though several global forums were sponsored by global head office. Even as an advocate for wikis & social networking within the organisation, I admit the forums seemed to fit poorly with local needs, suffered latency issues and lead to a blanding of local product, though increased consistency with the global product. Costs were high and even local project sponsors had to admit they were getting poor value for money. User satisfaction was declining. Understanding or appreciating the scope of use is important. Wikis represent a grass-roots/bottom-up type approach, so perhaps the global organisations mandatory top-down driven implementation was not suited. I suspect we early-adopters need to bear in mind that much (or perhaps most) effective communication takes place verbally and many team members within organisations seem likely to take a stance along the lines of "I'm here to serve the clients of the organisation, not be a slave to a piece of technology". Perhaps 3 years later buy-in would be easier to obtain. In 2006 as part of a team with responsibilities including Tech Infrastructure, I tried to advocate the use of team based wikis for many of the reasons you have mentioned, including enabling team reporting & facilitation of internal transparency. Some wikis were to be open to the (progressive large corporate) organisation and others limited to relevant players. Use of RSS type feeds were to be a key feature.

One of the significant aims was also to migrate valuable data off the tangled corporate filesystem and into a wiki where the users could define & refine the structure as required. Perhaps most importantly, responsibility for data could be allocated via a hierachy thus hopefully avoiding the “save & forget” mentality that had clogged the existing corporate filesystem.

Reluctance was significant from local management for a number of reasons (including focus elsewhere, lack of recognised outsourcing partner to hold responsible), though several global forums were sponsored by global head office. Even as an advocate for wikis & social networking within the organisation, I admit the forums seemed to fit poorly with local needs, suffered latency issues and lead to a blanding of local product, though increased consistency with the global product. Costs were high and even local project sponsors had to admit they were getting poor value for money. User satisfaction was declining.

Understanding or appreciating the scope of use is important. Wikis represent a grass-roots/bottom-up type approach, so perhaps the global organisations mandatory top-down driven implementation was not suited.

I suspect we early-adopters need to bear in mind that much (or perhaps most) effective communication takes place verbally and many team members within organisations seem likely to take a stance along the lines of “I’m here to serve the clients of the organisation, not be a slave to a piece of technology”.

Perhaps 3 years later buy-in would be easier to obtain.

]]>