Introduction
This paper describes the process Field Fisher Waterhouse (FFW) went through in utilising wiki software within the firm for knowledge management and knowledge sharing. At FFW we have a document management system (DMS), a know how database with enterprise search and a new intranet (both subjects at recent BIALL Conference seminars Rudman, Reference Rudman2009 and Jannetta, Reference Jannetta2008) yet with an increased need to provide opportunities to collaborate between our offices, we considered using a wiki as a solution.
The project began tentatively in 2008, with the Knowledge and Information Services (KIS) team trialling various wiki software. At the time, the team had little familiarity with wikis, having only ever seen Wikipedia, but not contributing to content. The team set up trials on PBWorksFootnote 1 (the wiki software used for the BIALL How Do I? wiki), MediaWikiFootnote 2 (used by Wikipedia) and Confluence by AtlassianFootnote 3. These trials allowed the team to see the benefits of such software and how they could be applied at FFW.
The benefits of the wikis were the solutions we were seeking at FFW. We wanted something to allow for increased collaboration, cross-departmental and cross-office working which would provide for more dynamic content. There was a desire to have something which would aid departments or groups which were split geographically; an example of this is the KIS team who are situated in the practice groups across two buildings in London and in Brussels. We also wanted a system which would allow for knowledge sharing; our know how database is not suitable for all types of knowledge, so we needed something which would complement it, but not detract from it.
Project development
Management buy-in
Our wiki did not come free so, before the wiki project could start, we required approval from the Board, both in terms of the cost and also that it was a project they believed in for the benefit of FFW. The project was approved and we have seen further demonstrations of the importance of wikis to the management team through a recent firm-wide initiative which directs groups to consider if wikis and blogs are appropriate to what they are doing.
Implementation
From the trials the KIS team conducted, Confluence was chosen as the preferred solution and implementation began in mid-2009, working with an Atlassian partner, Noko.
Initially Noko hosted the wiki on their servers for testing and it was then moved in-house. Once the wiki was established, a single-sign-on (SSO) solution was implemented, which allowed users to access it without a username and password, an important feature for adoption. SSO was also important to combat some technical issues we had. When the wiki was moved in-house, we encountered some obstacles with users accessing Confluence, which delayed us promoting wikis fully to the firm. We did not want to try to “sell” the wiki when there were still bugs in the system. Once we had SSO, the access issue was resolved.
In the early days of the wiki, a number of test spaces were created. These acted as a place for new users to experiment with the wiki, as well as for the KIS team to build their space so it could be used to demonstrate how wikis worked. The FFW “brand” was applied to our wiki spaces and templates were created to give some kind of consistency across homepages. These templates helped to create spaces quickly, so there would be minimal time and effort spent when a new wiki space was requested.
Our wikis, where appropriate, were also integrated into the intranet, with links from departmental pages to their related spaces. Figure 1 shows a wiki space, being used solely as a blog, integrated into the intranet.
Figure 1: Wiki space being used as blog – Dispute Resolution blog
Encouraging adoption
As with any new technology, use is not instantaneous and time is needed to explain wikis to the business, allowing people to understand the wiki concept, to see the benefits of wikis and to understand that our wikis are not like Wikipedia. At the time of writing, the wikis in FFW are still in pilot stage and, although we have not been using wikis for long, we have discovered some methods to help adoption in a law firm.
Test spaces
We set up test spaces to get to grips with the technology and the KIS team were the first to do this and then illustrated the functionality to others. The KIS wiki space has since become one of the most developed, containing a whole host of information, from contact details for suppliers to know-how on enquiries and it contains a blog to flag up new items of interest (Figure 2).
Figure 2: KIS home page
Demonstrations
We gave demonstrations to practice groups and to business services. To date we have demonstrated to all business services groups and most fee earning groups. These demonstrations worked on two levels:
1. For the users to query things they did not understand and for us to put their concerns at rest.
2. For the KIS team to get an insight into how wikis are perceived.
At these demonstrations, the wikis were not forced on the groups, nor were any spaces set up without an approach from a group first. The demonstrations allowed the groups to think about them and consider in their own time how they might use this technology.
Intranet integration
Embedding the wikis within the framework of the intranet was important to get people to adopt them. It shows how the technology works within existing infrastructures (Arconati, Reference Arconati2010) and gives seamless access. Being on the intranet, the wikis were also much easier to find and for users to stumble across.
“Stealth” adoption
This tactic involved moving essential content into a wiki space or page, thus people began accessing and using the wiki without realising it. Users can become comfortable with the wiki, before using it for their own project.
Watercooler moments
One of the recent ways of getting wikis adopted is using chance meetings with people to discuss their current work and see if a wiki could offer help. In a meeting with the fraud team, we realised how a wiki would help with a current project they had; this enabled them to have one place to access all relevant material, whether stored on the DMS or on the internet. This space has grown considerably over the past months and is an excellent example of how the wikis are being used.
Benefits
We have really started to experience the benefits of the wikis, although it is still early days.
Greater productivity
For the KIS team, the wiki has become invaluable. We have used it to draw together all information relating to our suppliers and databases into one space. Previously this information was in various documents and emails and in people's minds. It was difficult to locate and work out what the latest position was on a particular matter. Now there is one page for one database, with information ranging from our account managers' contact information to relevant terms and conditions. We have seen this as a time saving measure and it has increased our productivity.
Project management
We have also found the wiki useful for managing a project. A page will be dedicated to the project which will contain all the relevant information e.g. those involved, latest stages reached. We found that before a meeting took place we would discuss the project online. When it came to meeting face-to-face, these online discussions had already given us a rough agenda to follow and some solutions partially worked out. The wiki is certainly not a replacement for meetings, but it has made us more productive when meetings do take place.
Team communications
The blog functionality has proven useful for communications amongst teams. Some wiki spaces are dedicated blogs (Figure 1. The Dispute Resolution blog) and some use the blogs within an existing space (Figure 2. KIS wiki space). Several have been set up and are used regularly in the teams, including employment, dispute resolution, professional regulatory and those interested in the gas industry. They have provided a way of keeping teams up to date without flooding their inbox with emails and as a central storage point for any of these updates.
Library knowhow
The KIS team are using the wiki to store know-how related to enquiries. Before the wiki, we did not store answers to enquiries which would potentially be useful in the future; the knowhow database did not seem appropriate and the KIS team do not have colleagues near them to ask. Having these pages saves time when answering repeat enquiries. These pages are much like the BIALL wiki but more appropriate to our own resources.
Points to consider
Whilst we have seen the benefits of the wikis and had successes, there have been issues we have come across and the process of implementing wikis has not all been plain sailing.
Barriers
We have found that having any sort of barrier to the wiki hinders adoption. One barrier is low visibility: whilst the wiki was on our own servers, it was not visible on the intranet. Integrating the wiki in the intranet overcame that visibility problem. Another barrier is the request for a username/password to access the wiki. Such a facility is available on external wikis like the BIALL wiki, but as this wiki is internal and most of our systems are IP recognised, the expectation was not there. The sign-on requirement became a barrier as people thought they were entering a space they were not allowed to enter, or would not be able to access. The SSO solution overcame that barrier and this greatly increased the use of the wiki.
“Empty wiki syndrome”
Empty wikis do not attract users. Content is needed for people to begin using them. When the KIS team has set up a wiki space for a department, we populate it with basic information or give it a structure before promoting it.
Measuring success
We have discovered that it is very useful to have statistics and a reporting function for the wiki, to see how much it is being used. What we have not determined is when we consider a wiki project to be successful. Is it the first blog post or the 50th? From the limited reporting function we have (Figure 3) we can consider them a success, but we have not defined our parameters for “success”.
Figure 3: Reporting function
Misconceptions
We have encountered the assumptions people make about wikis and how they view them. From our demonstrations to practice groups, we have found there are a number of preconceptions people have about wikis and we needed to be prepared to respond to them. Common ones we found were that they were confused with Wikipedia, or were social places like Facebook. Our Atlassian partners Noko suggest we do not use words like “social” or “wiki” when selling wikis to the business as they generally have a negative impact (Attewell, Reference Attewell2010).
Future developments
Our use of Confluence is not even a year old, and we are looking to the future. Some things we are looking at include better reporting and statistics, upgrades by Atlassian which will provide additional or alternative functionality and features, archiving of wiki spaces which are no longer used, integrating the wiki in our enterprise search and the use of RSS from the wiki to feed into our intranet.
Conclusions
The use of wikis at FFW has so far been successful. We have seen the benefits of installing them, even though we are still in the pilot stage, and we have identified problems which colleagues planning to introduce this technology should be aware of. Our most successful wiki has been within the KIS team, but other wiki spaces are developing well. Adoption remains a key topic and all manner of tactics can be used to encourage this. The wikis have complemented our existing systems and now we are looking to integrate them further within our enterprise search tool and intranet. We have seen increased productivity and more efficient use of time through the wikis.
