grow your wiki

Stewart Mader is tearing himself away from the Tooheys-scented teet of Sydney/San Fran wiki-meisters Atlassian and going out on his own. As a fan of Stewart's work, I wish him all the best and advise you to check out his offerings.

wikis for ray

Ray Sims made some comments on the Twitter post. This led to these two pictures which I am really not happy with. Can anyone come up with some better suggestions?

freezing out on the scarpa flow

Michael Idinopulos writes about in-the-flow and out-of-the flow activities and wiki beahaviour and Andrew McAfee takes his point a bit further. Andrew asks:

How outlandish would it be for a company to put participation in emergent social software platforms in the flow for at least some employees? In other words, why not put in job descriptions something like "being helpful at the enterprise level using digital tools such as blogs, wikis, folksonomies, Q&A forums, idea boards, comments, prediction markets, ratings, etc."

And then goes on to say:

I get the impression that few companies these days think of their employees as assembly line workers who should be focused exclusively on the job that’s right in front of them... I imagine part of the reason companies haven’t done much of this yet is that to date it’s been hard for people to work above and beyond their ‘normal’ jobs. Doing so typically involved physical displacement—hopping on a plane, going to a meeting, etc.— and so was time consuming, inconvenient, and often costly.

I suspect that may be a part of it but only a small part. I think the assembly line worldview is far more prevalent than Andrew realises. When I worked as a knowledge manager in a global consulting firm, we had terrible difficulties getting people to participate in knowledge sharing activities. While management consultants are paid far more than assembly line workers, there was a huge focus on utilisation and billable hours - and these people tended to work long hours. Many of them did not want to contribute to a wiki or write a blog on top of that.

I am a little cynical of the "rewriting job descriptions" suggestion as these are rarely worth the paper they are written on. My comment would be this: People follow their leaders. If senior execs are not contributing to this stuff then why would their juniors?

The tool formally known as wiki

James D talks about wikis and what they are becoming. James links to posts by Ray Sims and the Atlassian dudes. Wikis are essentially about simplicity and openness. So RS's comment that you'll find traces of wikiness (to a greater or lesser extent) on intranets going forward is right, I reckon. And lots of things will get badged wikis. But are they simple? And can I edit them?

Oh I have to master CSS? There's an approval process? Ahem.

Wikis are starting to gain a foothold in organisational information ecologies. And they are changing this environment and being changed by it in the process. And in doing so, they'll interact & transform surrounding tools - intranets, email (which takes a pounding in the Atlassian/Razorfish slides), etc.

Part of me relishes this impurity, this messiness. But it's OK, I have a powerpoint slide with boxes that shows how all these sworn enemies can get along just fine. There are arrows on the slide as well so it must be good.

Collaboration tools

James Robertson has been thinking about collaboration tools. Which is interesting because I have as well. As ever, James is practical & clear in his thinking and suggests a 5 phase model (0-4) for organisations thinking about collaboration. So here are the phases and my responses to them:

Phase 0: Fragmentation
As the usage of collaboration tools grows in an unmanaged and unconsidered way, so does the "fragmentation" of information. Key information is divided into ever-smaller spaces, locked up out of broad use, generating considerable information management and knowledge management problems. (This is not a search problem.)

Agree with this - and not only the fragmentation of information but the fragmentation of activities, relationships, etc. N.B. This is bad.

Phase 1: Gardening
The starting point is to identify an overall owner for the collaboration tools, and to put in place simple governance, policies and management. Rather than trying to restrict usage, the approach is one of "gardening", helping to guide usage , connect the dots and identify best practices.

Also broadly agree with this. Except that gardening might be the wrong word. This is about identifying the existing collaboration tools within an organisation. What they are. Who uses what. What activities they are used for. And then how these different tools might fit together. And where the gaps between them might be. Something like mapping perhaps? The concept of guiding usage is critical here - "Just enough governance".

Phase 2: Business solutions
The next step is to identify key (and common) needs, and build solutions that are tailored to meet them. In this way, clear user needs can guide how to bring together different solutions (wikis, blogs, lists) into more coherent solutions. Possible targets include project collaboration, teaching or e-learning, collaborative authoring, communities of practice or research.

Nothing to disagree with here. Using the map to produce repeatable toolsets.

Phase 3: Rich networks
Organisation-wide collaboration will only be achieved with the silos are broken down between different spaces. This involves recognising the difference between "inwards" and "outwards" facing spaces, and putting in place processes for sharing and linking between them.

Now many organisations are currently in phases 0 & 1. Several are starting to move to phase 2. Are there any out there that have reached phase 3? These rich networks will almost certainly be a federated model.

Phase 4: Coherence
This is the end goal, where there is coordination between the collaboration spaces at all levels, accessed through a personalised portal-like interface. The lines between different "tools" is blurred, creating a single working environment. (There's a lot to be done before anyone can reach this state.)

I look at phase 4 and go "yeah, right". The collaboration tool space is changing very quickly at the moment. Phase 4 feels like a utopia at the moment. And given this dynamic environment, a very unlikely utopia. I think many organisations have enough on their plate trying to get to phase 3. I would feel nervous talking about phase 4 because I can just see a senior exec going: "This sounds great, I want one of these by the end of the month!" and mayhem ensuing. What is more likely in the next 1-3 years are rich networks (collaborative ecosystems) and then richer networks - with tools dropping in and out. "Coherence" feels way too static to me as a goal at the moment.

What do you think?

Enterprise 2.0 Questions & Answers

So when you start talking about Enterprise 2.0 stuff, certain questions keep coming up. Here are some of the ones that I have heard from people in different organisations.

• Have you heard similar ones?
• Which other ones have you heard?
• Do my answers make sense?
• Do you have better answers?

1. We've had Forums / Lotus Notes around for ages. What's new about these tools?

Some social media technologies have been around for a over a decade. What is new is their pervasiveness on the internet and the way they are now leveraged to make connections. They are significantly simpler than previous enterprise collaboration technologies. However some (e.g. podcasts, social networking software) are genuinely new in the corporate environment.

2. Will these tools by themselves make people collaborate?

Implementing a wiki will not lead to collaboration by itself. However the simplicity of these tools can provide very usable platforms for groups (teams, communities, directorates) to achieve their collaborative goals.

3. Are they just fads?

Some deployments of these tools are faddish. However, many organisations are experimenting with them and seeing benefits. The longevity of some of these tools (e.g. blogs have been around for over 10 years) suggests there is more to them than "cool" value.

4. Do they fit into our IT architecture?

They certainly can. Our IT architecture should not quash experimentation & innovation but it should position it correctly. "Just enough" governance of these tools is a critical part of their implementation.

5. Won't more tools just confuse people?

If we are not clear on its role then any new tool is confusing. If there is a clear role for a new tool then we need to communicate it to potential users and position it next to other tools. This is another governance issue.

6. Are their security risks associated with these tools?

If they are implemented poorly there could be a security risk but then this is true for any communications technology. If users are clear on what they should and should not share then security risks are minimal.

7. How will we manage all this content?

Some social media tools promote content management (e.g. folksonomies & social networking software) through non-traditional means. From a broader perspective, we need to examine the findability for all of its content – not just social media. Robust search and analytics tools are critical for effective management of these resources.

Wiki highlights

Patrick Lambe proposes a "wiki raid". I like that this uses wikis with a team in a room together around a real business task. It cements the idea of the wiki as something simple, useful, quick & collaborative. In effect you are establishing wiki behaviours up front. I may well be stealing this shortly.

James Matheson & Andrew Mitchell were both talking more wikis at the NSW KM Forum last night.

Andrew talked about 3 kinds of info his team's wiki: Eternal Truth (stuff that is correct for a long period), Past Truth (stuff that was once useful but is no longer current) & Collaboration (stuff that multiple people are working on now).

James talked about 3 specific wiki behaviours:

1. If you have something to write, write it on the wiki.
2. If you need to send an email, send a link to the wiki page.
3. Check the recent changes.

So there you have it - go forth & wiki.

Wiki reliance

About a month ago, I was talking to a friend involved with wikis & collaboration at a major corporate. The thorny issue of "governance" came up. What do you need to manage with a wiki. Now part of this relates to the previous post around where wikis fit in with the plethora of other collaboration tools that most organisations have. The other issue is one of "reliance". So if a group (a team or a community) is using a wiki for their own purposes, that's OK. If other people come to rely on their content in a major way, does this then need to be managed more tightly. What do you do about "reliance"? Do you end up moving from the left to the right of the "after" diagram here. And if so, how do you make that decision?

Now if your organisation has decided that your wiki is your intranet, not really an issue. The thought that came to my mind was: viewer metrics are key here. If you have a team of 10 people working on something and only 10 people visit those pages, no worries. If 10,000 people visit those pages then that may indicate that this stuff is becoming important. And hey, it might even be worth investing in developing this content more.

What do you think?

Collaborative ecologies

So everyone is playing with enterprise wikis, quietly. James Dellow outs CSC's wiki efforts. In trying to make sense of the ways in which wikis are being used, the following diagrams came to mind.

First, the "before":



And then the "after":



The basic point here is that whilst a few organisations are using wikis as their whole intranet, most people are using them to replace / augment the standard content collaboration tools found in organisations i.e. email & MS Word.

Wikis - middleware for humans

This entry barely reaches the level of "soundbite" let alone "article" but it struck me the other day that wikis are basically middleware for humans.

Just as SOA, BPEL, WSDL & SOAP (google 'em) aim to link previously isolated automated applications and allow them to collaborate together, so wikis allow people to link together information (& each other) in a collaborative way.

The fact that enterprise wikis are being used in heterogeneous environments should come as no surprise - as that's where middleware can add the most value.

Secret wiki business

MIS Australia podcast on Secret Wiki Business. Wikis as a knowledge sharing tool get a name-check. Very pertinent comment: people are using wikis and other simple tools for sharing as they were burnt by big, clumsy KM tools in the late-90s. You can expense a wiki as a cab charge - you don't have to issue an RFP. And it's yours - you own it not some git in IT.

Source: ABB

Meanwhile http://www.anecdote.com.au/archives/2007/08/wiki_patterns_1.html namechecks wiki patterns (also mentioned in the podcast) and places wikis in the complex domain. I'd agree with some caveats:

• The uses of wikis can be complex because for many organisations they are still new and poorly understood.
• The uses of wikis can be complex because they often involve many individuals collaborating P2P in the same space.
• The uses of wikis can be complex because they work in heterogeneous environments on the internet (with blogs, Flickr, YouTube, etc) or inside the enterprise (with ECM, EDRM, yadda yadda).
• The uses of wikis is not always complex. Once a small group of people using a wiki have settled down then it may become simple.