Given that the typical user spends several hours each day using email it just got to be a valuable store of potential knowledge.

For the past couple of weeks I’ve been trying out xobni.

This is a plugin for MS Outlook that gives an additional layer of information extrapolated from the email store. Initially I thought it would be something of a fun gizmo but now I’m quite taken with it.

Xobni (which btw is ‘inbox’ spelt backwards), runs in a separate pane that integrates with the main outlook application. For a currently selected email it will give you a conversation based view of the email, an analysis of the volume of emails sent/received with the particular sender/recipient, an extrapolation of their phone number, a social network type view of the sender/recipient (ie who they also typically include on their emails) and a list of files exchanged with this email sender/recipient (ie attachments).

Of these, perhaps the most useful feature is the ‘file exchanged’ view. How many times have you spent ages digging away in your email folders looking for a particular file you sent or received?

The most amazing thing, though, is the search which is just lightening fast and very accurate. I’ve been using this a lot. I don’t know how many hours I’ve wasted using the built in MS search looking for some long ago sent or received email.

Xobni also provides some fun analytics such as who responds the most quickly to your emails and the peak times of day that a particular user sends / responds to emails.

All in all, this is an amazing bit of software and I’d strongly recommend it to anyone running outlook. Apparently, MS have been sniffing around Xobni looking to buy it but the xobni people have held out… well done… I think they are really onto a winner with this… I just hope they have thoroughly patented the great ideas in their code. With any luck we’ll be seeing this kind of functionality, ie a knowledge based view of email, appearing in more email applications both desktop and web based.

Twine’s stated aim is to enable people to share knowledge and information. In broad terms it’s an “intelligent” wiki that understands a lot more about the relationships between the information it holds.

Twine is about “Knowledge networking”, it aims to connect people with each other “for a purpose”. It’s not based around socializing, but to share and organize information users are interested in. Content can be added via wiki functionality, you can email content into the system, and “collect” something (as an object, e.g. a book object).

Other features of Twine include: RSS feeds to track all kinds of things (topics, events, search, etc); commenting and viewing related things, sharing tags, and the ability for users to import and export their own data. Twine has a kind of blog functionality which they call your own “twine”.

Where Twine is differentiated from the likes of wikipedia is that its underlying data structure is entirely Semantic Web. Twine uses the following Semantic Web technologies RDF, OWL, SPARQL, XSL.

At the moment there isn’t a lot of content in twine and maybe this is the biggest turn off to the casual user.  While it offers a great range of features and is really the kind of product that brings together most of what’s needed in a knowledge management solution, there is quite a big conceptual barrier to first time users and a lot of complexity is exposed on the surface.  I think it would be much better to offer a simple easy entry point with progressive layers of complexity as users get more into the system.  Google is the ultimate demonstration of this “progressive layers of complexity” approach.  Google have an incredible range of functionality on offer but the start point into their systems is deceptively simple.

I’m still debating whether I want to put in the effort to really start using twine as it’s a big commitment to start creating content in order to get something out of it.

There lies the rub, despit all the great functionality, if they can’t get users putting content into it then it’s not going to fulfil it’s potential.  Maybe it will end up being an online software solution for organisations looking to implement knowledgement management?  My first thoughts were that this might be a more appropriate use of the system as it currently stands, rather than a consumer focused web 2.0 application.

Therefore a clearly defined up front business case is a must.

A report by Intellect UK makes some interesting observations / cite research regarding the field of knowledge / document management and why organisations need to get serious about it.

• The average organisation loses half its knowledge base every 5-10 years through turnover of staff, customers and investors, this greatly affects its competitiveness and value.
• 80% of knowledge workers’ activities are crucially supported by documents, yet they spend up to 50% of their time searching fro relevant information and data, a drain on valuable staff time that impacts on business-critical activities.
• An organisation of 1,000 staff will waste on average £2.6m a year in staff time that has been spent looking for information, as well as wasting resources.  This greatly impacts on an organisation’s agility and ability to respond quickly and effectively.
• Most managers believe that, apart from database support, systems support for information management is poor.  Access controls are weak, search facilities are ineffective, compliance is patchy and risk is likewise high.  Consequently organisations do not know what information assets they own, where to find them, who has responsibility for them, what value they have, and whether they should be kept or deleted.
• On average staff spend 9.6 hours a week searching for information.
• New information created on paper is growing at an average of 36% per year.
• 38% of staff admit to being caught out by not having the correct version of a document.
• 67% of managers believe that information is so easy to steal, it is impractical for employers to protect it.
• An organisation of 1,000 staff will lose on average £2.8m per year on wasted staff time used for converting information from one format to another.
• 42% of an organisation’s knowledge is held in the heads of its staff.
• A company’s paper filing doubles in size every five years.
• 22% of staff have lost an important email attachment.
• Email generates 400,000 terabytes of new information every year.  41% of staff spend up to fours hours  a day on email.
• At any given time, 3-5% of an organisations’ files are lost or misplaced, replacing these costs on average £100 per document.

Now if we can address some of the above we are addressing real business issues, delivering tangible, measurable benefit and should be able to get some executive buy-in !!!

He refers to Nielsen’s research on participation inequality, in particular the 90-9-1 rule and claims that in his experience community participation can be much greater if the Wiki is strategically implemented in a way that works for the organisation … Sherif claims 60-20-20 participation.

Here’s a summary of Sherif’s 7 recommendations :

1. Pick a good Wiki

Nielsen sums up participation inequality in the 90-9-1 rule

• 90% of users are lurkers (i.e., read or observe, but don’t contribute).
• 9%of users contribute from time to timebut other priorities dominate their time.
• 1%of users participate a lot and account for most contributions: it can seem as if they don’t have lives because they often post just minutes after whatever event they’re commenting on occurs.

Earlier studies also suggest a similar distribution. For example, researchers looking at Usenet newsgroups, CompuServe bulletin boards, Internet mailing lists, and internal discussion boards in big companies found that some 27% of the postings were from people who posted only a single message. Conversely, the most active 3% of posters contributed 25% of the messages.

Fast forwarding, in 2006 there were about 1.1 billion internet users with about 55 million blogs (5%). Only about 0.1% of the blogs are updated daily.

It seems then that a disproportionately small number of internet users are generating the content, views and general trends on that are coming through the medium. This is a great quote from Nielsen that succinctly states the phenomenon in the context of amazon.com reviews :

”Furthermore, at the time I wrote this, 167,113 of Amazon’s book reviews were contributed by just a few “top-100″ reviewers; the most prolific reviewer had written 12,423 reviews. How anybody can write that many reviews — let alone read that many books — is beyond me, but it’s a classic example of participation inequality.”

In another one of my posts I suggested segmenting the community as a way to incentivise participation (particularly in the enterprise setting). I suggested categorising the user base as one of the following

• Content contributor (mostly consumes, very occasionally contributes)
• Peer producer (has made an important contribution that is of value to the peer community)
• Mass collaborator (highly active, recognised authority and domain expert).

What does Nielsen suggest to encourage participation by the community?

• Make it easier to contribute. The lower the overhead, the more people will jump through the hoop. For example, Netflix lets users rate movies by clicking a star rating, which is much easier than writing a natural-language review.
• Make participation a side effect. Even better, let users participate with zero effort by making their contributions a side effect of something else they’re doing. For example, Amazon’s “people who bought this book, bought these other books” recommendations are a side effect of people buying books. You don’t have to do anything special to have your book preferences entered into the system. Will Hill coined the term read wear for this type of effect: the simple activity of reading (or using) something will “wear” it down and thus leave its marks — just like a cookbook will automatically fall open to the recipe you prepare the most.
• Edit, don’t create. Let users build their contributions by modifying existing templates rather than creating complete entities from scratch. Editing a template is more enticing and has a gentler learning curve than facing the horror of a blank page. In avatar-based systems like Second Life, for example, most users modify standard-issue avatars rather than create their own.
• Reward — but don’t over-reward — participants. Rewarding people for contributing will help motivate users who have lives outside the Internet, and thus will broaden your participant base. Although money is always good, you can also give contributors preferential treatment (such as discounts or advance notice of new stuff), or even just put gold stars on their profiles. But don’t give too much to the most active participants, or you’ll simply encourage them to dominate the system even more.
• Promote quality contributors. If you display all contributions equally, then people who post only when they have something important to say will be drowned out by the torrent of material from the hyperactive 1%. Instead, give extra prominence to good contributions and to contributions from people who’ve proven their value, as indicated by their reputation ranking.

Harvard professor Andrew McAfee (left) is credited with coining the phrase “Enterprise 2.0? — which is basically Web 2.0 for businesses .

He previously viewed blogs as a medium for teenagers to journal about meaningless ramblings. Now, he relies on blogs on a daily basis. “I think the blogosphere is my single most valuable source of information… I’m amazed at the non-patheticness [of it]”.

McAfee asserted that many of the tools in the Enterprise 2.0 toolbox are aimed at replacing e-mail but noted that it will be difficult to unseat e-mail in many organizations because it is so ingrained. “We tend to overweight the value of our incumbent technologies,” he said.

The core of Enterprise 2.0

The collaboration tools of Enterprise 2.0 are not about replacing e-mail as much as they are about allowing e-mail to simply be a messaging platform and not a collaboration platform. Right now in most organizations, e-mail is the primary means for sharing and collaborating on files and doing group-think for geographically dispersed groups. However, e-mail was never designed for those functions and is not very good at them.

Enterprise 2.0 tools are about making collaboration more efficient and effective by providing better ways for groups (either standard teams or groups gathered for a short-term project) to share and edit files in real time with full version tracking and easier replication/transfer. Plus, the groups need communication tools like IM, forums, comments, Wikis, shared whiteboards, and/or VoIP to collaborate because e-mail quickly becomes cluttered and difficult to track when multiple people jump into a thread.

The next great battleground

Both startups and established tech companies have realized the potential for improving productivity with Enterprise 2.0 tools, so there’s an all-out race to create a great collaboration platform that will gain critical mass.

Every company is taking a slightly different approach to building a collaboration platform, often based on their strengths with previous products. Some are approaching it from the angle of an intranet portal, while others try to do it with an SaaS (Software as a service) platform that they host. Still others are doing it with a distributed approach using fat client P2P-based software.

Microsoft has a head start with two different approaches: SharePoint (portal) and Groove (fat client). IBM is using WebSphere to make its collaboration play and is also developing middleware for mashups to help fuel other platforms. However, the most interesting work is coming from the startups.

Zoho has built best-of-breed online office apps and threaded in collaboration features from the ground up. ThinkFree (right) has reverse-engineered Microsoft Office file formats and done a better job than Microsoft of creating a business-ready portal for collaborating on them. Collanos has built a peer-to-peer collaboration workspace that is probably easier to use than any of the other platforms.

#1: Start with the basics — incorporate everyday tools

Choose software with familiar, everyday tools, such as e-mail integration, Wikis, and instant chat. This makes introducing new software less intimidating right from the start.

#2: Consult users

Consult the people who will actually be using the software before making a purchase. Take it from the experts: “IT professionals, project managers, and business development managers should provide input into the PPM [project and portfolio management] investment decision; otherwise, the tool might not be capable of providing all promised benefits.” –Daniel B. Stang, Gartner research

#3: Try subscription-based

Subscription-based pricing is more flexible, so you can deploy on a small scale first to make sure it is right for your company. Pay-as-you go flexibility allows organizations to add or subtract functionality as needed, so you’re not locked into expensive commitments.

#4: Collaboration promotes adoption

Tools that offer enhanced collaboration abilities lead to more rapid adoption, as teams can grow virally and expand as more employees are pulled in.

#5: Simple, effective user interfaces.

Remember that it’s a user interface, not a developer interface — navigating the system shouldn’t be like solving a Rubik’s cube or completing a scavenger hunt. Rather, it should be brilliant in its simplicity. Choose software with a friendly, intuitive interface designed with the end user in mind, and people will be more willing to give it a try.

#6: Fast deployment = fast adoption

Common sense tells us the quicker a solution is deployed and is up and running, the quicker employees can familiarize themselves with it. T

#7: Adoption flows downhill

Lead by example. If others see team leaders using the software, they will be motivated to follow suit.

#8: Less is more

Make sure to distinguish between “must have” and “nice to have.” Inundating your team with a solution that has all the bells and whistles will intimidate and veer users away from a smooth adoption. Apply the 80%-20% rule. It works!

#9: It takes a village community

Offer a help community — quick, anonymous online assistance forums for troubleshooting and shared experiences.

#10: Offer cash rewards

When all else fails, bribe employees with cash and/or fabulous prizes.

After six months, traffic to the internal wiki was exceeding typical traffic to the company intranet, has grown to more than 2,000 pages and is used by about 25% of the workforce. Dresdner Kleinwork have around 6,000 employees, so that’s about 1,500 employees who use the wiki.

The organisation claims that the internal wiki has decreased email volumes by up to 75% and cut the company’s meeting times in half.

This is an interesting case study. The projections on volumes for wiki implementation in this blog roughly correlate to this case study.  Looking at Wikipedia statistics, I deduced that a Wiki rolled out to an organisation of 15,000 employees would result in a Wiki of around 20,000 pages (in time).

It still amazes me that after all these years, email is still cited as the number one killer application on the internet. Mayfield says;

“For a long time, personal productivity tools and applications – the kind Microsoft makes – have been centred on a single user who generates documents. You also have highly structured enterprise systems designed and implemented from the top down – in many ways as an instrument of control – with rigid work flow, business rules, and ontologies that users must fit themselves into. The problem is that users don’t like using those kinds of tools, and what they end up doing is trying to circumvent them. That’s why ninety percent of collaboration exists in e-mails.”

Mayfield goes on to claim that the average Fortune 1,000 employee spends four hours a day in their in-box and that organisations have reached a point where e-mail is “breaking down” with only 10-20% of email time being productive time.

I think that there’s definitely some truth in the above, in my experience e-mail in the enterprise is overused as a tool of collaboration and document exchange.  I think the issue with wikis, though, is getting the momentum behind it.  E-mail works because everyone is on it.  Similarly with a wiki, if it’s going to work.  Check this post for some idea on the numbers.

One ray of hope in the midst of the hopelessness was the emerging maturity of interative web technologies and the tools of online mass collaboration.

David Geilhufe and a handful of volunteers began developing software to compile XML format data of identified victims. This screen scraping software automatically scanned a wide variety of disparate web sites, forums, bulletin boards and so on. However, human assistance was needed to compile the data as well and after a high profile call to action, largely through the blogoshpere, some three thousand collaborators had compiled 50,000 entries within 3 days (this eventually rose to 650,000). Salesforce.com donated much needed infrastructure for the hosting and database requirements.

The project serves as an example of the roll that the Internet and the tools of mass collaboration need to play in a modern day emergency response / relief effort situation.

Of these, about one hundred thousand have contributed 10 or more entries.

A core of about five thousand users contribute frequently and keep the site running.

What this suggests is that for a rollout of a collaborative wiki, say in an intranet environment, we can expect 10% of the user base to make a useful degree of contribution (lets call them the ‘peer producers’) and about 1/2 % to become frequent contributors (let’s call them the ‘mass collaborators’).

From this we can, perhaps, derive some figures on the minimum community size needed to create an effective wiki.

Personally, I would say for a good robust in-house Wiki you’re going to need about 50-100 users from the overall the user base to get really hooked on it, make regular updates, monitor other updates, correct errors and opinionated entries and so on (the ‘mass collaborators’). Anything less that this and it’s not going to really get traction.

50-100 mass collaborators is going to suggest 1000-2000 peer producers and a necessary overall user base of 10,000 to 20,000. Roughly this is going to produce a Wiki of 1,500 to 3,000 pages (wikipedia has over 10 million pages, about 2.3 million in English).

It’s fair to say, then, that a wiki ***properly*** rolled out to an intranet of 15,000 users is going to produce about 0.2% of the knowledge as contained in Wikipedia.

Most of us think of google as the mother of all search engines. Well it is but it also one of the most successful examples of collaborative filtering. Matching keywords and generating a search engine results page is pretty straightforward; sorting the relevance of those matches isn’t !

Google alerts allow you to specify your keywords and then get a daily or weekly digest of the most relevant matches for these interests. You can also include results from youtube.

I’ve become pretty hooked on google alerts. I usually read through the alert because there’s always going to be something in there of interest to me.

On the other hand, I played around with friendster some time ago. This system, aims to keep you connected with a never ending stream of emails telling you when one of your friends has updated their profile, has a birthday coming up and so on. Now for me that’s overkill. In an enterprise environment we have to be sensitive to email overload. I’ve seen reports that employees spend up to 4 hours a day on email… there’s an argument for moving to the wiki workplace!

I think the ideal knowledge sharing / collaboration system should produce a google type alert to community members (optional of course) that is based on their explicitly stated interests and/or what is implicitly known about them. This of course means that having a powerful indexing and predictive results sorting component is essential.

There’s been some debate about how good google can be inside the firewall (no backlinks). Google have said that backlinks are only one part of the overall page rank algorithm. Well that’s something that I’m going to have to look into in a lot more detail.

What is particularly interesting in the classic peer production cases, e.g. Linux, is that for a good proportion of the production there is no direct monetary compensation. Why participate then.? Clearly, the peer production model involves more complex systems of compensation.

In an enterprise model, an employee may not necessary gain direct financial benefits by making extra contributions on the company wiki or contributing in other ways to the process of mass collaboration. However they stand a very good chance of earning considerable kudos and attracting attention, earning a reputation for themselves and hence enhancing the opportunities for further downstream economic gain.

It seems, then, that when implementing collaborative technologies in the enterprise we need to incorporate models that will recognise the knowledge workers who make considerable contributions to the corporate body of knowledge. Online profiles should make it clear the extent to which an individual is involved in and contributing to the collaborative knowledge base.

Perhaps a rating scheme, something along the lines of the loyalty points system that airlines use would work? For example, contributing X number of articles to the corporate wiki earns a certain recognition status. Producing a blog of a certain scope earns some sort of “expert” status in that area. Add the social networking piece to the mix and it becomes a powerful incentive for knowledge workers to participate in the collaborative workplace.

Here is my suggestion for segmentation of the community :

• Content contributor (mostly consumes, very occasionally contributes)
• Peer producer (has made an important contribution that is of value to the peer community)
• Mass collaborator (highly active, recognised authority and domain expert).

“…four principles – openness, peering, sharing and acting globally – increasingly define how twenty first century corporations compete. This is very different from the hierarchical, closed, secretive and insular multi-national that dominated the previous century.”

“…the organisational values, skills, tools, processes, and architectures of the ebbing command-and-control economy are not simply outdated; they are hadicaps on the value creation process.”

“In an age where mass collaboration can reshape an industry overnight, the old hierarchical ways of organising work and innovation do not afford the level of agility, creativity and connectivity that companies require to remain competitive in today’s environment.”

It strikes me that this is especially true of large, globally dispersed organisations.

I’ve worked in small to medium enterprises / organisations, often under limited funding and it always struck me how much we could achieve in that environment on limited resources; compared to large well structured better funded multinationals. Maybe the emerging “wikinomics” will enable large multinationals to incorporate some of this agility and light footedness.

Indeed, this is at the heart of the information revolution that has been upon us since the uptake of the web. Ideas, thoughts, opinions, facts from all corners of the globe are only a series of clicks away.

Looking at an organisation that has a deep investment in legacy systems, various silos of information, some web based, some not, it’s all too easy to take a technically driven approach to facilitating greater collaboration, knowledge sharing and interaction across the global enterprise.

We need wikis… we need blogs… we need social networks… we need better search … we need collaborative filtering… personalisation … and so on.

For me personally, I would ask the question… all of the above is available, free of charge, in shedloads to anyone with an internet connection…. to what extent are the employees and partners of an organisation already involved in and using knowledge sharing tools? If so, how can it be done better if the organisation is to provide it’s own in-house knowledge sharing platforms? If not, what can we reasonable expect to achieve. How ready is the enterprise to really begin using these technologies in a way that results in new creations, new collaborations, new strategic directions?

What needs to be done to facilitate the right level of readiness so that the introduction of tools and technologies will actually be fruitfull?

Is our wonderful document respository, web based and tightly integrated to desktop applications going to be little more than a glorified file share?

“The fact is that ‘social computing’ cannot be implemented without trust between employers and employed, between colleagues and between departments. It holds the potential to destroy hierarchies and demolish departmental silos. Paradoxically, it can also protect and strengthen these things, if this is what the company really wants.”

It’s interesting to consider how the introduction of knowledge sharing tools in an enterprise may start to challenge existing hierarchies and relationships. Especially those with highly ordered structures and staff ranks such as governments and international organisations.

What happens when a “lowly” administrative staff member begins to question and correct the work posted by the PhD domain expert on the enterprise wiki? What about when a particular staff member develops a reputation as a domain expert of a particular topic or set of topics within the enterprise social network and becomes a trusted authority on it… despite the fact that it is outside their job description and they are not compensated in the same way as the “official” experts?

Is it possible that the enterprise knowledge sharing / knowledge management platform may start to take some of the power away from predetermined command and control structures and introduce elements of a “self organising system” into the enterprise?

This would of course be a great opportunity for some, but for others quite a threat.