Library clips

This is a follow-up to my Community Lessons post, and Community paradox post.

Top-Down community creation

We have not officially released communities at work, but we have over 50, as it’s spreading by word of mouth (plus all this stuff is in vogue now).
I’m still writing the help guides, so I feel for the current users, and sometimes they are lost…the design of our communities is not very web 2.0, so people need help.

People have to fill in a request form that asks them various questions highlighting the committment and facilitation required.
Once I review that form I meet with the proposed community leader and talk to them about communities, domain, people (community), practice (output), tools, methods, participation, facilitation, structure, types, community indicators, shared identity, how they are different to networks, sustainability, etc…

NOTE: Previously with organisational/team based communities I met with the whole team on a telecon, and it was a bit messy because everyone had their idea of structure, etc…so now I meet with the proposed leader and a couple of key members, and we go through everything, then they may or may not talk to their team before coming back to me to finalise.

Once this is finalised I create the community to the required specifications eg. maybe a community only want forums, or maybe they just want a blog and a place to store documents, etc…

Then I ask the leader to pilot the community with a few key members, this way when it’s opened to more people they can visit and read the content and discussions that have already taken place. The idea is to make it attractive and engaging on the first visit.
The other aspect to this is that the community leader and key members will be proficient users and will be empowered to tackle questions by new users.
For me this is part of adoption - a blank community is not inviting, it lacks a gravitational pull, and a leader who is not equipped to properly lead may leave members in the cold. Plus as global community coordinator I don’t want to be asked questions that the facilitators could be empowered to answer.

In the future I will be running a Facilitator’s community so I can keep community leaders in the loop of running and sustaining communities, and a place for them to learn off each other. I also give them examples of community specific help guides and examples of instructional design to help their users orient and learn to use the community…it’s crucial they have a good experience, by their needs being fulfilled. This also goes for people who visit. In regards to design it’s important to role play and pretend you are a member or a visitor and see how you fair in knowing how to orient yourself when visiting or participating in a community.

Something I’ll add here is that the person I talk to has to be the community leader, they have to be the passionate person. What happens with organisational/team based communities, as opposed to practice or share interest communities, is that a sponsor will set it up with me, and then they leave it to others to run…whereas I’d rather speak to those others from the start as well…I want a relationship with the person running the community. I want the nominated person to be passionate and committed, and not doing it because their boss said so…this is something I try to make known to their boss.

Another thing I learnt is that alot of communities have lots of members for no reason. With our communities visitors are free to subscribe to blogs and forums, leave blog comments, and ask a question.

Members can additonally write blog posts, interact in forums, and add documents. But it’s more than this, members need to be involved either offline/online, they need to be an integral part…whether they are behind the scenes organising meeting/events or they are a subject matter blogger or perhaps they don’t write forum topics but get involved in a lot of forum replies.
The real communities are those where each member is integral, this quote by Adam Fields sums it up:

“There’s really only one rule for community as far as I’m concerned, and it’s this - in order to call some gathering of people a “community”, it is a requirement that if you’re a member of the community, and one day you stop showing up, people will come looking for you to see where you went.”

If you are not going to participate at all, well you might as well not be a member, but still subscribe or visit to content you are interested in.
Anyway, when people request to join a community there is a message to this effect, helping them decide right off the bat if being a member is what they thought it would be.

So far this post has been about community creation, but what I really wanted to focus is on the disadvantages of top-down creation of communities, wiki, blogs, etc… That is, what are we, the company, and knowledge workers missing out on by not being able to have the freedom to create these objects (bottom-up creation)?

I have explained above, in the pre-creation consultation of a community I talk people through what’s involved. A lot of the time it’s not what they are after, they didn’t realise “communities are conversations”, and they were just after more of a document management (DM) type thing. I tell them that DM is a way to centralise and make available what’s on people’s hard drives into one easy place. The additional feature of our communities is that we can also have conversations using blogs and forums, that replace and make less messy what happens in emails, and much more…it’s about awareness, discovery and connecting with people, participating, conversations, evolving content, and learning.

The other aspect is that they don’t know what’s involved in sustaining and facilitating a community to be a sticky hot spot for people to visit daily, interact…ie a daily resource to learn more about your interest. In the end, the less participation, the less it’s a community. In one community at work there are very few forum topics and I’m basically the lone blogger, so it doesn’t feel like a community at all…we don’t meet-up or discuss things we want to learn. I get lots of comments, but then you don’t have to be a member to comment on a blog. I learn from these comments, but I might as well blog outside the community (but we don’t have this kind of framework yet, we only have blogs within communities, an intranet 2.0 network solution is further down the line)…I’ll stop here as this is not a post about participation.

I’ve mentioned that some people:

- think they want a community, but don’t, once they find out it’s not what they wanted
- don’t have time to commit
- don’t like the top-down process of having to set one up

Bottom-Up community creation

It’s this last point I’m interested in, if community creation was a bottom-up process what would be different?

For starters our communities are not that well designed or intuitive so they need to interact with me anyway, and creating a community requires a few steps.

My speculation is that we would have hundreds of abandoned communities, as people would realise it’s not what they want, they don’t know it’s about conversation, they don’t know how to facilitate, etc…

What this means is that our community directory would contain lots of empty communities, which would be an unfriendly experience as people would browse and discover lots of empty spaces, and perhaps think this community tool is not really serious, or wonder how to find the good stuff.

What I do like about this approach is since people are free to create communities, they will, and we would potentially get lots of great communities. Factors such as limited time, attention, and the fact that you can do it yourself and not need permissions, would surely result in the creation of lots more new communities, compared to a top-down method.

Simply, if there is a button called “create a new community”, people will press it, but if the button is “request a community” and outlines steps in involved, they are more inclined to wait another day, or never (and continue as an email gang)…that’s human nature. But then again if they are really passionate about enhancing their email gang with more appropriate tools, then they will make time for the formal process of starting a community.

By using our top-down creation approach we are probably forgoing the creation of lots of good potential communities, but at the same time we are not getting; duplicate communities, and lots of abandoned communities that make the product look like horseplay. All this flies in the face of Dave Snowden’s experience in IBM’s change to bottom-up community creation.

Another thing is that bottom-up creation may result in more communities that have lower membership, but where everyone is a major contributor (these are thriving communities as you usually trust a smaller circle of people, and you are all on the same wavelength and have time for each other). At the moment our community requests are never for 5 or 6 people, they are always for an indended crowd of 20, 50 or 100, I don’t know why. What I want to see are real small and tight communities, at the moment I still think these types are still using emails. Somehow I have to make clear that communities can be tiny and are able to reject membership. As I get into below, maybe a Facebook Group type of design is more inducive to this type of community.

I suppose there is also the other point in that we are being an authority in deciding whether the proposed community is a worthy topic for organisational performance, and so far it is every time. We also have more casual spaces like a bicycle users community, etc…but these are the minority, the idea is that the majority of communities are about building situational awareness and capabilities.
We are not averse to casual communities (just as long as they are not the majority, we are at work!), as it’s a way for people to discover, connect, converse and engage at work…people like where they work when they are socially engaged. Casual communities are like bumping into someone in the coffee room, you never know what may percolate, perhaps a conversation in the bicycle users community will lead to a work oriented task, or finding some information, or wanting to create a new community, or collaborating.
As long as we give people the tools to connect and converse we hope that everything else follows, and this will certainly be true with a future social networking tool. I think more communities will be created as people will meet in the network, and then hook up as a group as a community to pursue their shared interests.
Dawn Foster has an interesting idea of a lounge area in a community, where people can bond in a forum about things that don’t have to be work oriented or don’t have to pertain to the topic of the community. I think this is a great idea, and is something I may suggest in the future, this gives people a way to connect beyond the commonality of their job, and get to know each other a little deeper, or simply more holistically (I mean we do spend more time with these people than our families).

So when I think about it our communities are transparent and bottom-up in that people participate and interact their know-how, allowing for emergence, but they are not very enterprise 2.0 in the way of bottom-up creation. If people were free to create I bet we’d get lots more created than we’d get asked to create, so we are missing out on some emergence here.

Groups and Design

I have to think to myself if our communities were intuitive in design like Facebook groups, would we be more likely to let people create communities, as a Facebook group is very simple to create and use.

But then our communities are more robust than Facebook groups, you can do a lot more with the structure, permissions, and look and feel. Facebook groups are more disposable whereas our communities seem more professional. With our communities you wouldn’t go to the trouble to creating a “Nicole Kidman hate group” (well you wouldn’t do this in the enterprise anyway), as they take longer to set-up, and gather people…so I’m thinking here that there is a difference between a group and a community, or at least a group being a feature of a social network.

In the future when we look into an enterprise social network, I’m sure it will have a group feature just like Yammer, or any other enterprise Facebook type tool, and in this case people will be free to create groups on the fly. I’ve got a feeling these types of groups will be more about getting a task done, or smaller things, or more temporary things, rather than our official community tool.

I wait for the future to see how these groups will differ to our communities…for starters groups will be a feature of a social network, so already you have a pool of people one click away from being part of a group.

Actually I see these groups being use heavily for cross team collaboration, or team collaboration tasks. We don’t have a basecamp type tool (which is more task oriented than a community, but very similar), so some people use communities for tasks, but they are not quite designed that way even though they have almost the same tools. Our communities are too big or serious to set up to for a one month task, so people nominate an existing community and create a folder, adding a blog, forum, and documents, and then give non-members permissions to just that folder. The problem is first you have to choose a community to do a cross team task, wait for the Facilitator to create your blog and forum, and secondly the other team after a while may forget the link to that folder.

Our communities are just not designed for this, but I really feel this is where a groups feature in a social network will shine.

BTW - only a Community Leader can create a blog or forum…community members must send a request to the leader of a community. What do people think about this?

Wikis - Top or Bottom

We are also piloting wikis, and at the moment, as a control mechanism for the pilot you can only create a wiki in a community. I have had requests for wikis that don’t fit into any existing communities, but these will have to wait. Just like blogs and forums, a community member has to request a new wiki in their community. Any thoughts?

One of our staff (Jeff Brown) posted a great reply to one of my internal forum topics:

“A wiki is just another type of document, isn’t it? It has similar features to a document, in that it contains formatted text, images, can get updated, and is read by (possibly) multiple audiences. Do we restrict people from adding documents? (No)
I can see wanting to reach out to the people who just created a wiki, and providing them with material on how to use it, make it better, etc. I got an “urgent” call several weeks ago about how to set up a community, about 5 minutes in after I started explaining about the process, they said they had to go and never called back. I think they decided it was too much work (midcall). I’d hate to think we are putting too much red tape into the wiki creation process.

What could happen if everyone could create a wiki? Are we worried that someone will create a wiki that is then abandoned or not updated? That we will have a flood of wiki-hungry users with no support?”

This got me thinking, documents are linear and wikis are websites (hyperlinked pages), is there anything about the wiki format that makes it seem more official than a document.

Each community could create about 5 wikis, one for notes, one lists, one for drafting articles, etc…so whenever you need a wiki you just create a new page in an existing wiki and go for it. If people want a whole wiki for a task or topic they can request it from the Facilitator…but in a global community this could mean waiting for the next day, and that’s too late, as we only want to wait 5 minutes, and rightfully so.

Since they nature of wikis are more immediate and spontaneous eg. brainstorming, lists drafting…I think anyone needs to be able to create one.

But at the same time wikis can be official eg Help Guides, Glossary…and we don’t want duplication.

In the future when we allow wikis in and outside of communities eg. in our document management system, I don’t see why they can’t be created by anyone. It’s up to the owner of that folder or space to promote the official wikis from the scratchings and non-official wikis.

Thoughts

In relation to our communities, even if we had a bottom-up approach of people creating them, they would have to follow instruction as it’s not straight forward like user designed web 2.0 tools, and they may be put off straight away. Due to this non-intuitive design they will have a better experience if they can wait and allow me to create one, as they will be needing my help anyway. This way I will not be receiving constant support calls.

As I said earlier, if the design was right, it would be more probable for a bottom-up community creation scenario. We would get duplication, and abandoned communities which we would have to monitor. We’d also get more support calls as we’d get members asking the differences between blogs and forums and how to use them, as the community creator would not be empowered. Maybe communities could be promoted to the official directory based on participation and success statistics.

But I still like the idea of top-down creation as I get to share my skill in how to pilot, run and best set up (structure) a community.

So I’m really in two minds about this.

And of course it depends on your culture eg. if I was talking about a company like Google, I would assume their culture is web 2.0 savvy, and can probably survive on bottom-up creation. But that doesn’t necessarily mean they have facilitating and leadership skills.

When it comes to wikis, well I think users need to create this at will, bottom-up all the way…keep in mind I’m not saying this from experience.

I’d like to here from the likes of Gia Lyons, Chuck Hollis, Joitske Hulsebosch, Stewart Mader, Luis Suarez, Nancy White, Shawn Callahan, Steve Dale, Ed Mitchell, John Smith, Richard Dennison, Dawn Foster, Stan Garfield and any others on bottom-up community and wiki creation.

eg. Does Lotus Connections enable anyone to create a community, if so, what are the pros and cons of this bottom-up approach.

[ADDED 8/01/09: The participation issue from community ownership and structure]

[ADDED 9/01/09: A social media proficiency strategy]

My previous blog entry was a follow up on flexible tools not being immune to being used the wrong way. My example was the danger of using a blog as a solution centre due to its news type nature, and rather using a wiki for an official solution centre.

In that example, wikis were described as a place to house explicit information, whereas the blog was more explanatory tacit based information, perhaps containing the know-how behind the solution.

Why is the blog entry important?

We may not be aware that the wiki solution page that we are reading, with a little altering, can also fix our current error we are troubleshooting.

Why?

The wiki solution page may not have much context, it’s just, “when you see this error, use this solution”.
The good thing about this is the page is succinct, we don’t want to be reading forever when we are researching for a solution.

But if that wiki solution page points to a blog entry about the experience of coming up with that solution, we may find we can apply these same techniques to our current troubleshooting.

This is the difference between explicit and tacit, with tacit know-how we learn, rather than just being informed.

It can be done without a blog

You don’t have to have a blog to share the anecdote about your troubleshooting experience, you could have a link on your wiki solution page to another wikpage that is a space for anecdotes about the solution. I just like the idea of a blog format listing a diary of experiences in time, like reading the daily news (again, this is learning by building anticipatory awareness).

Wikis vs Documents

So at the moment a wiki is preferable as a solution centre over a folder with a bunch of documents, as the website format is more usable, and one-click edit is very easy compared to having to launch a Word document in a Document Management System (DMS).
I guess a website feels like a sense of place, more a one stop shop compared to a document in a folder, a website just has more character, a front door, etc…

Know-how expressed as both explicit and tacit

Using the example above, the fact that people are taking the time to add a solution to a wiki is an act of sharing their know-how. Even though I have called it “explicit”, it blurs the line as know-how is usually synonomous with “tacit”. Perhaps it’s better to say that they share their know-how in the wikipage in a more explicit and summarized way, and they share this same know-how in a more tacit and personal way in the blog entry.

In fact I described the different ways to express information in an entry called the KM Core Sample.

Whether explicit (more formal) or tacit (more informal) we are happy that people are sharing at all, and as facilitators we are to concentrate on creating conditions for it to happen more often.

Wikis reach what procedures cannot forsee

Wikis are really valuable for people to pool their know-how for incidences where there are process failures and exceptions to the rule.

Some members of a Document Control team at my work use an Excel document (stored in the DMS) to list exceptions to procedures or just little steps that are not able to be known upfront in a procedure…we hope wikis will cover this space.

A procedure or a best practice cannot cover every context, and some clients and situations have different needs, which means we need to be able to make our workflow flexible and also keep everyone in the loop of what’s going on and how to do things that procedure’s simply cannot cover (they are thick enough already, and are not clairvoyant anyway).

Actually I mentioned this point in my KM Review article:

“These types of interactions enable learning to occur in a more informal and social way; a way we cannot cater for upfront; and a way that brings to light answers and workarounds for contexts and situations that arise, as well as those that already exist.”

There’s always a documented formal way in how to do things, and then there’s the way things are really done. I think a wiki is sharing and documenting how things are really done, they reflect the reality of where a manual cannot reach.

In a learning perspective this is the difference between formal learning (training) and informal learning (social on the job). I heard the other day that 80% of what we learn to do our job, is contextual on the job learning by experience, and 20% is from formal training. Put another way why do we spend 80% on training, when it effectively relates to only 20% of learning…this is based on the Pareto Principle of 80% of the effects come from 20% of the causes.

See more on a comparison of Learning 1.0 vs Learning 2.0.

BRP - Barely Repeatable Process

Ross Dawson explains the need to complement an ERP - Easily Repeatable Process, with a BRP - Barely Repeatable Process:

“Typically exceptions to the ERPs, anything that involves people in non-rigid flows through education, health, support, government, consulting or the daily unplanned issues that happens in every organisation. The activities that employees spend most of their time on every day.
Processes that often starts with an e-mail or a call. A process volume, measured by time and resource spent at organisations, probably larger than for the Easily Repeatable Processes.
These are mostly handled and organised - frameworked - by systems like paper based rules and policies, e-mail, meetings, calls and now in more modern organisations by wikis and other collaboration systems and methods.

Known by extensive loss of information (e-mails residing on HDDs), little knowledge acquired and reused (typical research says 70% of problems solved before without being known) and most of all, untrustworthy processes (oops, forgot to send that mail). In other words not an iota (well almost) of business process thinking or methodology applied to this huge untapped area of business processes.”

Not only do wikis offer a communal space to list these exceptions to procedures and workflows that occur due to unplanned events or just the plain reality of situational contexts, so we can do our work, but it can be seen as a knowledge re-use perspective. Once what was just “known” but not written down, is now flowing out of people’s heads onto the communal canvas.
When I’m in a urgent siutation I may not need to wait for a couple of people to get back to me with an answer, as they may have already shared a little scribble about an exception to a process in the wiki.

Ross Mayfield on the same meme:

“The way organizations adapt, survive and be productive is through the social interaction that happens outside the lines that we draw by hierarchy, process and organizational structure. The first form of social software to really take off to facilitate these discussions was email.”

“Most employees don’t spend their time executing business process. That’s a myth. They spend most of their time handling exceptions to business process. That’s what they’re doing in their [e-mail] inbox for four hours a day. Email has become the great exception handler.”

And again, there’s no knowledge re-use when we use a closed system like email to handle exceptions that procedures cannot cover.

Examples

Just say some of your work tools or applications don’t work on certain laptops
- you are never going to get a laptop that works seamlessly with everything, that’s life
- IT could create a wikipage listing tools that don’t work on a particular laptop model, or what you have to do in order to make them work
- I bet a communal effort could whip up a list in no time at all

These little things we take for granted usually come up when we are training someone new.
Like all of us, every job I’ve had I’ve been taught processes, but also been overwhelmed with things like “but on this day, or in this situation, you have to deviate from the norm and do this instead”. You usually hear about 10 of these exceptions and think, how will I ever remember what to do when I need to do it.

Part of my role is in Document Management support. When a project coordinator creates a project there are various post-duties we have to do for projects created with different templates. This is because the templates are being revamped, and procedures don’t cover these in-between stages. Once the new templates come in then everything will be more generic, but for now we need to know what to do different for which template.
There are even local differences, and these differences can’t be part of a procedure, so again this is where a wiki can be used to help you do your job.

The world is complex and contextual, and wikis help ease this situation by pooling the efforts of all the players. Wikis can also display patterns that emerge. If a manager reviews all the exceptions and workarounds in a wiki, it could reveal a usage issue, a bottleneck problem, a safety issue, etc…

Every plant site has procedures, but like everything else these procedures cannot be aware of every situation that can occur, or meet every need, so a site wiki for these heuristics, anomalies, band-aids, exceptions can be communally created by the people who actually work at the site.

A wiki would be doing a site manager a favour in the ways of safety, and possible new inclusion into the procedures…when exceptions become the rule. Now that I think of it, it’s kind of a distant cousin to an online suggestion box.

What I like about this is no-one is in charge or responsible to write such a document, it’s just stuff everyone knows or doesn’t know, so by everyone pitching in we help each other out, there is no effort on just one person, therefore it’s more prone to exist…plus none of us are smarter than the sum of us.

I’m sure everyone has seen a sign when they have travelled and stayed in hostels, that says “if toilet doesn’t flush, keep button pressed till it passes” or “first set shower hot water tap, then turn on the cold water tap”.

But we can’t have signs or post it notes everywhere, and you can’t easily put a sign on intangible things like a process step in using an online application.

Please leave a comment of an example of exceptions and workarounds in your job, that people know (or don’t know), but isn’t written down because it’s not someone’s job duty.

I expect some comments as I think this happens everywhere

In this post I describe using wikis for a solution centre and for an exceptions list, but there are endless ways to use wikis, go check it out.

Related

The tacitness of wikis
The value of networked free-form publishing
KM 2.0 : doing your job or giving back to the organisation

A recent conversation has re-emerged at my work on How do wikis and blogs fit together?

One way is to think of the stock and flow model, wikis have perpetually re-edited pages, whereas blogs have a stream of date-based entries just like newspaper articles.

Wikipages can be seen as more definitive, whereas blog posts are about currency, opinion, etc…

A perfect example of this thinking is a paper by the CIA called The Wiki and the Blog: Toward a Complex Adaptive Intelligence Community. This is an award winning essay on how information sharing, and collaborative tools allow us to dynamically adapt to a changing environment (from an intelligence agency point of view).

I posted about this 3 years ago, so I’m going to quote myself here:

The idea is based on a workflow:

- repository
- blog
- wiki
- search (self explanatory)
- feedback

As the repository fills with information (structured or unstructured), we can be alerted by email or RSS for items within a category, user, keyword, most recent, etc…

Then we post blog entries, adding value (ideas and context) to this information (kind of a KM transference), people read the blog posts and are informed, creating further discussion.

The cream of the blog conversations is then added to a wikipage as the important and relevant information (filtered, and applied to the corporate context)

From the essay:

“The Blog will be vibrant, and make sea changes in real-time. The Wiki, as it matures, will serve as corporate knowledge and will not be as fickle as a the Blog. The Wiki will be authortative in nature, while the Blog will be highly agile. The Blog is personal and opinionated. The Wiki is agreed-uopn and corporate […] The Blog and the Wiki serve as successive refining processes for the unrefined ore in the intelligence repository.”

“…in the repository were most cited by the Blog over the last 24 hours. This feedback lets visitors quickly know what the community thinks is important…understand its impact…let visitors know what areas of the Wiki are changing most rapidly as an indicator of newly vetted knowledge […] top words…top blog postings…top sources cited.”

” As important as information sharing is to the success of the solution, it is even more important to know who is sharing what information. This allows intelligence officers to accurately understand where they are in the intellectual space of the intelligence community. It also allows intelligence officers to see what gaps exist and where changes need to be made.”

Since this essay the intelligence community has made a big impact at the latest enterprise 2.0 conference with it’s Intellipedia system and beyond.

How this relates to using a wiki as a solution centre?

(I think) a blog should not be a solution centre, whereas a wiki is ideal.

I guess a Tips and Tricks blog is OK, but “solution” is a more definitive word, so a wiki is more suitable.

A blog is simply a timestamped communication, similar to a newspaper.

If someone attempts to use a solution listed in a blog entry from 3 months ago, this could be outdated and not work, whereas the wikipage would always be re-edited and fresh.

Sure you can re-edit a blog entry, but its date-based format implies user beware when you are in the archives. Just like if I look at a newspaper article from 8 months ago, it may no longer be true, but that’s OK because the article has a date on it.

Within a community blogs, are great for announcements, experiences, tips, sharing links, ideas, etc…
When it comes to a solution, it should be created in a wikipage (then put the link of the wikipage on the wiki homepage or table of contents)

Then if you feel like it, write a blog post telling and pointing others to the wikipage solution, and sharing perhaps your experience and context in working out this solution.

This way the wikipage becomes the sanitised document, and the blog entry becomes the context, know-how, the “workings out” that led to this solution.

This blog entry is handy to notify people, but also the “workings out” type of content you share may trigger things in others to apply to related issues. Whereas the wikipage solution on it’s own may not be as prone to trigger correlations or ideas to other issues as the wikipage solution is sanitised, focused and more impersonal (whereas a blog entry may have more peripheral information).

Obviously you can be as personal as you like in wikis, after all it’s a free-text box, but for a solution centre wiki you may want to be more succinct and to the point.

What you could do is go back to this wikipage and put in a hyperlink to the blog entry…this way when someone is reading the wikipage solution they can click to the blog entry to find out what happened behind the scenes.

NOTE: a similar scenario could be applied to testing or tasks, where the wiki is the formal content, and the blog tells you the informal stuff about what happened.

A typical workflow

1. A support worker is dealing with an error

2. They check the solution wiki if there is a solution for this error

3. If not, they search their community support forums or post a forum topic

4. If they find a solution, they create a wikipage, then link to it on the wiki homepage

—

5. If they feel this solution is a crucial find and needs to be shared, they can then create a blog entry

A. This blog entry notifies people and points them to the wikipage

B. This blog entry includes informal, experiential and contextual information that is not included in the wikipage solution. The wikipage solution is more focused and to the point, whereas the blog entry may explain the workings out, and what took place.

6. If you like you can go back to the wikipage solution and put a link to the blog entry that expands more on the solution.

If someone has feedback or a question after reading the blog entry they can leave a comment.

In the past you have to be in the same room when someone discovers a solution, otherwise you may not know. The benefit of being in the same room is that you were there and experienced the build up to the solution, you know all the details, and you could discuss it as well.

The idea of wikis and blogs it to mimic what happens in real life, but extend it to a global village.

Further to this…

In the future someone may use this wikipage solution for a different issue, and they then may create a blog entry pointing to this same wiki solution (and then include a pointer to the blog entry, in the wikipage solution).

What we have in the end is an official solution wikipage, with links to blog entries which are essentially anecdotes about experiencing this error and solution.

This is an example of using new flexible tools to create explicit (wikipage) and tacit (blog entries) knowledge.

This is an example of a user putting the complexity into the software, instead of the other way around…see more at the end of this post.

UPDATE: Wikis and blogs can be used the same way when doing UAT (Testing). Your test results can go in the wiki, and the blog entry can notify and explain the test experience.

Related

The ubiquity of social tools in context of workflows
7 seconds to knowledge share
Is publish a dirty word in enterprise 2.0?

Not long ago I wrote a post called “7 seconds to knowledge share” based on a post at Infovark.

Here’s something I said:

“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)…”

This really ties up with Bill Ives’s comments that I’ve quoted on two posts about old KM being both workflow and repository types…the problem being that the workflow types were too rigid so we went elsewhere for these exceptions, and the repository types were out of our flow, not in tune with human behaviour, and as Bill says, “…it became managing knowledge rather than supporting work”

At this stage of KM 2.0 or enterprise 2.0 we have seen people familiarising themselves with these new social tools, and how they are the new exception handler. Instead of using email to get work done because my workflow tools are too rigid, I can now use wiki or a blog for these workarounds, etc…the benefit is openness, transparency, visibility, feedback and evolving…basically pooling our talent.

I think the next phase of KM 2.0 (no, I’m not calling it KM 3.0 or KM 2.5) is going to be where answers to these exceptions will be shared into the flow.

Firstly the idea is for these new social tools to become boring, as said by Clay Shirky.

Secondly we are going to see features of blogs and wikis in existing workflow tools.
Like I said in the quote at the start of this post, we need “blog it” features in our current workflow tools, etc…just like every object has “print this” or “email this”…

Further to this we need our current workflow products (an example is a support database-from users logging calls, to working on calls, to closing the call, to harvesting the unique calls to a solutions page) to be blogified and wikified.
I think along with wikis and blogs as standalone tools, we are going to see our workflow tools incorporate wiki and blog features, but yet it won’t be a blog or a wiki. We will have “post it” buttons on forms that publish fragments from our workflow to other places, yet we don’t have a blog in our workflow, it’s just a form, kind of like an edge feed like publi.sh.
We will perhaps have access to a “edit this” button at stages in our workflow to add/edit notes to a page
eg. you get to a stage of a workflow where the procedures really don’t help you with a clients need, this becomes an exception, but as you get to this stage someone has edited this page and instructed you how to move on with this type of client need. The talent pool is able to share their experiences and know-how right into the workflow…it’s not really a standalone wiki, it’s just a wikified object.

What I like about “edit this’ all over the place is that we don’t have to go to a separate repository (wiki-page) to see if people have shared this type of information before, instead it’s right in our flow, without us even having to think about it.

The current stage of KM 2.0 is that people have a personal interest in sharing their know-how, there’s less resistance, in fact people feel the benefits, and it’s all due to tools with a low barrier to entry, and how they are in tune with human behaviour, just the way we converse offline.

These tools are open and transparent and perpetually evolve content, but similar to KM 1.0 they are still a separate place from our workflow. When we want to know something, we visit a blog or wiki to see if anyone has shared some insight, if we find something relevant, we then go back to our workflow and move to the next stage.

It’s not just about workflows, of course blogs and wikis are used outside of workflows eg. personal blogs, communication blogs, wikipedia’s, wikis for lists, wikis for meetings, wikis for documentation, etc…

I just think the next phase is using features of these tools into our existings workflows, so when we get to dead end, we don’t go elsewhere to find a way to move on, instead the answer is right there. If it’s not, then when you do find an answer you include it in the workflow stage that you are at so the next person will go through the flow like a speed bump rather than a detour.

This is all about the ubiquity of social tools in context of workflows.

Related
Knowledge visibility, conversation, and the In and Out Flow

[ADDED 30/09/08: In-the-Flow with Acumen Fund]

[ADDED 14/01/08: KM 2.0 : doing your job or giving back to the organisation]

In a few posts I have talked about a support team using blogs (micro-blogs), forums, and wikis to get work done.

In regards to blogs the idea is to that we have an unstructured, low barrier to entry type tool to quickly publish fragments about experiences, tips, solutions, ideas…in fact we can publish by email, so this blends in with current rountines.
BTW - this isn’t just altruistic, I often do it as a way to remember what I know, but at least I’m keeping notes in the open for all to see.

Can blogs be harmful? I think it’s how you use them.

I think it’s of absolute importance that people understand that blogs are based on a currency format, they are similar to a newspaper or a journal.
A blog entry that was true last month may no longer be true anymore or correct, or there may be a better way to do the same thing.

So even though a blog is technically a database, I feel that it shouldn’t be a solutions database, especially when it’s a massive group blog.

eg.
POST 1
2 months ago someone may of posted about a feature in the software that has an error with editing a file
- someone may leave a comment saying we are working on it, and here is a workaround

POST 2
2 months later what could happen is that someone else (different to the person who created the comment) may post that the problem with editing will be fixed in the next release and we won’t be getting this till next year. Plus we have made some patches to our software and the workaround that people were using to edit files no longer works

Now someone searching a blog may come across the first post, try the workaround and it fails.

What should of happened?

The person who made post 2 should have also left a comment on Post 1.
- but 2 months have past, are they going to remember, especially when they didn’t participate in the first post

Or perhaps the person searching could of browsed the tag “edit”, and would’ve found the most recent post about “editing”
- this wouldn’t be viable if 20 posts since then have been made about “editing”
- plus we have to assume the authors are using the correct tags

What would be good practice is that the URL of Post 2, be included in Post 1, this way Post 1 will have a trackback link, that takes you to the new post.
- even better, is something I have posted called “Sparklines” which rather than add a trackback link to Post 1, will automatically edit Post 1 and put the trackback link in the post itself.

But regardless of all this, we are relying on people to follow all these subtle rules.

The point I’m trying to make is, just because blog content is visible, it doesn’t mean it’s all correct, it’s not a website that is re-edited and updated, rather it’s a blog, where you write a new post as an update…old posts may be incorrect as time goes on.

Another example…

I made a blog post describing a particular functionality of a piece of software.

We now have a new release of this software and this month old blog post is now outdated.

What’s good practice?

I need to make a new post about how this feature now works.
Then re-edit the old post to point to the new post or a leave comment on the old post
- but what happens 5 releases later, will I have to update each past post?

What are your views?

Do we have to retro edit or comment on all blog posts to keep things neat and tidy?

Wikis for solutions

I’m much more inclined to use a wiki for a solution database, as the concept is more about going back to “the entry” and re-editing it.

In this instance the blog post is not the solution, but the messenger.

eg.
1. This wikipage is solutionA for errorA
2. Write blog postA to tell people about it, include perhaps some casual (personal) and contextual content
- also include the link of the blog post in the wikipage

So far this makes sense, but it has a high process barrier to entry as you have to share twice
- write the wikipage (perhaps via email), then write the blog post (perhaps via email)

A new patch on your software means that solutionA for errorA no longer applies
3. you re-edit the wikipage
4. Write blog postB to tell people about it, include perhaps some casual (personal) and contextual content
- also include the link of the blog post in the wikipage

In this example the wiki is the solution database that gets corrected and updated, where the blog is just the messenger, and old message become out-dated, but that’s OK, because we know the blog is currency based. This doesn’t matter too much anyway because if someone visits blog postA it will still link to the same wikipage, so they will land on the correct solution.

NOTE: it would be good to re-edit blog postA and include a link to blogpostB, or use trackbacks to link them together, or perhaps grouping them with the same tag is enough…either way re-editing blog posts is higher maintenance, or not as common as old posts fall off the radar, and people may be aware they are date-stamped and may be outdated.

A blog is a blog and a wiki is a wiki

The case I’m making is that I don’t think it’s safe or good practice to use a blog as a solutions database, it’s more for sharing current happenings, where posts do not get re-edited, rather a new post is made (just like newspapers).
The blog post is not limited to just pointing to the solution, it can involve some personal context and peripheral information, or workings out (experience) that led to the solution, whereas the wikipage is a more focused formal and official solution.

The scenario comes to mind of someone following what is said in a blog post causing some kind of error or disaster. It’s essential people understand the nature of blog posts, and that they are not official…perhaps a message could be reinforced in the banner, and people can leave comments to clarify before acting on information in a blog post

Whereas a wiki is generally not a newspaper, it’s moreso a book that never goes out of date as it’s pages are continually re-edited.

In saying this it seems, you could always trust the support wiki, and you can trust recent blog posts, but how recent?
Do you trust a blog post 2 weeks old, a week old…who knows that could now be old news.

I think as long as a blog post points to the wikipage solution, then whether you click on an old or new blog post about the same solution you will always land on the correct wikipage.

What about wiki comments?

I suppose an alternative is to subscribe to wiki comments
- if a wikipage is updated, a comment can be left to let everyone know
- in this respect the wiki comments double up as a notifications feature of current happenings (which is what a blog does best)
- it doesn’t make wiki comments a blog, but the comments can be used for a blog-like way of updating people

This post is the reversal perspective on the flexibility and visibility of social tools. That is these tools are so unstructured and flexible that we can use them for unique purposes (as Ross Mayfield says, we, the users, put the complexity into the software).

I don’t think blogs are harmful, but I think they are so unstructured that people may decide to use them for inappropriate purposes. The problem is that it may work at the input stage, but it may not work at the seeking stage. I have demonstrated a scenario above where it’s so easy to post solutions in a blog, but people seeking a solution may find an old entry of that solution…this is not friendly and may have consequences. Instead a wiki is a more official solution as only one page always represents the solution, and even better is combining its use with a blog so we can explain how we came to the solution.

Just consulting a wiki solution page we get a focused error and solution, but reading a companion blog post we get what happened at the time and thought processes involved. This blog post may give away clues or trigger a thought to solving another solution that the wikipage didn’t reveal, as the blog post is more diffuse, not as focused on the endpoint.

Unstructured tools like email have been used for purposes that just don’t stretch, eg chain conversations and announcements, problem being that it’s too closed and messy.

Social tools are not immune to being used the wrong way either.