Last week in part 2 of the Extended Enterprise series, I blogged about the value that external communities offer to the internal business community. Now, I'd like to share some strategy for how to grow the kind of community that delivers on that value. In our sister market, CRM, the post on SearchCIO.com had this to say: "Last June Cambridge, Mass.-based Forrester Research Inc. reported that less than 50% of the 94 business and IT executives it surveyed were fully satisfied with their CRM deployments. When Forrester asked those executives to list their best practices for improving their CRM implementation, 66% said promoting user adoption was a top priority." The user adoption challenge for CRM is similar to the user adoption challenge when implementing social productivity software in the enterprise. If you want a community (internal or external) where social productivity can be optimized, you need to put quite a bit of thought into how the community will be structured. In addition to productivity concerns, this initial structure can also impact the adoption of your new community. The challenges include how much or how little structure should be provided and then what kind of promotion/coaching/training should follow the initial implementation. The amount of structure falls into three main categories: emergent, highly structured, and adaptive.
An emergent approach presents the community members with a blank slate with no defined sub-communities, topics, or other structure. As the topics of conversation evolve into common threads, gradually a structure is put in place. For example, if there are many discussions about best practices, then maybe it makes sense to add a best practices area within the community.
Using an emergent structure when building a community has a number of advantages. It is easy to implement, since less up-front planning is required to define the structure. You get great user buy-in when the users are helping to define the structure. The end result may include a fantastic structure that you never would have thought of as way to organize your community.
There are also a few disadvantages associated with the emergent approach. The biggest disadvantage is that many users will be faced with writers block. It can be much easier to contribute to a community when faced with some general topics, instead of a blank slate. Another issue is that contributors can get sidetracked more easily. If the first few posts are way off topic, the rest may continue in that thread making it difficult to achieve the objectives that the enterprise is trying to accomplish. It can also be difficult to establish structure after people have started contributing, since many discussion threads, documents or other content will need to be moved into the new structure.
I think that the emergent approach would work best in environments where the subjects are not clear or are still emerging. It also works well for non-enterprise (purely social) communities where the community is self-led.
In the highly structured approach, the community manager lays out a very formal and possibly rigid structure before rolling out the community. Community contributions will need to fit within this defined structure.
The highly structured approach has some advantages. The enterprise has much more control over the topics allowed within the community. The expectations for community members are also clear. When community members arrive at the community, they see the topical areas where they can contribute.
The disadvantages of this approach are that it can be restrictive and possibly inflexible as the market changes and evolves. You may miss valuable contributions in areas that you never thought to include, but that would have great benefit for the community. The structure may be defined in a way that just doesn't work in the real world. Some community members may also resist the structure if it doesn't fit with the topics that are important to the community or if the structure makes it difficult to figure out where to post content.
This approach works best when a company wants to have very tight control over their community; however, this control usually comes at the expense of community buy-in and participation.
An adaptive approach requires that you define some structure before the community launches, but allows for additional changes as the community evolves. A few top level topics may be defined while sub-topics and additional top level topics are encouraged to emerge.
Advantages of an adaptive structure include stronger user buy-in as they see the structure evolve in response to community input. The company still has some control over the topics and the initial direction of the community. The community can evolve in directions not anticipated during the initial design.
The disadvantages of this approach are minor. The company gives up a little control to the community. User traction is required to make progress toward the defining the rest of the structure.
Tips and Recommendations
I recommend using the adaptive approach when starting your community. This has worked well for me in the past, particularly with the Ignite Realtime community. We started with a loose structure in place, but over the past six months, I have made quite a few changes in response to community requests and the evolution of the community. With Jivespace, I took a much more structured approach, not out of a desire to control it, but because I got a little carried away with defining things up front. As a result, I have some sub-communities that are rarely used. I find the adaptive approach more appealing. I can define a few sub-communities until I see where people are contributing. In general, it is easier to add new communities over time as needed.
Over a longer period of time, most communities will need to be adaptive. Businesses and products change and evolve as markets and technologies change. Communities need to have some flexibility to adapt and grow to include new areas of collaboration.
Spend some time in the early days of the community identifying and getting to know the heavy users and tap them for spreading interest within the community. These community members can give you an early indication of where the community is headed and how you might need to adapt the structure. They can also be your biggest allies when you need help with problem users, disagreements within the community, and even just answering routine questions. Jim McGee summarizes this well in The Problem of Emergence post on FASTForward the blog:
"In particular, the plan needs to identify those potential users who are most likely to benefit from the new capabilities and whose successful use of the technology will be interpreted as an endorsement to be emulated."