London Part III of III - Commitment Counts

February 7, 2006 · · Posted by Jordan Frank

On the last night of my trip, I grabbed Sushi dinner with a customer and Suw Charman. Suw is a Corante analyst, author of Strange Attractor and author of Dark Blogs Case Study 01 - A European Pharma Group. Conversations ran the gamut as they should when a virtual colleague is first met in person. Among other things, Suw briefed me on the Open Rights Group, which she heads in her copious spare time, and, we exchanged ideas on social software adoption. We are both steeped in various implementation projects and have seen some similar, some divergent trends. What's clear is there are no hard and fast rules, but lessons to learn from each deployment.

Mike Gotta lays out three major technology adoption factors which include "organizational (social), business (process) and IT (infrastructure)." This is a useful model, especially when all three factors are taken as interdependent.

For example, supposing you want to post project status reports to your boss, you need agreement from the team that everyone will blog reports, process alignment to ensure that the information will flow properly up and across the corporate food chain to the right people, and IT facilitation to enable e-mail notifications for those who prefer their e-mail boxes to RSS feeds.

Suw and I focused on the Social factor and first debated the two usual deployment models: Top down vs. grass roots. Top down requirements can be suppressive, I suppose, but offer instant alignment throughout the organization and increase chances for success. Top down efforts can come with the encumbrance of requiring worker overhead and solving problems for management rather than day to day business process. Grass roots efforts, when they take off, provide increased self-satisfaction for the "do-ers" and may be likely to solve business process problems for those behind the effort.

The problem with grass roots efforts, however, emerges ugly head when stakeholders (upwards or downwards from "the grass" in the organizational hierarchy), don't align with the process introduced by the effort.

Participation in the social networking software platform (be it blog or wiki or workspace) does not require a commandment from the boss (top down), but it does require commitment on the part of the stakeholders who benefit by, need awareness of, and must interact with the information entered into the platform. Otherwise, the social platform isn't social at all.

The grass roots + organizational commitment model is not the best or only approach, but it certainly aligns the social adoption factors in a way that are likely to facilitate rather than conflict with the process and infrastructure factors.

Best Practice and the Wikipedia Big Brain

September 25, 2006 · · Posted by Jordan Frank

ImageAt the recent Interop New York (see TechWeb story), Andrew McAfee compares Wikipedia to an ant colony, suggesting that the opposite of imposed structure is not chaos. He said:

When you look at an ant colony, it seems like there is a big brain somewhere... Lots of people don't like having structure imposed on them.

The "ants" surely do the lion's share of work to build wikipedia. But we should remember that the best practice demonstrated by Wikipedia is not the opposite of imposed structure. Far from it, the simple fact is that there is a big brain behind Wikipedia which very discretely organizes the actions of the ants:

- Wikipedia has guidelines

- Wikipedia has policies

- Wikipedia is not a democracy

- Wikipedia is maintained by roughly 1000 volunteer developers, stewards, bureaucrats, and administrators.

Nicholas Carr recently wrote about A Fork in Wikipedia's Road, where the 207 member Association of Inclusionist Wikipedians and the 144 member Association of Deletionist Wikipedians are advocating different sides of the wikipedia governance debate.

Collectively, there are a set of rules that govern what can be done in this wiki and people who manage the structure through the list of possible categories and who enforce the rules, though sometimes with differing philosophy, but all with common governance.

As many companies are fretting with developing blogging policies (see Blogging Policy = Blabbing Policy), Wikipedia provides a good case study which includes top-down policy and structure, wherein the ants may freely work bottom-up towards the group goals. The fact is, ant colonies work effectively because there is a set of explicit or implied marching orders and a discreet division of labor between management (the Queen or Queens), workers, and other roles such as alates.

Best practice recommendations (see KM Forum and case studies from Ipsen, a global pharmaceutical company and SITA, a network provider to the airline industry) show that similar top down support and a set of structure and rules for a workspace provide a necessary framework for knowledge workers to adopt technology with willingness and efficiency.

Pros and Cons of Emergence

October 17, 2007 · · Posted by Jordan Frank

Jim McGee did an excellent job in The Problem of Emergence of wrapping up our coffee talk with Jack Vinson on the pros and cons of emergence when adapting Web 2.0 to Enterprise 2.0. The simple fact is that Enterprise 2.0 is different from Web 2.0, and because of that, these differences have to be accounted for in the technologies implemented and in support of the adoption process.

The concept of emergence comes in response to the unreasonable Enterprise 1.0 constraints of pre-conceived, rigid enterprise systems built, generally, for process control.

At the other end of the spectrum, Jim says "In designing a system for emergence, the designers leave a number of these decisions open; waiting for users to fill in the blanks. So, for example, instead of locking down a taxonomy for categorizing documents, the designers might provide a tagging system to allow a folksonomy to emerge from the idiosyncratic choices of each user."

The problem with full fledged emergence, in Jim's words, is "You want the energy and creative outcomes that can come from a successful emergent approach, but you can’t simply rely on unaided market forces to fuel the process."

On the web, many social networking sites have launched and failed, millions of blogs have emerged and seen little traffic. Beyond emergence, some mix of good marketing strategy, PR, timing and money contribute the the success of sites like Flickr, Facebook, Wikipedia and LinkedIn.

Taken to the enterprise, it's necessary to acknowledge the realities of the success and failures of Web 2.0, as well as factors specific to the enterprise realities. In the body of his post, McGee suggests three essential ingredients:

  1. A marketing plan to introduce the technology and how it may be used.
  2. Appropriate scaffolding and careful seeding of content... an empty tagging system will prove too much of a blank slate for users more accustomed to the structures of conventional systems.
  3. Coaching and mentoring on how to use selected technologies to accomplish their goals. This coaching would focus on working out strategies for how to use the technology to accomplish specific business and organizational goals.

The second point is the crux of my reasoning in The Yin and Yang of Enterprise 2.0. The Yin/Yang post suggests a marriage between the Yin of Coordinated Collaboration (structure, perhaps in the form of a tag template for new wikis) and the Yang of Collaborative Creativity (emergence, allowing users the freedom to create tags and build out the organization of the space over time).

Web 2.0 models are necessarily emergent as there is little opportunity for planning and coordination. However, the formalized structures such as those described in Best Practice and the Wikipedia Big Brain cannot be ignored. As McGee says, Web 2.0 models benefit from the openness and scale of the web as a whole.

Enterprises are limited in scale as compared to the web, but can benefit quickly by establishing best practices, tag templates, and patterned use cases which make it easier for users to adopt the technology and to get traction quickly as they move between wiki and blog spaces to perform their regular communication and content management activities. Detailed taxonomies are too rigid, but enterprises will benefit readily by synchronizing tags between wikis and blogs. One simple example might be agreeing on the tag "Status" vs. leaving users to the task of creating an array of similar tags like "Status" and "Update"

Given appropriate scaffolding, software interface elements such as those described in Making Wikis Work in Business - Leading Users to Water can help to nudge late adopters in the right direction.

If you want to be successful in Enterprise 2.0 efforts, as with any effort, there is no harm in using all the resources available; from technology to training, coaching, internal marketing and process suggestions; to your advantage. Depending on your mix of internal culture, user skill and existing infrastructure, the right mix of emergence and planned or suggested structure is one key factor.

Page Top