The genesis of iFreshfields

Continuing her ‘Challenging preconceptions’ series, Cora Newell and Mark Walmsley discuss the development of the wiki-inspired intranet at Freshfields Bruckhaus Deringer

The concept of successful knowledge management (KM) has changed radically over the past 15 years along with the need for efficiency and improved profitability. Social networking and Web 2.0 tools enable like-minded people to collaborate remotely around the globe, which contributes to enhanced business performance and efficiency. As professional services firms rely heavily on the intellectual capabilities of their employees, improvements by such firms in the provision and accessibility of rich knowledge to their workers are critical to the delivery of effective business strategies and cost savings.

Technological advances have helped us to understand that effective KM relies on efficient communication and collaboration. Most professional services firms have three communication channels: e-mail, intranet and face-to-face. Although each provides a social networking capability, only the intranet can support all levels of KM.

Changing e-mail usage behaviour has proven to be too difficult – we are all guilty of taking refuge in the anonymity of working with colleagues from behind a closed door. Face-to-face meetings are often productive but can be difficult to arrange and discussions are rarely documented or subsequently shared. Intranets, however, offer flexibility and openness. Most importantly, they support collaboration.

Professional service firms can no longer rely on the storage of useful documents in hard copy, which cannot be searched and are seldom updated. The evolution of electronic document storage around ten years ago means that content is now more easily accessible and searchable. The most exciting advances have occurred in the past five years largely due to the work of ‘bedroom developers’, who have built tools that push the boundaries of how we communicate both socially and professionally.

Google can now claim to have two million developers, although very few of them are actually on the company payroll.

The age of bedroom development is flourishing and there is a wealth of young, talented developers who build applications from the comfort of their own homes – not for money, but for pure enjoyment and the respect gained from fellow techies.

Bedroom developers are partially responsible for the development of some KM systems, particularly social networking sites, such as FaceBook and MySpace, which enable information to be shared globally with friends both quickly and informally. The original concept behind these platforms of social connectivity has evolved and been improved by software houses, which now provide scalable, business-focused tools that are becoming invaluable within a commercial environment.

The uptake of social communication tools by businesses has been met with some scepticism, as is often the case with newer technological solutions. Commercial organisations are inherently wary of reputational damage, lack of content control, using unbranded products and moving away from traditional software providers. That said, the desire for efficiency has opened the door to diverse and often low-cost technological solutions – such as Wikis, which enable a large audience with little or no training to easily create and update content using simple interfaces.

What led to the development of iFreshfields?
Like many other firms, Freshfields conducted a KM systems and processes review in 2008, covering internal content management, newsletters and support.

The review identified some fundamental issues with the structure and accessibility of the firm’s intranet content:

Regionalised and siloed content – content was separated by region, making it difficult for employees across the network to access the same relevant material. This separation led to duplication;
Limited editors – intranet software was complicated and expensive, which meant only limited employees had editing rights. Editors were asked to carry out their duties in addition to their normal day job, which meant content became out of date quicker;
Lack of governance – caused content to become out of date quickly, which affected the intranet’s internal reputation for accuracy;
Limited accessibility – a static homepage made it difficult for users to access their relevant material quickly, affecting adoption and resulting in increased use of e-mail;
Poor structure – poor content structure forced users to navigate through a series of links before finding relevant material; and
Existing technology did not support collaboration.

Generally, recommendations following such reviews tend to fall into two categories – improve what you already have, or implement new technology. Most firms choose the former because it is cheaper and easier. This path often involves improving e-mail efficiency and cleaning up intranet content. Implementing new technology is usually rejected on cost grounds as it can be expensive in the short term, but it may be the only way to ensure medium to long-term KM efficiency, and ultimately competitive advantage.

In mid-2008 it was agreed that Freshfields would replace its intranet with a wiki-based tool for effective content management, which would be surfaced on an in-house developed, iGoogle-inspired home page, giving users total control of the content they see. iFreshfields was born.

Objectives and benefits
From the start, the focus was on efficient creation, dissemination and access to rich content through a flexible wiki-based intranet. Some of the project goals and outcomes are displayed in Table 1.

The technology
Dynamic content, collaboration and efficient work flows are the most important aspects in the success of an intranet system. Wikis are currently a popular choice for businesses as they offer a good level of flexibility at a low cost and do not require advanced IT development knowledge from the user.

The market is awash with various wiki technologies, but fundamentally most do the same job. While there is no hard and fast rule for technology selection, it is useful to consider the following before implementing a wiki:

Scalability – whether or not the wiki will be able to cope with all your user’s requirements simultaneously;
Compatibility – ensure the database and server requirements are supported by your IT department. They won’t thank you for making them support new hardware and this can add to delays, increased security threats financial risk, and issues with delivery;
Functionality – aim for an off-the-shelf solution where possible. Building bespoke features following implementation causes issues when upgrading the software. Ninety-eight per cent of the original functions will work when there is an upgrade. The same is not true of bespoke development;
Control – define and prioritise what level of control you want (in terms of page structure, editing and governance) and select your solution accordingly. All wiki applications offer different levels of flexibility in each area; and
Design – Consider how technologically advanced your users are before making your choice. Complex, cluttered interfaces work for IT developers, while simple platforms work for great-grandparents. Think of lawyers as somewhere between the two.

Planning and delivery fundamentals
Never underestimate the complexity of replacing an enterprise system. Most users are reluctant to change their tools even if they don’t work properly. Even fewer users are keen to be re-educated as they simply don’t have the time.

It is imperative that developers aren’t fooled into ‘seeing how it goes’. Delivery always starts with planning so a project methodology must be chosen at an early stage. Most professionals recognise Prince 2 as the leading standard but in private practice, Prince is often considered impractical because of the excessive controls and checks. Freshfields has its own version of Prince, which is shared by both IT and the firm’s knowledge business development (KBD) group, which provides for all the major planning, risks/issues management and reporting without distracting from fast and effective delivery.

There are always two ways to deliver a project – low-key (or covert) and ‘big bang’. The low-key approach provides a safety net for the business to test reactions before committing valuable budget and resource. However, most projects that start out as low-key tend to fail as a result of poor adoption. Commitment to change and improvement needs to be communicated well throughout the project..

Freshfields took the low-key approach, initiating a series of very small pilots across the firm. However, the wiki rapidly became a victim of its own success; most noticeably because users started creating whole wiki sites with no training and, in one case, without the project team being aware. This could have become quite a problem, but the team was quick to recognise the issue and put controls in place to reduce further individualised wiki creations and enable more detailed planning.

Low-key pilots, although smaller and therefore supposedly easier to manage, can still get out of control and force the project team to become more reactive than proactive.

This directly affects adoption and efficiency of delivery – showing confidence in your goals and commitment to delivery will always mean improved buy-in and reaction from the users.

In much the same way project management has strong methodology, so does software development. Freshfields chose the Waterfall1 model, a process by which the basic platform is installed and tested first before new functionality is ‘unlocked’ or developed. This enabled the project team to qualify user requirements once the system was live and avoid any mal-development or unnecessary use of resource. It is much harder for users to communicate required functionality in the absence of a visible platform.

Installing the wiki platform is essentially straightforward, but issues around functionality, servers and design can be problematic. Bearing the following principles in mind can help minimise teething troubles.

Functionality
Offering excessive, ‘advanced’ functionality can create a training and support headache. It’s better to offer basic features and let users become accustomed to them before considering which advanced features are really necessary.

Servers
Spend time predicting the expected level of usage. A product might seem robust but running background processes like statistics or error logging will affect performance. Freshfields had unexpectedly high user uptake early on and we found the servers were not configured to handle the uptake efficiently, which caused performance and reliability issues. Reconfiguring the servers so they were load balanced2 (each server sharing users) reduced load and meant that if one server failed, the other could handle the load on its own until the issue was resolved.

Page design
Keep it simple. Adoption is higher when the technology platform is easy to use. Technically simple designs are also easier to develop, which reduces the chance of coding problems and the amount of support calls.

Page designs are formulated in style sheets or themes that contain code for how the page looks and feel. iFreshfields’ initial design was aesthetically good, but as usage increased we realised the original design prevented easy functionality with some of the advanced features. Recreating style sheets takes time and additional software and as a result we invested in best-practice sessions to ensure the core wiki editors understood the nature of the issue and were given the skills to work around it.

Stakeholder engagement and change management
The key to success is engagement and change management. A firmwide release will always be difficult and there are normally four groups of users to contend with:

‘Give it’ – new joiners or the younger generation of staff in a firm, who are likely to have grown up with similar technology and understand the need to evolve. These are the evangelists;
‘Not fussed’– these users don’t have an opinion and are happy with or without the change, just as long as they understand why and are provided with guidance. These are potential evangelists and early engagement is essential;
‘Not again’ – longer-serving employees, who have seen waves of changes over the years and are frustrated with constant adaptations. Traditionally, they are not vocal but remain key to how others perceive the change. They are often opinion leaders and as such they should be included in any decision making or design process; and
‘No way José’ – often the most vocal and derisive group, who are typically against change and new IT solutions. However, this is the most important group because winning them over is the greatest challenge and provides the biggest benefit. If your greatest sceptics become fans, the likelihood of success increases dramatically.

Firm-wide rollout
Following a very successful pilot, iFreshfields was launched to the wider firm in a joint e-mail from the IT and KBD partners. It contained an explanation of the change, a user demonstration and contact names from the project team in London. The communication was written in English and was sent to all Freshfields’ global employees.

Probably due to the fact we all receive too much e-mail and prioritise accordingly, initial analysis showed that only 60 per cent of users read the iFreshfields launch e-mail. A contributing factor may have been that the senders weren’t well known outside of London and recipients were prioritising local e-mail traffic from known senders. After the Asia rollout, local senior partners were asked to send out a teaser e-mail in their local language before the IT and KBD partners sent out theirs in English. This led to an improved response and future projects will adopt a similar approach.

Of course, communication didn’t stop there. The project team was committed to regularly updating its stakeholders. Table 2 is a basic example of a typical communication process which is followed for a project such as this.

Training
Every business has a range of users with different abilities. No matter how simple a product might be to use, it is naive to think that training will not be required. Some amount of direction is always needed, although this may not mean classroom-based training, which can be costly. The trick is to align training with the different levels of knowledge or user-comfort. One of the critical factors to the success of iFreshfields was the variety of training offered, which included:

Classroom based. Two formal training sessions were created – one for basic functions and the other for advanced. These were not compulsory but were made available for those who wanted them;
Online guide. A comprehensive resource detailing the wiki’s functionality with clear examples, including the code which could be copied and pasted. Each function was supported, where possible, with a short video showing its practical application;
Best-practice sessions. Classroom and online sessions demonstrated how to write for the web and structure content, including accessiblity to those with disabilities; and
Dedicated training personnel. A dedicated team offered more sophisticated technical support than the firm’s IT helpdesk, which could make small changes and explain how to use functionality over the phone.

Governance
The way in which an intranet is managed post-release must be factored in at any early stage. Intranets suffer most from out-of-date content and poor structure. Good governance can prevent this from becoming a problem.

From the start, the project team maintained control over all new wiki spaces by ensuring new sites were officially requested via an online form to ensure they met certain criteria. All new wikis were created by the project team and requests were reviewed rigorously. Users were asked to provide a sponsor name, predicted size and number of users, the type of content and whether the wiki would contain any sensitive material – in which case records are kept according to the principle of Chinese Walls. On completion, the form was automatically e-mailed to the project team and was reviewed, giving the team the ability to deny applications when content could easily sit on an existing wiki or where there was potential for collaboration.

The issue of content governance itself is more difficult. Ensuring material remains relevant takes considerable resource. The firm has recently invested in a bespoke statistics tool, which runs quarterly content reports identifying content that has not been updated or reviewed in the past six months. The project team reviews these reports and the wiki owners are contacted if appropriate. Eventually, the statistics tool should report directly to the content owner so that the project team need only be involved in cases of prolonged delay in response.

The future
With more than one-million hits a day, iFreshfields has been a success – notwithstanding its teething problems. Some of these were directly attributable to surprisingly high user uptake early on, and the ever-present sceptics found in any professional services environment. Very few firms have created a wiki-based intranet with a front end like iGoogle, enabling users to personalise their view by adding, moving and deleting wikis. Going forward, the firm is hopeful for steadily increasing adoption of its new intranet and intends to concentrate on ensuring that iFreshfields remains a viable source of up-to-date, relevant and accessible information.

Cora Newell is a change management and communication expert and director of KM Insight Consulting, which helps businesses to drive performance and quality improvement. She can be contacted at newell@kminsightconsulting.com

Mark Walmsley is project manager in the change management group at Freshfields Bruckhaus Deringer LLP. He can be contacted at mark.walmsley@freshfields.com

References

http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Load_balancing_(computing)

Note: to see a PDF of the article including Figure 1 and Tables, please e-mail the editor at kclifton@waterlow.com