Library clips

sharing ideas thoughts and feedback

July 22, 2010

Real KM : It’s about the match play, not the scoreboard

My previous posts have indirectly been on "know-why."

They are about working on tasks in an open way where anyone can go along for the ride and see all the context and workings out to a solution…which as a by-product of this methodology is documented for future findings.

I just thought of a good metaphor for the concept of know-why.

By looking at the scoreboard of a sports match you "know-what" has happened but you don’t really get a sense of why it turned out like that (the know-why).

If you watch a re-run of the match you will then understand all the micro-decisions each player made, and how the team worked together.

There are also other complexities like: morale, a man short, a fight broke-out, a few players on the team have been in a bad light in the media recently, a team has new players that need to get into the groove…and complexities we don’t even know about (a player having a rough family patch, hidden rivalry between team mates, a player ate some bad food, whatever….)

Understanding all this context and what led up to the final score gives you more of an understanding on the "why" which helps you make a more informed decision on your next action.

Representation

This is also important when looking back at the past. Will reading a report give you a complete picture of all the complexities mentioned above that all contributed to the whole? I doubt it. But reading back on multiple stories and raw blog fragments will. Raw information has all the peripheral information that may not seem important to include in a report. It isn’t the job of a report to be a video recorder, a report has an aim or agenda (it has a narrative) as does a novel (it’s what you choose to say). What I like about blog fragments and conversations is we can piece together our own understanding or narrative from the raw artifacts that are always available (we don’t just want formal representations, we want raw information to make our own). Further to this a raw fragment can be found and re-mixed for a completely different subject matter.

Imagine if the coach for some reason was not able to watch the match (undergoing surgery or something). He/she is not interested in just the final score, rather they are interested in how it came to be (what went wrong, what went right), and to learn from that and move on with an understanding. It’s much harder to improve by just knowing the score alone, as it can only tell you so much (close to even result, a team got it’s ass kicked, it was level all the way until the last 20 minutes, etc…)

Reflection

This is the whole notion of AAR and Lessons Learned, where we talk about the brain work, the conversations and decisions the led to the final results. This is what sports coaching is all about, improving yourself and the team for the next game, learning and using that. This may relate well to business units in organisations (especially if measured on collaboration and group output), but not so much for projects. Why? Well project teams don’t have a thirsty motivation to improve as the team is only temporary (unlike a business unit). Once the project is over people move on to another. Yes you take away your individual lessons, but there is less drive to do this in open anecdote circles as your care factor drops due to you moving on to working with a bunch of new people on a new project. Lessons Learned is important for the organisation as a whole and project managers, but I’m not sure workers see it as an investment or of innate importance as the entity they are improving is about to disband.

At the least if we can document as we go using social computing, then these artifacts will be left behind. And I think this is what a sports coach does, besides reviewing the match, and training to improve performance, they are on the sidelines watching a match unfold and manipulate the conditions for an intended better result. This doesn’t always happen in the workplace, often a manager requests you to report as a representation or interpretation of your conversations and brainwork, rather than seeing and interacting with you as it unfolds, which was the point of my previous post.

Social computing environments are engaging from the "What’s In It For Me" factor, which perhaps is the intrinsic motivation that will help glean improvements from temporary units like projects.

What can we say about knowledge management (KM) in relation to this?

Sure we need end products, but the real juice is in the connections, conversations and context that went into these end products. We can better understand these end products when we have access (during and after) to the workings-out and people. Just like the coach back from surgery (or anyone else) can watch a re-run of the match, or the coach at the game can make decisions as the play is happening.

Is it important for managers to eavesdrop and interact on the workings-out on your path to your end-product so they can facilitate the work? If so, we can now do this in the most ambient way.

John Hagel talks about Stocks and Flows, and that we have to move from a stockpiling culture to a flow culture, where it’s important to connect to fragments in context. From these intersections our new conversations based on earlier fragments becomes a process of knowledge creation, which is simply a by-product of doing work.

"…the real value is in creating new knowledge, rather than simply "managing" existing knowledge. In this fast moving world, what we know - our "stocks" of knowledge - depreciate faster than they used to. So we’ve got to keep creating"

"Most of us, as individuals, know this. That’s why we’re not keen to spend time entering our latest document into a knowledge management system. We know we’re better off engaging in the interactions and collaborations that create new knowledge about how to get things done.new knowledge in order to keep pace."

"Knowledge management systems desperately try to persuade participants to invest time and effort to contribute existing knowledge with the vague and long-term promise that they themselves might eventually derive value from the contributions of others. In contrast, creation spaces focus on providing immediate value to participants in terms of helping them tackle difficult performance challenges while at the same time reducing the effort required to capture and disseminate the knowledge created."

This is KM for free, as we are creating conditions for "flow" based on how humans behave to get things done, rather than explicitly warehousing end products on the shelf hoping someone comes across them, blows the dust off them, and uses them before their expiry date. Only to find it only has hints of usability (if you dare read the 50 page document hoping to find relevancy to your context in the first place). Your next move is to find the author to re-frame this information into a workable context. When doing this you are not documenting these conversations as they happen (knowledge creation) so all people get in the end is your end product, the cycle goes on. In comes social computing….

John Hagel then talks about stocks and flows in relation to written information compared to observation, experience and conversation. Which is what is special about social computing as it’s a written form that is alive; getting as close as possible to offline interactions and learning.

"think of tacit knowledge as the "know how" rather than the "know what." Imagine trying to perform brain surgery after having read all the books you can find on the subject. The books are the explicit knowledge telling you what to do but knowing how to perform this kind of surgery critically depends on an extended apprenticeship process in which tacit knowledge gets communicated through observation and then by participating on the periphery of these operations. Accessing this kind of knowledge typically requires long-term trust-based relationships. And, in times of rapid change, tacit knowledge becomes increasingly valuable: because it’s the newest knowledge, it’s the most helpful in dealing with the latest changes in a fast-moving business landscape.

Then he alludes to the ecosystem and symbiotic relationships…self-generating, self-organising, self-regulating. Something you get by facilitating conditions and monitoring the system to do it’s own thing rather than a managed approach:

"We can’t participate effectively in flows of knowledge–at least not for long–without contributing knowledge of our own. This occurs because participants in these knowledge flows don’t want free riding "takers"; they want to develop relationships with people and institutions that can contribute knowledge of their own. This is a huge hurdle for most executives who were trained to guard their knowledge carefully. Yet if they remain "takers" they will find themselves rapidly marginalized. Knowledge flows tend to concentrate among participants who are sharing with, and learning from, each other."

Above I have talked about KM embedded in doing work. Not having this is a loss, as from a KM perspective the workings-out are more valuable than the end product. KM of the past has known this but the right tools weren’t available so people were asked to write reports. Which is kind of like watching a two minute sports review of the match, which mostly show the goal scoring…the nature of this format leaves out content and context, and can also have their own agendas.

KM has been branded from a library science / information management side of managing and organising end products. But I think if social computing existed back in the day, then KM would of had the right tools for their aims. But it’s not just the tools, KM like anything else of the past has been approached with a scientific management style, whereas social computing is more about facilitating conditions, less about plans and targeted outcomes, and more about nurturing, experimenting, and emergence…not to say it can’t be incorporated to flavour business processes.

Capturing output is not KM

Let’s finish with reviewing an experience shared by Yigal Chamish, who says:

"knowledge is for action, not for warehousing"

Simon Bostock adds to this:

"You cant "manage" knowledge in a traditional sense. Its contextual, it resides in stories, its only valuable when it "flow" not when its stored, it cant be measured and its always, but always, Just In Time."

David Tebbutt has left a valuable comment on Yigals post:

"No doubt the outcomes could be captured and archived as useful information, especially if it were tagged adequately and made easy to find. But this is more content, or information management, not KM.

Were the people (in the interests of cutting travel, CO2 emissions, whatever) able to cooperate through social tools, tele-presence, or whatever, this too would be part of the "management" role that of creating the right environment for knowledge sharing to flourish."

Anyway what was Yigals post about?

Yigal talks about a group of Europeans who were invited to a herb farm in Ethiopia to explain to them the process of growing herbs and sending them to Europe. Out of conversation the issue of dealing with (eliminating) insects that damage the herb crops was raised. This was not on the agenda but its a common interest. What ensued was lots of discussion, each sharing stories and experiences. This was not planned or led, it surfaced naturally, and is the makings of a Community of Practice…naturally forming at time of need.

Social computing can mimic this type of exchange. Conversations are no way limited to the offline world. Whether they form into a community or not is not important, what is, is that the people are able to find each other and the conversation is able to take place. These are conditions for sense-making, and helping each other at time of need. It’s all documented so the conversation has longevity and reach to new people, and this whole process creates new knowledge and leaves behind artifacts that can be found and become pieces of new conversations and knowledge creation processes, and the flux goes on.

Yigal makes an important point:

"I can only imagine trying to pump this new contextual knowledge and warehouse it in a form stored in a database."

Conclusion

Charles Jennings (via Harold Jarche) gives us a nice way to conclude:

"…we need to move away from a focus on knowledge transfer and acquisition, an approach rooted in Plato’s academy…we are moving to the world of the sons of Socrates, where dialogue and guidance are key competencies. It is a world where the capability to find information and turn it into knowledge at the point-of-need provides the key competitive advantage, where knowing the right people to ask the right questions of is more likely to lead to success than any amount of internally-held knowledge and skill."

May 16, 2010

Visibility : Proof of Concept or Request

Filed under: km, community

My posts of late have been on the DIY meme, which is possible now that we have enabling social tools. These grassroots tools empower you to achieve part of your vision, and hopefully your visibility will lead to others helping you finalise it.

I’m hoping that my current project I’m tinkering on will be an example of this concept. I’m not building it using social tools, but I will spread the word using social tools.

I figure you get more participation with some good design thinking. That’s why my vision is for a browserless desktop app that streams latest content from our CoPs and allows you post to the CoP eg. something like Tweetdeck.

Now I’m not a techie person, I have limited skills…but my limited skills will get me further than trying to get something approved and developed. This idea would not be seen as important, but hopefully it will be once people are hooked on a Proof of Concept version.

I have made a HTA file on my desktop that opens a little pop-up box. It lists all the blogs, forums and wikis that I regularly use, and even has links to the post entry form for each object.

This is so much better than opening a browser and using my Favourites, and better than a desktop folder with lots of shortcuts. My little app is nicely presented as a list with some fancy javascript accordion features, and a window that rolls-up. BTW - I don’t understand how it works, I just found stuff on the net and chunked it together and tested and tweaked it till it worked.

I can share this file so others can use it. Even better I have the contents of the file in an iFrame the refers to a HTML page on our server. This way I can write new versions and not have to re-issue people new files.

Anyway, so far so good.

But what I really want is to be able to publish content to the CoP from inside the app (which I can already do if the links open within the app, but this is not ideal). I also want to see streamed content. And it would be good if my app could be turned into a generic form so people can easily make their own apps without needing to know any programming.

At the least I hope to see a cosmetic change…since I have taken away the border and the title bar you cannot drag the HTA window, so I’m hoping someone knows how to make my HTA file a window you can drag.

Anyway, my Proof of Concept will be posted in our communities.

Hopefully someone will see it, and get good use out of it, another may know programming and re-mix it to work better, another person may want to rebuild it using MS Silverlight or Adobe Air…who knows.

If it really caught on and people did not want to be without it, it might get some resources thrown at it…all thanks to Proof of Concept and the visibility of Grassroot social tools.

This example is about using social tools to get your invention visible, but further to this the invention itself may be built using the social tools…this is now all possible!!

Glass half-full

To achieve your vision you may not have everything and everyone at your disposal. But that’s OK, just use what you have at your disposal. The important part is having the grassroot tools to enable you to make your thoughts visible.

In a past post I mentioned that our Communities of Practice were originally for people in different teams or even the same teams that had like interests. eg. people from 5 different teams and offices may be experts in "Flash programming", so they set up a group space to benefit from each other.

But since these tools are so flexible we had CoPs being used for unexpected use cases, like initiative task forces, support sites, office website, task rooms, etc…

Our CoPs surfaced all these needs people have that are beyond CoPs. It teased out needs like our official support database needs to be less rigid as some teams are using a CoP instead, business unit spaces need to have social tools as BU’s are using CoPs instead of the official space, etc…

So in a certain light our CoPs have become a "Proof of Concept" for surfacing other unmet needs.

Rather than a team complaining and requesting about a better support database or better business unit spaces, they just used what they had at their disposal to achieve their needs…we are great self-organisers. This is the true essence of grassroot tools.

Due to our CoP tools, and our organic process of creating them we are able to indirectly use them as Proof of Concepts. Perhaps now the official support database may look into a crowdsourcing feature, perhaps business unit areas will have a homepage rather than just a bunch of folders…or perhaps they are happy to stay with what the CoP offers them.

People could of talked about these needs forever, and management may even agree with this need…but things go on the backburner…you have to wait for requests to go through the right channels..approvals…charters…money.

The answer is use whatever tool you have, and rather than talk the talk, walk the walk with a Proof of Concept.

There’s a difference in hearing and discussing something compared to actually using a prototype and getting that "feeling" from using it…it has a more profound effect as it’s experiential.

Summary

You have the idea, and talking gets you nowhere, so you use some grassroot tools (thank-you web 2.0) as a Proof of Concept, and this visibility gets you noticed. People you don’t know see it, and think it’s a good idea, someone else with a similar use case may apply it to a different context, a viral effect may ensue where lots of different groups are using it and improving it, someone else high up in the chain may come across it and may say why isn’t this made official.

You get the idea…visibility is king, and grassroot tools help you get there.

Not only do these social tools help you get there because they bypass the hierarchy, and it’s information flows and approvals (basically your Proof of Concept can go viral and touch lots of people…you no longer need authority as you have influence by reputation…you are networked.) But the actual tools getting you connected, can be the same tools that your Proof of Concept are based on.

In my last post I mentioned some teams have noticed our wiki tool and are self-organising a way to do onboarding. Not high-level onboarding, but at the level of what new comers need to know about working in that business unit. They are not going to wait for an official way, or approval to do it their requested way…instead they are using the tools at hand and going with it. Maybe the idea is to get in trouble, but when you get in trouble they might decide that they like your prototype and give you resources to do it properly.

Get visible, get in trouble (well, be cheeky), get a proof of concept, get social tools.

This goes hand in hand with a culture of autonomy, experimentation and acceptance of failure as the road to better productivity and performance…and innovation.

May 13, 2010

Show and Tell : Proof of Concept or Suggestion!

Filed under: km, community

Previously I posted on the ability for the bottom-up use of free-hosted tools as a way to bypass the usual channels to try something out…basically you don’t need permissions…this may sound anarchistic, but it’s simply true…people may not pay attention to their rogue behaviour for long, all they see is that they are able to work more productively. All companies can do is monitor and observe, and then shut-down or harness.

When you think of it this is a basic principle of emergent systems. The top are open to allow a pot to boil to see what percolates, emergence arises (not all ideas and strategies have to come from the top), and they can then make decisions based on the outcome.

Anyway, in the next post I talked about this type of experimentation and compared it to pilots, in the realm of enterprise 2.0 implementations.

NOTE: I used the term "enterprise 2.0" because more people will pick up that post and read it, but more accurately I mean introducing social platforms and the adoptions of these into the enterprise. Enterprise 2.0 is a state we one day may reach that will transform the structure (hierarchy blended with networks), operations (from competition to cooperation/collaboration), and the way organisations are managed, as described above (complexity eg.the Cynefin framework).

In this post I want to talk about the benefits of experimentation or "Proof of Concept", over a suggestion.

I facilitate many Communities of Practice (CoPs), and I do this by facilitating the facilitators.

Another thing I do is react to things I see around me, and imagine how they can be re-purposed using community tools. I contact the person to make the suggestion, but I’m finding the "suggestion" is not enough…Proof of Concept" speaks louder than words.

Eg. IT send out an email newsletter on Tips and Tricks

  • some sections are excerpts and link to a PDF to read more.
  • I suggested that each section in the newsletter could be a blog post (more timely, feedback)
  • this way the newsletter becomes a digest of the blog posts over the last month, that is presented in newsletter style

In another example I put together a presentation on some recommendations on how social tools can continue the conversation after an event, and how the presenters could have blogged their monthly happenings and roadmaps in a blog as a pre-cursor to the presentation…but it’s still not enough.

Even if they agree, they might not be savvy enough, allow time, or find it hard passing it by their boss.

The new approach is, "Proof of Concept". Just seed it, get it started and then let them take over…you get the ball rolling, rather than talking about a ball rolling. Momentum is king here.

Feeling it, rather than hearing it, has more impact…people just need a little push or offering to get started.

BUT, when you oversee lots and lots of CoPs it’s hard to find time to go further than a suggestion. You need to be able to build a network of volunteer activists to help you out. Sometimes this happens in a self-organised way…some of our CoPs have success in using social tools for a particular use or process, and when these facilitators are in conversation with others they naturally share the success in the way they have done things…this in essence is the viral effect.

Show and Tell

I have lots on my plate at the moment, but my priority is going to become CoPs-in-Action.

What is this?

I have been collecting lots of use cases that have emerged by various CoPs…people are using blogs, forums and wikis in ways I didn’t think would happen. Lots of these are both Above-the-Flow and In-the-Flow, but what I really want to hone in on are the In-the-Flow cases. People are also using CoPs in the way you would imagine like troubleshooting, calls for help, announcements, looking for stuff, sharing stuff, etc…

I’ve already posted about the emergence of different types of CoPs, in this post I’m now talking about the types of activities that have emerged in these CoPs.

At work I’m going to run workshops demonstrating the business value of social tools that goes beyond sharing and learning…these type of use cases are more tangible as they demonstrate what’s already being done only doing it a better way eg. broadcast team announcements, creating lists, discussing and coordinating a task. And showing examples of what people are doing. eg. A project control team using a wiki for answers to common questions, BU’s using wikis as an onboarding tool, the L&D team using blogs, forums and wikis to do a task like a global e-learning initiative (and the actual end product is a wiki), the L&D team using a forum as a place to ask questions after the presentation is over, etc.

…these initiatives didn’t come from top-down, they were grassroots things started by passionate people in those teams…now we have the ideas and have the enabling tools do the execution…no more waiting, as you are empowered.

You may be happy with how social tools spread your idea, or how the tools themselves built the idea…if not at least you built a Proof of Concept, which is more tangible than hearing a pitch…management may like it and throw some resources at it.

These workshops that will demonstrate what others in the company are doing are a Show and Tell exercise..and the intention is a viral effect.

Show and Tell is good as it demonstrates business value and use cases for others to learn from each other. To help the viral effect, or parallel push along side it, exercises like Blog and Wiki Raids are a good way to workshop with a team on an actual use case by using the tool in the workshop. Then when they go back to their seats they have first hand experience, and may continue using the tool.

Sometimes it’s hard to explain the benefits and use of a new tool, it’s better if people "feel" it…it speaks for itself, it has more impact. But it’s just hard to make time to sit with each group, so you may need to find a network of volunteer activists. Ultimately we hope for the viral effect to become so embedded that it becomes part of the culture.

Peer influence

Just the way Proof of Concept and pilots are similar, so is peer influence and the viral effect.

I have talked to managers about CoPs and collaboration and they really see the benefits and intend to use them. But they go back to their seats and don’t have time to experiment.

Yet if they see the benefits that a peer is getting out of them, or a peer recommends the tools saying there is some ground work, but then in the end they are better for it…then they more likely will give it a try.

Training, and presentations only go so far. You are more influenced by people in your peer group, people you trust..these are conditions for a viral effect.

Conclusion

Instead of waiting for what you want or instead of making a suggestion, use grassroots tools to DIY, or as a Proof of Concept. Some of these applications can be as innocent as complementing a newsletter with a blog, or using a forum for discussions after the presentation is over. And some, like perhaps using wikis to onboard BU’s, could be seen as a control and authoritative issue from a management point of view. But from an autonomous point of view your concept may have fans, and you can’t fight the crowd, or something that is viable and has increased productivity…this can be seen as disintermediation, rogue behaviour…or it can be seen as engagement, innovation…a change from extreme management to leadership blended with management.

May 10, 2010

Enterprise 2.0 : Pilot or experimentation?

Filed under: km, community, emergence

My previous post, Skip the buy-in and get ’em addicted, is about using a Proof of Concept and beyond model as a fast track to your fulfilling your vision. A way to penetrate the hierarchy in an unorthodox way, and get them to "feel it" and see living proof of it’s usefulness, rather than a Powerpoint pitch, or proposal document (or as living proof of your proposal).

It’s cheeky, but you are doing them a favour at the same time, as you have living contextual proof of the viability (by going ahead and doing it yourself), as opposed to buy-in approval, strategies, time, more time, and some more time…only to not get approved.

The decision-making doesn’t have to be bottom-up, perhaps management agree with a no-cost Proof of Concept as part of the strategy, this is a win for them as they are able to experiment and fail for free, something that was not possible in the enterprise tool arena a couple of years ago. Free hosted sites like Yammer for micro-blogging, and others for blogging, wikis, bookmarking, etc…make all this possible…a move from the Albatross to the Salmon.

Experimentation

The ease of Proof of Concept using social tools is an example of Dave Snowden’s Safe-Fail concept; Clay Shirky also talks of experimentation and low cost failure. Clay talks about organisational costs getting in the way of experimenting and finding the most optimal road. Rather we except sub-standard roads based on them being less risky and more predictable…not really the agile road to innovation at all.

Clay says:

“…most organisations attempt to reduce the effect of failure by reducing its likelihood [and cost].

Imagine that you are spearheading an effort for a firm that wants to become more innovative. You are given a list of promising but speculative ideas, and you have to choose some subset of them for investment. You thus have to guess the likelihood of success or failure for each project.

The obvious problem is that no one knows for certain what will succeed and what will fail. A less obvious but potentially more significant problem is that the possible value of various projects is unconnected to anything their designers say about them…in these circumstances, you will inevitably green-light failures and pass on potential successes. Worse still, more people will remember you saying yes to a failure than saying no to a radical but promising idea.

Given this asymmetry, you will be pushed to make safe choices, thus systematically undermining the rationale for trying to be more innovative in the first place”

But now with social tools you can experiment many options, which in the end is less risky as you are doing what you propose but at a low cost, if not free. What more would a manager want…they don’t have to predict the worthiness, they can see it and taste it. In economics this is collapsing the "opportunity cost".

The other important point is "emergence". You really don’t know what unexpected behaviours/uses may surface unless some experimentation happens. A product is not it’s design, a product is how it’s used. Just look at Twitter; it’s original intention/design was SMS text messaging, but look how it’s being used now; SMS is probably the least way people use it. And look how many different ways you can access it; 3rd party web, apps, toolbars, system tray,etc..And look at the new core features like, re-tweets and mentions, that have been incorporated into the design because people were using it this way. And look at all the use cases, originally it was about sharing what you are doing at that moment, now it’s being used as a customer service and promotions tool by the biggest companies on the planet…personally I use it for research, sharing links, getting help, and talking to rockstar consultants.

Imagine a project like Twitter was given the red-light as it seemed too risky, or other projects seemed less risky. We don’t even know the impact of the initial features and conceptual use case till we use it, let alone all that emergence (it manifests/has it’s own life…a teme).

[ADDED 12/05/2010: Some of the unexpected ways Twitter is being used may be an example of Exaptation]

Pilots

Proof of Concept is kind of similar to the idea of a pilot or even a prototype…you do something light weight and on a small scale.

But is a pilot different to experimentation?

Pilots are not about feasibility, aren’t they just the stage before release?

Usually pilots are more official. A product has been chosen, there is a strategy behind it, and the pilot is simply an early run before launching to make sure everything is working OK. But prior to this, did you experiment with other products, or did you choose the less risky or what seems as the more appropriate?

Is experimentation the stage before a pilot or is it an alternative to pilots?

The labels "experimentation" and "pilots" are sometimes interchanged. A while back at work I made a request to use a micro-blogging tool from our current content management vendor. There were many meetings (plans, security papers signed for hosted data) and away I went. I was given the product and invited a group of people to use it. At the time this product was performing badly (pretty much alpha stage so we didn’t take it further). But if it became a successful run we may have decided to purchase it, but from the beginning this was not the explicit intention, rather it was to have a go and see what it does (we did not have any strategy documents or a roadmap).

So did we run a pilot or experiment?

Does the fact that it wasn’t open to everyone have any weight on this distinction? Maybe, because of the low numbers it was a more controlled experiment, rather than a pilot?

Maybe it was an experiment because we had not bought the product as of yet, there was no strategy or roadmap?

Or maybe it was "experimentation" because it was bottom-up, rather than a top-down strategy. But I do not see why top-down ideas cannot be experimented, rather than deciding and planning on one path of action.

The context of pilots, and groups vs networks

You can pilot a Community of Practice (CoP) to get an idea of how a group works and coordinates in this new environment. All you need is a group of people to manifest the concept. And then we imagine it’s success would work for other types of groups…not always the case.
A good idea in your pilot would be to run a few different types of groups, to showcase the flexibility of these tools, and how their unstructured nature lends to different use cases ie. these tools aren’t necessarily used in one way, like an ATM machine is designed to be used one way.

One thing you can’t measure or see the benefits in piloting group spaces is see the value that visitors get from your community. Visitors to your community may ask questions, or provide answers, or read a wiki page or blog post and utilise that information. I say this because a pilot is a small scale, which means you ’aint gonna have many visitors, unless they are members of another CoP within the pilot.

I guess what I’m saying is that a pilot will not show the signs of cross CoP action. It will not demonstrate awareness and communication across groups…you know that silo bridging thing.

Just to be thorough when it comes to another dynamic like social networks, a pilot really isn’t as useful.

Unlike group spaces, social networks rely on network effects to reveal their usefulness and emergent nature.

eg. your telephone becomes more useful when someone else gets a new phone (ie. they join the network). A pilot with 5 people isn’t going to show the potential benefits and use cases that emerge when everyone is connected.

eg. Same goes with Facebook, etc. When I’m connected enterprise-wide I can see tag clouds, I get recommendations, I can see who is connected to who, serendipity will lead me to useful content by someone I don’t know but need to know…critical mass is needed for optimal emergence or gifts you receive from taking part in the system.

Andy Mcafee in his Drop the pilot post talks about the limitation of pilots in the context of social networks. Themes I got out of it are: #emergence #serendipity #awareness #diversity

From this post:

"How many of us have found great information in some weird corner of the Web, someplace far from the presumed authorities? How many have had a question answered on Twitter by a stranger? Received unexpected praise or good wishes on Facebook or LinkedIn from someone we hadn’t thought of in a while? The smaller the scale of an ESSP deployment, the less likely all these good things become.

These realizations lead to an answer to the second question posed above. Enterprise 2.0 enthusiasts should abandon pilots and go as broad as possible right away. The risks of doing this are small and manageable, and the serendipitous benefits are many."

For more on this see my post, Do group tools get more traction due to not requiring network effects and being in the context of certainty, which was inspired by a couple of posts by Michael Idinopulos called Skip the Pilot, and Launch E2.0 broad, then go deep.

Microblogging as a Stepping stone

In the latter link Michael talks about low threshold participation tools like micro-messaging as a stepping stone to higher effort tools. And he is serious about this as the company he works for, Socialtext, have their micro-blogging product, "Signals", both within the social software suite offering, and also as a standalone product. Michael says:

"Signals was not just a useful tool, it was also a stepping stone that helped participants move to the right on the Participation curve (see image above). As participants started to get the hang of Signals, many started to ask about Socialtext’s other collaborative features: What are workspaces? How do I use the Dashboard? How do I look up an individual?

After the webinar was over, a number of users wanted to go deeper by creating wiki workspaces to collaborate on tasks, projects, documentation, etc. We scheduled follow-up time with them to understand their collaborative needs and build tailored solutions.

This story describes a launch approach that simultaneously achieves seemingly conflicting objectives:

  • Launch quickly and cheaply, without investing a ton of time or money in training and content creation.
  • Achieve scale by inviting lots of people.
  • Minimize risk by making participation opt-in rather than mandatory
  • Generate active participation through interactive launch events that don’t require a lot of training or engagement from the new user.
  • Deliver deep value by following up with local champions who want to invest time and effort in more robust, group-specific forms of collaboration."

Pilots as learning stage

A post by Bertrand Duperrin about the Enterprise 2.0 Forum relates to pilots being about learning (rather than testing) before the official release, which is different to experimentation where something has just been made available, and is more about trying and testing:

"It’s not a game anymore. Now projects are global and carried by the top management. That’s the end of social bubbles disconnected from reality. Companies think global and pilots are not made to test but are the learning stage before global rollout. I really appreciated Claire Flanagan’s approach that set a time limit (5 month) instead of limiting the number of users what allowed her to quickly get a critical mass (nearly 30 000 users) with an opt-in policy."

In another post Bertrand reinforces this point:

"The purpose is not to decide to carry on or not but to learn what will be needed to drive the program at a wider scale later

Bertrand also mentions not to throw the baby out with the bath water, that we have to learn from failure, that failure is part of the path. An analogy of a car is quoted:

"…if a car does not function it’s not because the concept of a car is bad, but because either the fuel is not good, the transmission is brocken or the engine is not well set."

I often say that just say someone new to a vegetarian diet finds themselves not feeling very well, it doesn’t mean the vegetarian diet as a lifestyle is wrong, it just means that person was not very good at being one as they were not aware of all the food groups they need to cover to be healthy. Maybe they were not eating enough foods with vitamin B12, they can learn from failure and keep going on their new path.

Bertrand then says something related to the Clay Shirky excerpt at the start of this post, and that’s the notion of "risk"…and the use of the word "experiment" may have bad connotations (as does the word "social" in a business context), where usually business decisions are very carefully thought out to minimise risk

"We can be sure that employee will think, even unconsciously “I’m fed up with all their crazes…I won’t buy before it’s definitive and official…no time to waste
for something than can be shut down at any time…being a part of it may expose me and it may be a bad idea if the project goes wrong”. I already heard an employee
saying “experimentation…do they think we are guinea-pigs ?”. Explaining that the experimentation is not “on” them but “with” them is easy…but never happens.
Anyway, we must be aware that this word means lack of visibility and indecision, what is not reassuring when trying to engage employees."

Bertrand goes on to compare this to pilots where it’s not about feasibility, but rather a decision has been made, and the pilot is just the phase before the release, but it’s important to understand that…

"…the direction is known but that the path will be decided with them, hence the pilot…the company knows where to head to but must be aware of not being too directive or interventionist."


[ADDED 12/05/10: Drop the Pilot, Part 2

“…you wouldn’t dream of piloting a telephone with a small team.”

“We recently persuaded a large Socialtext client in the publishing industry to abandon a pilot-first strategy and launch enterprise-wide. They were glad they did. Their intended pilot audience showed adoption which was good, but not great. In the meantime, the rest of the company started using Socialtext to create all kinds of unintended interactions […] A lot of that would never have happened in a pilot-first scenario.”

“Andrew, I couldn’t agree more with dropping a “limited reach” pilot. As you know, CSC did run a pilot, but it was limited only in duration, not in audience. That meant any of our possible 92K+ employees could participate if they chose on an opt in basis. This allowed us to truly validate the viral nature, if in fact our strategy met the mark, and allowed us to watch collaboration patterns emerge… We created a multi-layer advocate program that included a top down and bottoms up approach. We emphasized self-service over a traditional centrally managed approach to communities. We seeded our environment with compelling business use cases prior to launch so users were greeted with real business groups and communities. And we also remembered the value of a “watercooler” in forging strong bonds across the globe. These practices, and more, combined to make the pilot so successful that the results truly demonstrated to our leadership how this could be used for business, solidifying our business case. Our users had clearly voted with their feet – and we had the data to prove it. It was an easy decision for our executive sponsors and CTO to continue funding operations into a “production contract”.”

“Sometimes something needs to be called a pilot to get executive buy in. So labeling a phase a pilot is a clear way to signal to your company (and perhaps even your vendor) that you really are in a trial stage where the commitment, risk and investment are limited. That is often a huge way to start something sooner while a larger business case is evaluated. So I think the label of a “pilot” has very strong political meaning…” Michaelbierly evidently agrees with this; he wrote: “will [not having a ‘pilot’] work? not in a typical corporation. Too much culture to change on decision making around IT to say we aren’t going to pilot.”]

[ADDED 21/05/10: Setting up a pilot is not only a matter of sizing

1°) The question of a preliminary phase

Before going further, what matters is to know if a preliminary phase is needed before scaling up the project. Obviously the answer is yes : businesses need to be sure they can manage things and get some kind of benefits on a smaller scale before applying a new concept to the whole organization.]

[ADDED 5/06/10: Piloting Social Media Creates More Risk Than It Mitigates

“This practice is not prudent for social media where the software complexity should be minimal and the primary goal is to get people interacting. Community participants are fickle and unforgiving (especially external communities). You may only get one shot at catalyzing community formulation. Don’t pilot, test, prototype, or experiment on the community. Don’t artificially restrict participation. The law of numbers is a critical factor in building a thriving and productive community. Why would you only go after a small subset of a target audience when mass adoption is a critical success factor?”]

[ADDED 16/06/10: Stephen Bounds

“I’d say that the essence of “safe-fail” is (a) trying multiple things in parallel; (b) not picking winners in advance and (c) always proceeding incrementally.

For example, most pilot projects run in two phases. First, run a proof of concept. If that works, roll out to the whole organisation.

Safe-fail breaks the process down much further. The idea is to always do things in chunks small enough to allow for roll-back if negative results occur. So an old-style “roll out” might instead happen as a dozen or more “safe fail” experiments, at each point confirming that results are positive before proceeding further down that path.”]

March 25, 2010

Presentation : Participation in Communities of Practice

Filed under: community

A while back I posted about and shared a presentation I did at a KM Conference in Perth last year. The slidedeck is on my experience developing, supporting, and facilitating online Communities of Practice for a global EPCM (Engineering) consulting firm.

That presentation contained a couple of slides on participation and I spent a lot of time talking about these slides. For the CoP facilitators at my work I thought I would flesh this out into it’s own presentation, as participation is an important topic.

It’s not just important because there is a lot of content to cover, but because the nature of the content is something that is not really practiced or paid attention to. Normally all the focus is on command and control, rather than on people. I guess you could say this belongs in the same ballpark as Management vs Leadership, but only from the concept of running a CoP.

It’s important that managers who run CoPs understand that the usual scientific management approach based on the main concept of efficiency won’t cut it. CoPs are more like good parenting or leadership where you create conditions for good and emergent outcomes.

NOTE: Our CoPs have social tools like blogs, forums and wikis. Our team spaces don’t have these, so some teams are using CoPs. In this case the team is not really a CoP, but just using our CoP tools; therefore this presentation may not be as relevant in those cases. But still if you want an effective and engaged workplace, you need to pay attention to the happiness of your workers.

What is often missing in management practices is the anthropological aspect…observing group behaviour, leadership, interpersonal skills, trust, intrinsic motivations, social interaction/connection…

We need to focus on worker satisifaction and aspiration, rather than just ordering people to complete tasks.

When considering this in the context of “issues”; rather than continually doing surgery, why not look at the more holistic perspective….create conditions so the illness has less chance to emerge…disrupt the patterns.

Anyway…

Readers of this blog may already be familiar with the content of this presentation as I have blogged about it before in a post called Community of Practice for Facilitators : pilot, adoption and participation. I guess this presentation is a more succinct and refined version of my earlier thoughts.

It’s loosely divided into four parts:

Lessons and good practice

  • Do you have a community leader with passion and time?
  • Do you have passionate key members?
  • Do you have a shared identity on what you want out of the community?
  • The manager who thought he could create a community
  • CoPs are Voluntary, Emergent, Self-selecting
  • It has a sense of place, and needs to be tendered and cared
  • Social tools are not built for a specific purpose
  • Social tools are interactional rather than transactional
  • Don’t need lots of members to succeed
  • Subject matter expert needs to run it
  • Merging CoPs is a risk
  • Don’t over design look upfront
  • I don’t want to share, that’s counter to meeting my objectives…and reward!!
  • Intrinsic motivation, rather than rewards

Participation

  • Design (Intuitive / Stickiness)
  • Frequency of content
  • Email interaction / Bookmarklet
  • Peer influence
  • Champions / Role models
  • Viral approach
  • Feedback (Reputation / Recognition)
  • Group building
  • Confidence / Comfort / Safe
  • Trust
  • Relationships (Give and Take)
  • Personal relevancy / Change
  • Post, and send link
  • Attract comments
  • Re-purposing email
  • Hand-holding
  • Barn-raising
  • In-the-flow / Above-the-flow

Activities

  • Offline to Online
  • Member Intros
  • Lounge forum
  • Blog carnival
  • Polls
  • Guest posts
  • Coffee Corner / Fill in the gap
  • Member of the month
  • Weekly roundup
  • Personal stories
  • People travelling
  • Blog columns
  • Engaging media (video)
  • Email signature
  • Newsletter
  • Linking across CoPs
  • Events
  • Portal

Facilitating

  • Garden
  • Design
  • Communicate
  • Welcome
  • Assist
  • Support
  • Prompt
  • Correct
  • Guides
  • Promote
  • Re-purpose
  • Suggestions
  • Feedback
  • Congratulate
  • Barnraise
  • Monitor
  • Listen
  • Personal needs
  • Subscribe
  • Specialise

Get free blog up and running in minutes with Blogsome | Theme designs available here

Related Posts Plugin for WordPress, Blogger...