During our Insight Event last week, Sam Dimond (Director of Knowledge Systems) outlined his thoughts on how to get started with social tools, drawing from his experience of the adoption of blogs and wikis in Clifford Chance.
Here is Sam's presentation along with his amazing notes - well worth a read!
"Define success
The success of these these initiatives depends on a new skill-set that's very much in the DNA of knowledge professionals. Wikis and blogs at Clifford Chance seem to follow the 90-9-1 pattern identified by Jakob Nielsen:
Reducing email - an example use case
The Clifford Chance Foundation is made up of staff from across the firm who have to review, approve or reject applications for funding from charitable causes. As a virtual group they have operational challenges. They can only have so many conference calls, and these must focus on reaching decisions quickly. If each application had to be emailed to every member, the number of interactions and disjointed discussions would be considerable.
Wiki collaboration - an example use case (cont)
Now they post each new application to their wiki. And do same for meeting agendas, minutes and communications they have to draft for management. Members get a daily e-mail alert with a link to the most recent version, where they can comment on the merits or draft. This is very easy for them to do. They can see who changed what and everyone's comments are kept organised by that topic. The wiki means far fewer interactions and less chance of missing something - much more efficient than relying on Word and e-mail. And because more discussion takes place beforehand, their meetings are far more focused.
Trainee lawyers' guide - another example use case
Wikis are also ideal for collaborating on a significant body of knowledge. Each year a few trainees are asked to create a "trainees' unofficial guide to groups and offices", to help trainees choose their next seats. We burst a wiki space into separate pages for each sub-chapter, for example, what type of work you will get in London corporate. One or more trainees can take responsibility for a single section. And they can track how others are drafting similar chapters. The whole thing is now created in days by many as opposed to weeks by a few.
Sector know-how
Wikis are also ideal for supporting communities of interest. Like Clifford Chance's new sector-focused groups of lawyers. Wikis are replacing Outlook bulletin boards for helping tacit knowledge to flow across the boundaries of practice and office, which includes notes about client opportunities and questions of the "has anyone come across a deal with one of these features...?" variety. In addition, the answers are kept and organised, rather than being lost in e-mail folders.
IT management blog
IT management found that a blog rather than a wiki was more suited to their needs. They wanted to replace their monthly newsletter which they felt to be too formal and tiresome to put together. By the time an article had been authored and approved, it was often quite out of date. So they now take it in turns to post to the blog, and have developed a more informal, opinionated voice. Communication is more timely, frequent and interactive, which seems to have helped strengthen the IT community, especially important during these times of instability.
Guerrilla project
Because we already had several big ticket projects going on we needed to run wikis as a guerrilla project, without proving an impressive business case or great financial investment. But this also felt right because the technology itself was frankly cheap and we didn't really know what to expect or indeed exactly what we were setting out to build. Anyway we decided to focus on three pilot scenario:
Page templates
The technology was also refreshingly simple. We had to integrate the software with our active directory, so users don't have to log-in with a password and so every change is attributed to a person.
At first we stumbled by creating page templates that were too rigidly defined by the pilot group's processes, e.g. project methodology. We quickly realised these weren't going to be flexible enough. So we focused on a generic page template which allowed us non-technologists to build different business applications by mixing components and macros.
Loose functionality
This meant we could respond easily to unexpected business requests. And it quickly became clear that we couldn't dictate exactly how a wiki's users would develop and use it.
For example, one HR manager needed to report on different IT security policies across the whole firm. So she set up a simple wiki table and asked each office HR manager to fill in their row. Each manager could see what others had written and what was expected, which helped identify and close gaps.
The wiki allowed a greater distribution of effort, faster turn-around time and yet still maintained some consistency
Central wiki team
The central wiki team certainly picked up a high level of expertise in the wiki. Working with the more advanced macros and wiki-markup language to build different applications. But generally there was a high degree of learning together with the users.
For example, many people contributed to the wiki-based repository of knowledge on how to use the wiki, its possible uses and pitfalls. That left us more time to focus on the considerable change management issues.
Poor communications
It definitely isn't a case of build it and they will come. If an existing community really doesn't communicate or share at all a wiki isn't going to change that over-night.
So it helps to start with existing or new communities that have an acknowledged need and desire to communicate and collaborate better. That influenced our choice to focus first on non-legal communities since they have a great need to share better but have enjoyed very little KM attention until now.
Leading by example
So how did we go about identifying the right communities?
At Clifford Chance, there's a regular workshop for senior managers on "working across borders" - about cultural and practical issues of working in virtual teams. I hijack part of that forum to demonstrate how to use a wiki to run meetings more effectively
Some managers invariably realise that wikis can help their teams or projects, and we can then coach them or team members in behaviours that will help succeed. For example, to show that contributing to blogs and wikis is encouraged, we know that the managers should respond to, not ignore, posts by more junior staff.
Role of gardener
Even if users are familiar with external social networking tools, it's a real shift to using them at work - no matter how easy they are to use. It requires a change in the way we work - especially for law firms. I believe that you can significantly boost your chances of succeeding by breeding good wiki gardeners - otherwise known as "wiki gnomes". These will be more junior members of the community, and they embody a new skillset for the knowledge management professional.
New skill-set
Gnomes show and remind people how and when to use the wiki. They tweak pages to improve the readability of content. They organise new additions to bring structure, for example, by tagging pages or by adding and fixing links. They do cosmetic editing, like weeding out typos, and encourage people to use the wiki by asking the right questions and seeding it with content.
Email problem
Gnomes also coach people on to use the wiki as an alternative to e-mail. Until they realise it's a good way of helping to reduce the information overload, e-mail is a strong obstacle because, for all its faults, it's so pervasive. At the very least you have to try and integrate your wiki with e-mail as much as possible. For example, use e-mail to alert users to new content, especially if you don't yet have well-established RSS technology.
Fear of editing
We've found that even with wikis, many people are still more comfortable treating them like blogs. So they're happier adding comments to the bottom of a page rather than directly editing text. Even when they do start editing they often continue to put their own additions in brackets or a different colour. It takes a while to show people that wikis make it easy to show who added what and when and to roll back to an earlier version if necessary. But with time and hand-holding people will realise that they can safely let go.
Nervous about posting
Another challenge with blogs is to grow the confidence in people that they have something interesting enough to say. Blog communities certainly flourish best if the contributors voice an opinion, even it's something quite provocative or controversial. It's better to describe a unique personal experience, for example, their take on a recent strategy announcement by management. Posting a corporate message won't attract comments, if that's what you're after. Since we're aiming for 5 quality posts a week, that's quite a challenge. One tip is to make sure people have a place where they can draft before posting.
Governance
You'll have gathered that the biggest problem appears to be getting people to use wikis and blogs as an alternative to more traditional methods. That said, management and especially IT are going to be concerned that they will be misused or will result in thousands of unused, unmanaged islands of content - the Lotus Notes syndrome. So the central wiki team therefore reviews each business case for a new wiki or blog.
They aim to review each every 6 months. To check that they aren't being used in ways we discourage, for example, client matter information, but usually their task will be to offer help on how to nurture the online communities."
Here is Sam's presentation along with his amazing notes - well worth a read!
"Define success
The success of these these initiatives depends on a new skill-set that's very much in the DNA of knowledge professionals. Wikis and blogs at Clifford Chance seem to follow the 90-9-1 pattern identified by Jakob Nielsen:
- 90% of the community read but don't contribute
- 9% contribute occasionally
- while only 1 % participate frequently.
Reducing email - an example use case
The Clifford Chance Foundation is made up of staff from across the firm who have to review, approve or reject applications for funding from charitable causes. As a virtual group they have operational challenges. They can only have so many conference calls, and these must focus on reaching decisions quickly. If each application had to be emailed to every member, the number of interactions and disjointed discussions would be considerable.
Wiki collaboration - an example use case (cont)
Now they post each new application to their wiki. And do same for meeting agendas, minutes and communications they have to draft for management. Members get a daily e-mail alert with a link to the most recent version, where they can comment on the merits or draft. This is very easy for them to do. They can see who changed what and everyone's comments are kept organised by that topic. The wiki means far fewer interactions and less chance of missing something - much more efficient than relying on Word and e-mail. And because more discussion takes place beforehand, their meetings are far more focused.
Trainee lawyers' guide - another example use case
Wikis are also ideal for collaborating on a significant body of knowledge. Each year a few trainees are asked to create a "trainees' unofficial guide to groups and offices", to help trainees choose their next seats. We burst a wiki space into separate pages for each sub-chapter, for example, what type of work you will get in London corporate. One or more trainees can take responsibility for a single section. And they can track how others are drafting similar chapters. The whole thing is now created in days by many as opposed to weeks by a few.
Sector know-how
Wikis are also ideal for supporting communities of interest. Like Clifford Chance's new sector-focused groups of lawyers. Wikis are replacing Outlook bulletin boards for helping tacit knowledge to flow across the boundaries of practice and office, which includes notes about client opportunities and questions of the "has anyone come across a deal with one of these features...?" variety. In addition, the answers are kept and organised, rather than being lost in e-mail folders.
IT management blog
IT management found that a blog rather than a wiki was more suited to their needs. They wanted to replace their monthly newsletter which they felt to be too formal and tiresome to put together. By the time an article had been authored and approved, it was often quite out of date. So they now take it in turns to post to the blog, and have developed a more informal, opinionated voice. Communication is more timely, frequent and interactive, which seems to have helped strengthen the IT community, especially important during these times of instability.
Guerrilla project
Because we already had several big ticket projects going on we needed to run wikis as a guerrilla project, without proving an impressive business case or great financial investment. But this also felt right because the technology itself was frankly cheap and we didn't really know what to expect or indeed exactly what we were setting out to build. Anyway we decided to focus on three pilot scenario:
- A project team organising a conference;
- A cross-practice policy-making group; and
- A legal knowhow group.
Page templates
The technology was also refreshingly simple. We had to integrate the software with our active directory, so users don't have to log-in with a password and so every change is attributed to a person.
At first we stumbled by creating page templates that were too rigidly defined by the pilot group's processes, e.g. project methodology. We quickly realised these weren't going to be flexible enough. So we focused on a generic page template which allowed us non-technologists to build different business applications by mixing components and macros.
Loose functionality
This meant we could respond easily to unexpected business requests. And it quickly became clear that we couldn't dictate exactly how a wiki's users would develop and use it.
For example, one HR manager needed to report on different IT security policies across the whole firm. So she set up a simple wiki table and asked each office HR manager to fill in their row. Each manager could see what others had written and what was expected, which helped identify and close gaps.
The wiki allowed a greater distribution of effort, faster turn-around time and yet still maintained some consistency
Central wiki team
The central wiki team certainly picked up a high level of expertise in the wiki. Working with the more advanced macros and wiki-markup language to build different applications. But generally there was a high degree of learning together with the users.
For example, many people contributed to the wiki-based repository of knowledge on how to use the wiki, its possible uses and pitfalls. That left us more time to focus on the considerable change management issues.
Poor communications
It definitely isn't a case of build it and they will come. If an existing community really doesn't communicate or share at all a wiki isn't going to change that over-night.
So it helps to start with existing or new communities that have an acknowledged need and desire to communicate and collaborate better. That influenced our choice to focus first on non-legal communities since they have a great need to share better but have enjoyed very little KM attention until now.
Leading by example
So how did we go about identifying the right communities?
At Clifford Chance, there's a regular workshop for senior managers on "working across borders" - about cultural and practical issues of working in virtual teams. I hijack part of that forum to demonstrate how to use a wiki to run meetings more effectively
Some managers invariably realise that wikis can help their teams or projects, and we can then coach them or team members in behaviours that will help succeed. For example, to show that contributing to blogs and wikis is encouraged, we know that the managers should respond to, not ignore, posts by more junior staff.
Role of gardener
Even if users are familiar with external social networking tools, it's a real shift to using them at work - no matter how easy they are to use. It requires a change in the way we work - especially for law firms. I believe that you can significantly boost your chances of succeeding by breeding good wiki gardeners - otherwise known as "wiki gnomes". These will be more junior members of the community, and they embody a new skillset for the knowledge management professional.
New skill-set
Gnomes show and remind people how and when to use the wiki. They tweak pages to improve the readability of content. They organise new additions to bring structure, for example, by tagging pages or by adding and fixing links. They do cosmetic editing, like weeding out typos, and encourage people to use the wiki by asking the right questions and seeding it with content.
Email problem
Gnomes also coach people on to use the wiki as an alternative to e-mail. Until they realise it's a good way of helping to reduce the information overload, e-mail is a strong obstacle because, for all its faults, it's so pervasive. At the very least you have to try and integrate your wiki with e-mail as much as possible. For example, use e-mail to alert users to new content, especially if you don't yet have well-established RSS technology.
Fear of editing
We've found that even with wikis, many people are still more comfortable treating them like blogs. So they're happier adding comments to the bottom of a page rather than directly editing text. Even when they do start editing they often continue to put their own additions in brackets or a different colour. It takes a while to show people that wikis make it easy to show who added what and when and to roll back to an earlier version if necessary. But with time and hand-holding people will realise that they can safely let go.
Nervous about posting
Another challenge with blogs is to grow the confidence in people that they have something interesting enough to say. Blog communities certainly flourish best if the contributors voice an opinion, even it's something quite provocative or controversial. It's better to describe a unique personal experience, for example, their take on a recent strategy announcement by management. Posting a corporate message won't attract comments, if that's what you're after. Since we're aiming for 5 quality posts a week, that's quite a challenge. One tip is to make sure people have a place where they can draft before posting.
Governance
You'll have gathered that the biggest problem appears to be getting people to use wikis and blogs as an alternative to more traditional methods. That said, management and especially IT are going to be concerned that they will be misused or will result in thousands of unused, unmanaged islands of content - the Lotus Notes syndrome. So the central wiki team therefore reviews each business case for a new wiki or blog.
They aim to review each every 6 months. To check that they aren't being used in ways we discourage, for example, client matter information, but usually their task will be to offer help on how to nurture the online communities."
0 Comments
Leave a comment