Library clips

Gordon from Inforvark has a piece on why KM didn’t work, due to it’s non-humanistic processes:

“Who was the guy we talked to about that thing?” Enterprise 1.0 tried to address this by mandating a central repository and hierarchical classification system. It forced employees to tell some computer system what they knew and how they knew it. Only after a lot of manual data entry would the system be able to tell them something in return.

This approach failed because knowledge workers couldn’t be bothered. There was too much up-front work to make the search results useful. Without useful search results, nobody wanted to use the system. It was a classic chicken-and-egg problem. Instead, knowledge workers would just ask someone who knew rather than working with a difficult computer and move on. You simply can’t turn your workforce into programmers, historians or archivists. There’s work to be done.”

The Diving Board blog in on the same plane:

“As we all know, collecting knowledge (if it happens at all) usually involves a person or organization monitoring knowledge as it is created, and then capturing and categorizing it after the fact. This could either be the knowledge worker as they create it or someone else charged with this mission. This process is both inefficient and inherently flawed. Typically, the expert or the users themselves know what the best knowledge is, not some third party who is one step removed from the actual work. However, the experts and users lack the tools, time and incentive to carry out this critical task.”

I’ve also got a quote along the same lines from Andrew Gent in an earlier blog post.

And this is what my posts, Adapting to change with enterprise 2.0, Why km 1.0 failed in a nutshell, KM : Round 2.0, and Conversations, Connections and Context are all about.

Gordon then goes on to ponder whether enterprise 2.0 will fix this. His idea of a contribution engine is, “a tool that automatically captures an employee’s output, indexes it for later retrieval, and shares it with others in the group”

I think we need to define 2 types of knowledge sharing

1. knowledge sharing can take place as it happens as a result of doing work (capturing information as it happens)
eg. making your work visible on a wiki, using a forum to get answers, using a blog for directed communications
- others get the benefit of your participation
- you are sharing by default of doing your work

2. you may discover something, have some insight, have an experience…but then you have to choose whether you will let others know
eg. found a solution to a problem you were having, and if you share it others may benefit

In a past post I have covered that the difference here is In-the-flow (Directed) vs Above-the-flow (Volunteered)

So perhaps Gordon is talking about this second aspect (Above-the-flow), as I believe an In-the-flow approach is submitting to the “contribution engine” as it’s happening…he says:

“When I was working in ECM, I used to joke about the “seven-second window.” That’s the period of time between a user finishing a piece of work and moving on to the next task. That window is the length of time users will devote to figuring out where to put content and how to share it. Do I send an email? What folder on the share drive do I use? If you can’t capture the necessary metadata within that seven seconds of “Hmmm. Where should I put this?” then you lose. The system won’t work. People are too busy.”

At work our support team use a support database where users log calls. You can see the progress trail of any given call, and the final solution…then you close the call, and it goes into the ether.

You may have closed a call before any other support worker knew it even existed. Being based in Perth, I only choose to look at calls in my location anyway, so I don’t see the calls from around the world.

At the moment if the call we just closed is unique we add it to our group blog….this is our “seven seconds”.

But this doesn’t always happen.

So an ultimate contribution engine would be if our written solution in the support database posted to the blog as we hit the close call button.

I really think blogs and the like need to be features of existing products.
(You would think our document management system would have an item comment stream (like Google Docs), instead for every document we have chosen to have a forum topic. This is one step better than using email, but the conversation is still separated from the actual document).

Blur the line of above and in the flow

The other day at a staff meeting our new Quality guy spoke about his new role and how his focus is on working with other teams to ensure workers adhere to processes, procedures, culture of working, etc…and that he is writing a plan and report.

If he wrote this report in a wiki, others with permissions, especially cross-unit leads could eavesdrop on this progress, and add insight that he doesn’t know about, because he cannot possibly know the politics, norms, and domestics of each business unit.

NOTE: Please don’t say a survey…the idea of KM 2.0 is no extra effort to share and mingle, it happens as part of doing work.

This report, I assume, would take months to write, why not blog about; progress, feedback, ideas, musings, snippets to showcase, as you go along. By doing this others are in the loop, and they may leave comments to give you ideas and answers. Especially for this type of report, other leads could leave comments on blog posts, or even a dedicated wikipage, on the blockages they have with their team using current procedures, etc..

I bet when the report is finished it would be more relevant, and not just another report about you must work like this for the sake of quality
Instead, the writing of the report has incorporated the existing attitudes, which has helped shape it, now the procedures and processes may work as we are accomodating for the reality of the culture of work.

In fact it would be more true to “quality” if the report was more realistic in its research, being flexible to how people naturally work rather than rigid…in fact it may be realised that the proceses and procedures themselves are the problem as they are not in tune with human behaviour.

Why do I think this blurs the line?

Using a blog to share your insights and musings along the way is “Above-the-flow”, but using the same blog for progress updates and communications could be “In-the-flow” (as you would use email for this anyway).
Whichever method it increases a chance for others to contribute their know how as comments. In a nutshell working in a visible way may encourage more “Above-the-flow” participation.

Using a wiki to draft your document is “In-the-flow” (I don’t really like the descriptor “knowledge sharing” here as it’s just doing work). The benefit of doing this in a visible way, is others can see your progress without you having to update them, and they can add value using the comments. So what is happening, depending on the nature of their comment, is they may be choosing to share some “Above-the-flow” (personal know-how) to your wiki.

The idea is that an “In-the-flow” approach using participative tools, will encourage “Above-the-flow” sharing. You would hope in the long run that people would not only share know-how in a reactionary way, like using comments, but would also initiate original content using blog posts, wiki pages, etc…

We know comments is where the conversation is, and this is where all the know-how exchanges happen, as people share what they know and they discuss to clarify, etc… The object is dynamic, perpetual, and as smart as a crowd.
The existence of comments itself is our first step in an “Above-the-flow” culture, as they are less effort than initiating original content, and they almost always share opinion…it’s an effective way to get people in the swing of working open (transparent) and socially.

Anyway…

The premise is to capture thoughts and interactions as they happen, email is good but closed, and physical conversations have all the know-how, but can only be documented after the fact (which loses all its richness). So the idea is to complement the offline world with online social tools that mimic how we work offline, but have the benefit of capturing (documenting) as we interact, and including others in the converation, that don’t have the privilege of being in the same location of a meeting or 1-to1 conversation.

Without blogs and wikis, this would be the approach:
- Meetings, emails, IM, phone, physical conversations.

The problem here is there is no sense of place, if I am a new comer, how do I catch up on the progress of this initiative and the progress of the report.

Meetings are essential, but you can only say so much in a alotted timeframe, social tools allow to extend the meeting discussions in an asynchronous way, and to lots more eyeballs, that is much more open and conversational than email…others not in the meeting may have something valuable to say.

The phone and physical conversations are also essential, but blogs and wikis allow others to interact without having to engage in 1-on-1 conversation.
Sometimes I don’t want to engage in a phone call, I may have an idea and quickly add it as a comment to someone’s blog. I could email my idea, but then this clogs up their inbox, and who do I put in the to: field so lots of people see it. Actually maybe I feel a bit “pushy” and shy disturbing everyone with an email about a flash of insight, so I won’t send it after all. Whereas a blog comment doesn’t feel “pushy” at all, and you have more confidence sharing your ideas as you haven’t pushed them into people faces, instead they choose to “pull” your comment to themselves (you’re not quite sure who is going to see it, but it’s there for all to see).

I could give a quick IM, which isn’t as committed as a phone call, but then that comment is not attached to the object and the receiver has to write it down somewhere so they don’t forget.

To extend this post it’s essential to organically permeate the right culture by creating conditions for knowledge sharing, such as socially connected and unstructured tools with low barriers to entry, trust circles, roles models, senior support, job evaluation, and facilitation.

Related
The context of blogs
KM 2.0 : doing your job or giving back to the organisation
Knowledge and its facilitators

Stewart Mader, Wiki Evangelist for Confluence, has decided to go his own way and formally do what he does best, and be a full-time wiki consultant.

There are lots of enterprise 2.0 type consultancies, but a non-vendor consulting specifically about wikis must be a first.

Stewart’s blog is an education hub for enterprise wiki adoption.

If you want a quick fix check out Stewart’s series 21 days of wiki adoption, and for the more indepth know-how check out his book WikiPatterns, that also has a accompanying wiki website.

Congratulations to Stewart for being a pioneer in his field, and best wishes for spreading the word.

Stewart Mader from Grow Your Wiki is guest posting on Wikinomics and his lastest post is on the effectiveness of wikis enabling tacit sharing.

Documents that are open and dynamic allow people to evolve the documents by direct editing or leaving comments…ie. people are sharing their experience and what they know can add to the richness of the document.

Right away I thought of the How-To Guides I’m writing for our Communities of Practice (CoP) at work.

If my guides are on a wiki rather than PDF, people who use the guides can leave comments, or people with permissions can edit the page itself or a new page to add what they know.

This way they can help me evolve the document, even though it’s finished. Well, that’s the idea, it’s never finished…I may miss a feature, and I can’t experience every context, so there’s stuff that happens when people use Communities that I may not know up front. eg. a new way to use blogs, a workaround (exception to procedure) page for Document Control as each client has different needs.

They may leave a comment about a feature of our CoPs where they have a workaround, or a use case.
eg. someone might say everyone in our team has a status blog, so when we go to a meeting we already know what everyone has been up to, our meetings are more about action.
Another person visiting the guide may see this and use this idea.
A simple comment box on a wiki has enabled the sharing and receiving of know-how by two people that don’t even know each other, plus this is perpetual as another person may come along and get value or an idea from reading the same comment. In fact another person may leave a comment back and say that they found it more manageable having one group blog for status. The original person my see this and comment back saying, that is a great idea, I didn’t know that was possible. Oops, that’s because I may have not put that fact in the guide, lucky that comments allow for others to help where the guide fails.
And as Stewart mentions I can go and refine the guide and leave a comment saying thanks.

In the end we have this explicit type deliverable that has to be formal and succinct as it has to cater to many audiences, and can’t be too explanatory (long), and try to cover every context possible, as people won’t bother reading it. But on top of this we have a layer of collective know-how and feedback via the comments which inturn we feed back into the document (via edit) some tacit know-how.

The point is having perpetually live documents (editing and comments) harnesses the collective wisdom, where people can share their know-how, and benefit the user experience as a whole. It’s a win win situation.

A while back I mentioned that I like the idea that after a conference, conference-call, presentation, meeting, workshop, etc…you can continue the conversations online.

For a big conference like the Web 2.0 Expo, they used CrowdVine as a social networking tool…I’ve posted about it before. And of course this same tool can be used to continue the conversation once the conference is over. Vyew is another tool that saves your conference in a book where you can continue to collaborate and discuss asynchronously, it also has a widget so this book can be embedded anywhere.
Stewart Mader suggests a wiki rather than a conference showbag.

What I found in my last conference call is that most of what we talked about in the call can also be done online, in our community page, when we are not present at the same time (asynchronous).

These are three types of things we did in the conference call, that cover blogs, forums, and wikis:

1. News, and status around the globe from each team member [BLOG]

Each team member had a turn to update the team on their status

- why do this in the conference call, when we can subscribe to the group status blog, or each others personal blogs
- any conversation can be carried out in the comments
- all can read and/or take part in conversations on their own time
- this saves time on the call to do other stuff
- to recall something just go to the blog archive

This is put nicely from the wiki perspective by the Dresdner Kleinwort Wasserstein case study:

“The teleconference used to be one and a half hours long, with much time wasted on bringing people up to speed on the week’s events. Now team members update themselves on the wiki, and that part of the teleconference takes five to ten minutes.

The rest of the teleconference is used for ideas generation, being innovative, talking about problems and looking at solutions, which is what the meeting should be about. It shouldn’t be about updating people as to what’s happened, but thinking about our clients and how we can service them.”

2. Discussion about issues people had since the last call [FORUM]

The team was asked if there was anything to discuss.

This is what a conference call is all about…conversation.

But, we should not wait for a conference call to discuss things, why not use the community forums everyday.

3. Brainstormed an idea for better usability for one of our systems [WIKI]

What we basically did was come up with a list for things to appear in a drop down menu, that would cover all reasons when a user logs a support call.

It was good to do this synchronously as we could discuss whilst we made the list, nothing beats this.

But I’m sure we could of started this list in a wiki, and used the comments for discussion, and then perhaps join the conference call to finalise our list.

Summary

I realised in one meeting that we covered the use of 3 of the most important social tools.

Why do we need so many meetings, when we can be collaborating and conversing perpetually?

The more we use social tools, the shorter our meetings can be.

Nothing beats synchronous group chats to discuss out issues, but we can sometimes do most of this discussion, updates, and collaboration online, and call a short meeting to finalise and action our findings.

Next time I talk about social tools adoption, I can tell people you are doing it anyway, only this is doing the same thing when we are not all in the same room.

We can still collaborate, discuss, update when we are not in the same room.

The fact is people are fine to physically participate in informing their status and what they’ve been up to, discuss issues, and collaborate…but when it comes to doing this online they feel weird being social (open and visibility). Instead they use email as it’s more closed and private, and they do all three things with email (status, discuss, collaborate) that they do in person at a meeting, it’s like email is their asynchronous voice.

Part of the adoption process is to help people get over the awkwardness of being social online, we have to guide them by informing them social tools are not extra work, it’s what you are doing anyway.

Rough Example 1

“In a meeting you share your status, well here is a blog to do the exact same thing…you can even share any experiences, or whatever you like here.” (Above-the-Flow)

“In a meeting you take part in discussions, well here is a forum to do the exact same thing.”

“In a meeting we collaborate and brainstorm, well here is a wiki to do the exact same thing.”

“Email is for private correspondence, whereas these three tools above are the online version for what we do in meetings.”

“An easy way to think about it, is if it’s not private information, then a community tool can be used. The next step is to work out whether you need a blog, forum or wiki.”

“Please use these three tools when the context of what you want to do is about, status/experience, discussion, or collaboration.”

“These social tools will live in a community website, which assimilates our meeting room, this allows us to still communicate and work together when we are not in meetings.”

Using the approach above we are introducing social tools not for the heck of it, or as a knowledge sharing drive, etc…
We are introducing them to solve issues specific issues, that way people will be more serious about them, and these are issues that effect the whole enterprise.

If the reason of introducing social tools was-we need to collaborate more, and share knowledge-people are going to say “yeah, I’ve heard that before”, “I’m not sharing what I know” (power/trust), and “I haven’t got time”.

Instead if we put it across as solving particular issues, it is received in a more welcoming way, as it’s like we are going to deploy tools that we help them with their problems…it doesn’t come across like we want something out of them as much.

Rough Example 2

“The company is experiencing email stress, as part of this company-wide problem we are introducing communities and social tools in order to relieve this email overload.”

“Our introduction of communities are intended to help tackle two serious issues in our enterprise that effect everyone: email and meeting overload. Please use communities for any of these three types of action, rather than email or having yet another meeting.”

“These are two serious issues affecting everyone in the company, and if we don’t all do the right thing, we won’t be able to overcome our issues. The company is one big group, and if a few seeds ignore this message, it will spoil the intentions and dynamics of the group. So remember your behaviour is going to affect the whole.”

“As part of this initiative we will be looking at recognising people and groups that use communities, we feel there will be self recognition anyway. We will also look into this as being incorporated into our company aims, and job performance reviews.”

“To kick all this off I introduce the whole office to the “Office community”, the only communication via email will be a notification to visit an entry at the “Office community”.”

“Business units, interest groups, and task rooms will be set up on request in order to use community tools to get your work done.”

I’m more for a viral bottom-up approach, but even so at some stage you may want to get the message out to the whole company. Perhaps have it in your back pocket in case the bottom-up approach isn’t quite working as expected.

This office-wide approach has to be repeated to staff within their own teams, community leaders will be champions, facilitators, role models…

From the above example I did not once mention: social, enterprise 2.0, web 2.0, knowledge sharing, collaboration (oops, I did mention this), we need to capitialise on opportunities for competitive advantage, getting stuff out of people’s heads, blogs, wikis…
Instead I raised issues like email overload and shorter/less meetings (time) that can be alleviated using social tools.

The sell is about not doing anything extra, it’s only offering substitute tools, it’s focused on specific problems, and it hopes to come across as doing people a favour to help them work less frustrated.

To finish up here’s an excerpt by JP Rangaswami in relation to Facebook, but to me it covers what social tools and the use of communities are all about, this is the engagement we are trying to achieve…social productivity by leveraging the social capital:

“…you’ve taken what happened at the water cooler or at the coffee shop and made it persistent, made it shareable, made it teachable, made it learnable […] Now we have the ability to actually understand what these relationships are, how information and decision making migrates horizontally, laterally through an organization, rather than through the published hierarchies, how people really work, and what people do as part of that work […] to look at the flows that matter rather than the flows of the politics”

We are piloting communities at work, the gist of it is:

Blog - broadcast, experience, ideas, feedback, status
Forum - discussion
Wiki- collaborate, document, website

Step 1

The concept is, it’s much easier to do work using these new tools rather than using email to do all three of these things (broadcast, discuss, collaborate).

Let’s not mention that content is open and centralised for others to see, all have a voice, conversation can evolve into new knowledge, tune into your social filter to ask questions and finds things…pretty much a way to get things done.

Plus all your interactions, contributions, and readings happen in a contextual place. If I want to see the forum contributions I have made on the KM forum, I just go to the KM CoP, or goto my personal dashboard.

For me this beats trying to find this stuff in my email. I like my content to live in context eg. comments about a wiki to be in the wiki itself rather than be separated (disconnected) in my email client.

Jack Vinson talks about context as providing you with a “frame of reference”, he says:

“The better I understand the particular frame of reference (context), the better I can understand what this information or knowledge means.”

This is kind of different to the context I’m talking about. I’m talking about the context of a place, he is talking about seeing data in a context setting (even better if it’s a familiar setting) to help you use your current knowledge to create new information…I guess metaphor is another way.

In a way it does relate to what I’m talking about as reading a forum reply you found in your email, makes much more sense when you see it in the bigger picture of the actual forum.

Anyway so I call the use of our communities as Step 1.

We can now learn to use social tools to get work done with much less confusion, and of course this creates a perpetual open dialogue where knowledge is continuously created and re-used in the open.

Another benefit is that you end up with less email to deal with, as now what would of been email lives at the context of the place (as a blog post/comment, forum topic/reply, wiki contribution/comment).

Although, without an inbox for each community (private messages), one-to-one messages are done in email. I’d rather these emails as private or public messages that live in context, ie. at the community…see more.

Step 2

Does this really give you less email to deal with…I don’t think so.

It’s great we are attempting to no longer just rely on the intelligence of the email system to do our work, these social tools enable us to work easier and content is no longer siloed (a centralised and flowing corporate memory). But we are still using email.

How? Notifications, that’s how.

In our communities we currently have RSS disabled for some reason, maybe it’s a good thing for now, to prevent scaring people with too much new stuff to absorb.

For each blog and forum you can get new content delivered as a new email, and this is not just a notification, it’s the full-text of the blog post or forum topic.
When you subscribe to a blog or forum you are also subscribed to blog comments and forum replies (personally I’d like a choice).

Also, each blog post and each forum topic has an email address.
This means when you get an email for a new blog post, you can hit reply and it will post your comment to the blog…nice one.

You can also publish a new blog post by writing a new email and sending it to the blog email address (you can include non-subscribers to your blog in the to: or cc: field, that way they will get the content even though they don’t subscribe to your blog…nifty!)

OK, first thing.

I really like this email interoperability, it’s bringing the use of new tools to people’s comfort zone. But at the same time I would also like people to visit the actual community to experience the whole realm. There’s more chance you are going to read something else or contribute, if you are at the community itself.

So right now, this email interoperability is both good and bad.

The more concerning issue that some people have been talking about in the forums is since the introduction of communities they are getting just as much email.

They allude to “what’s the difference to my inbox overload if someone writes an email or publishes a blog post which I get in email anyway…isn’t communities meant to help with the inbox firehose.”
They also mention that community content gets lost in their inbox amongst all other types of emails.

This just screams RSS Reader.

But it also may scream our community Watchlist page.

The Watchlist page is a stream of the lastest stuff you are subscribed to, so throughout the day you can go to this page to see what’s new in the stream. The saves you visiting every blog and forum that you like from every community you like…instead it’s in one personalised page.
But I think I have to have an email subscription in order for this stuff to be on my Watchlist…darn (gotta look into this).

Whether it’s a Watchlist or an RSS Reader, it becomes a second dashboard.
You have your email dashboard and your what’s happening dashboard.

You can read RSS feeds within your email, but the idea is that email is a tool for personal correspondence, and that’s it, and an RSS Reader is a tool for the latest updates.

Perhaps a startpage could combine both into one dashboard, or Outlook could have an RSS Reader module that is just as important as the email inbox…in fact Outlook would no longer be an email client, it would be a personal productivity dashboard.

Conclusion

At the moment we are in the pre-introductory stage of Step 1. - a social way of doing work
(lots of learning, and culture change issues to go with this)

We also need to be prepared for Step 2.

And it’s Step 2. that may win the KM team acclaim in reducing the common email overload problem.

Any department that can reduce the email overload problem is going to get kudo’s, will it be the KM team.