Case study: Freshfields Bruckhaus Deringer

If we build it - will they come?

Transforming the Freshfields Bruckhaus Deringer intranet into an essential business tool. By Stephen Perry

The task
Updating Freshfields’ intranet from its old Microsoft FrontPage environment into our new Confluence wiki-based system has been an enormous task, involving a major change in approach. We are now 12 months down the line (April 2009) and 90 per cent of content covering the practice groups, sector groups and clients has been created and some pre-existing content safely migrated. More importantly, the new format has proved a hit with our users – as demonstrated by the fact that our updates have increased dramatically and we now have over 5,000 wiki intranet editors compared with just over 500 under the old system.
As anyone who has worked in a law firm (or professional services organisation) will know, knowledge management (KM) is built on foundations of talent and time – the former there in bucket-loads and the latter a rare commodity. Freshfields’ old intranet system was an illustration in point: we had a mountain of information, but too much of it was out of date, ownership was often difficult to trace, and the system itself was not used nearly as much as it should have been because it was not perceived as being user friendly, or adding business value.
When I joined the firm in September 2007 the intranet was high up on the list for an upgrade. Consultants Headshift, had helped kick-start our thinking with a strategic review in 2007 looking at our current awareness approach and intranet. Their findings backed up what was being reported anecdotally:

Our intranet content was either out-of-date or difficult to find;
It was complex to update information;
Usage was low, with some isolated success stories;
Poor search tools and content structure hindered finding information; and,
There was an inconsistent user experience in terms of the interface and the lack of capability.

None of this should be too surprising, given the size of the firm and the volume of information available.

The solution
But how to fix it? You might imagine a big problem needs a big solution but, in fact, we decided to take a more lightweight, flexible and innovative approach. We proposed the Confluence wiki, a web 2.0 solution, citing it as a low-cost, market-leading option for replacing the existing intranet, while at the same time improving information sharing and encouraging greater collaboration. The original plan was to incorporate three tools – blog, feeds management and wikis but we made an early decision to simplify this approach and instead to focus on initially replacing the existing intranet and subwebs with the Confluence wiki.
It was an ideal solution – a low-cost, decentralised, flexible tool that would have a real resonance with people used to wiki-type tools. It would address the two trickiest parts of the KM equation – people and process – in what seemed to be a refreshingly low-key and flexible manner. And what is the intranet after all, if not a series of community spaces – an environment ideally suited to the collaborative approach of the wiki.
Flexibility was key. We have eight global practice groups – each a different business with its own priorities, needs, preferences and processes. The advantage of the Confluence solution is our ability to adjust with the firm’s changing business needs. Following the creation of the top level spaces covering practice groups, sector groups, clients and business services; space owners were able to create new areas enabling a quick response to their business drivers.
If we had chosen the ‘big solution’ – one that dictated that everyone needed to do the same thing in the same way and that relied on changes being done by a few designated editors – we would have been consigning ourselves to the same straitjacket of conformity that was proving problematic with the existing intranet.

The process
We aimed for a low key pilot and rollout that embraced some key early adopters, rather than a ‘big bang’ approach. Similarly, the project was a collaborative effort between the knowledge and business development (KBD) programme management team, the KBD systems team (the wiki business owner) and our IT department, giving a diverse pool of resource.
The working group was also multi-disciplinary, consisting of the project manager, developers, usability and information architecture experts, who met with representatives from different practice groups, offices and central support functions to clarify their information structure needs for the new intranet. The project manager was then able to create an action plan based on the actual rather than perceived needs of the various stakeholder groups.
A decision was made from the outset not to oversell the benefits and to focus on users becoming comfortable with the new technology before exploring its capability. We worked with all the interested parties, including fee-earners, KBD staff and PAs using existing channels of communication and relationships.
Key editors were also given a series of best practice presentations showcasing key wiki features and top tips for creating web-based content so that it was more accessible.
Training is always an issue with any new tool since it is time consuming and repetitive and there is almost always a lack of resource, incoherent approach, lack of take up and so on. So we went for the revolutionary approach – at least for a law firm – and created a five-minute ‘viewlet’ for time-stretched fee-earners, enabling them to understand, through a series of visuals, the key functions and how to use it day to day. In line with the softly-softly approach, none of this was compulsory; instead we concentrated on targeting key figures recognised as influencers within the firm and relied a lot on the power of word-of-mouth.
The approach was one of engagement, encouragement and collaboration – with some coercion!

The pilot
We carried out some initial iterations and tested it with some users. By doing so, we were able to identify groups that were enthusiastic about the project. For example, our IP/IT practice group were identified as strong supporters of the pilot – they were very keen to replace and upgrade their old intranet site. There can be a danger in becoming too swayed by the converts (since not everyone will have the same level of enthusiasm) but we found that by starting with the groups that were already expressing an interest, we were able to create a bit of a buzz around the project. Indeed, it wasn’t too long before that had developed into an atmosphere of friendly competition, with those who had not yet converted their intranets to wikis wanting to sign up to the new system so as not to be left behind.
The size of the old intranet dictated a long and thorough pilot – we developed over 60 wikis across the network and they quickly began to be viewed as business critical. That also gave us the desired snowball effect, so that by the time we presented our case to our global operations executive committee in spring 2008, there was already a sizable groundswell of opinion in favour of full rollout.
Members of the committee had already heard from their own practice or sector groups how good the system was – many of them had tried it for themselves – so they weren’t being presented with a costly and theoretical proposition, but something that had resonance and some degree of familiarity. Since we had effectively already created a genuine business demand for the system (by this stage we didn’t have enough resource to cope with the requests for new wiki spaces) they could give approval for the rollout in the knowledge that this was something that was already working well.
The project success lay in not imposing a pre-decided detailed structure on users but working with them to evolve something that would meet their particular needs. Consistency – often the stumbling block with solutions imposed from on high – could be flexible to the business requirements of each community for each set of stakeholders. The flexibility of the wiki-based system enabled the project team to present stakeholders with an easy-to-use tool, support them while they assessed the material on their old intranet site – deciding what was worth moving over to the new system and what should go – and then choose how ‘open’ they wanted their wiki to be. This has varied between practice groups, allowing a large degree of access for users to go in and comment/contribute as they wish. Others have taken a more conservative approach, limiting the number of editors they will allow on sections of their site.
The wiki clearly appeals to a generation of users familiar with communities and collaboration on the web and not everyone, in particular at a more senior level, is likely to publish and collaborate on the wiki. But our CEO and a number of partners across the network are already strong supporters of the wiki and we are encouraged by the fact that all partners agree that the intranet upgrade is important to the firm – that if we want to tap into the wealth of knowledge available within the firm, in a collaborative way, then that means that static intranet solutions no longer work and we have to supply users with similar types of tools to the ones that they use at home.

The outcome
We chose Confluence because it met the criteria we had set ourselves for the intranet upgrade. We needed a tool that would ensure active participation and updating and ownership of content within each of the practice/sector groups etc, while also enabling a collaborative approach to our client service. The wiki system met those needs. In addition, Confluence:

Supports a structured intranet plus collaboration spaces;
Is easy to use and therefore presents a lower barrier to participation;
Is a cost-effective, lightweight and flexible solution; and,
Has low maintenance and support costs.

The wiki is now the preferred delivery platform for many of our KBD applications and works well with the myriad needs of an international network and its associate complexities of culture, time zones and language variations. So, for example, we have a number of very successful German language wikis and the new system has proved popular with our Asia offices, which have a large amount of active content.
The Confluence functionalities that we particularly liked were:

Labelling

It has user-driven folksonomies;
It shares content between wikis;
It increases findability through navigation by label and search;

Ease of integration including external content (RSS)

It has standards-based API;
It successfully integrates with internal and external systems;
Users can add any RSS feed to their wiki;
Every wiki can produce its own RSS feed for user subscription;

Blogs/News

Every wiki has a related blog;
Blog items are shared using the labelling architecture;
E-mail subscription through the use of bespoke plug-in;

We had positive user feedback with regards to the search functionality;
As part of the web service API and can be used in other applications;

Themes/Templates

Themes can easily be changed to meet the business need; and,
Templates can be created to make content creation easier – for example; client templates.

What we would have done differently?
It hasn’t all been plain sailing. Some of the early versions of Confluence had software bugs and the Confluence back-up conflicted with our own enterprise back-up, but by working with Adaptavist (a Confluence technical consultancy) we managed to solve those issues. Additionally, some of the Confluence features are not Disability Discrimination Act 1995-compliant and so needed to be changed to meet the requirements. There were also some issues around complex functionality that needed ironing out in the initial design stages. But, on the whole, the project has gone smoothly. It has been a great team effort led by the KBD programme management team and we are now on the home straight.
What would we do differently? We would probably get some of the building blocks of the project nailed down at an earlier stage in the process. For example, agreeing the information architecture earlier, deciding on the final technical architecture earlier, plan in more detail (and earlier) the content migration and agree earlier how we would measure and monitor usage. Keeping your focus is also difficult when you are dealing with such a large project so, looking back, we would have limited the number of suppliers and parties involved and managed the scope of the project in a slightly more structured manner.
Having said that, I think our iterative development approach enabled us to progress quickly with the business, which we wouldn’t have been able to do following a more traditional method.
And it has generally been a very positive experience – proven by the fact that we now have an intranet that users feel as if they own, and that is theirs to keep fresh and updated. So much so, that we were the victims of our own success in terms of the huge demand for new content areas and uses of the functionality. Our scope nearly doubled during the course of the year as a result of enthusiastic requests from senior figures across the business, but we are still on target to deliver it on schedule – and on a very small budget.
Our ultimate goal is that our fee earners feel they can go quickly and easily into an area and contribute some insight or intelligence on a client, sector or cross-cutting issue and the wiki provides an excellent platform to do this.

Steve Perry is head of knowledge and business development systems at Freshfields Bruckhaus Deringer LLP. He can be contacted at stephen.perry@freshfields.com.