Making a difference

Julien Desmottes outlines lessons learnt from developing and reviewing intranet tools and applications at global firm Salans.

Adding value
Before thinking of how to add value, it is crucial to determine what the goals are for an intranet and its tools, plus what value is already there. In the context of a new application, how can we try to provide additional value to the user community? The real goal is in creating new and useful tools that people can use every day, as well as linking them together so that the intranet stays simple and easy to use. Similarly, the user interface should not have to be reinvented every time something is changed.

Most professional applications today are packed with features, which makes them very powerful, although it can also make them very hard to understand and challenging to learn. This might be fine for specialists in the field of the application, but for end users it makes for a long and slow learning process. Packing in many features only makes user interfaces more complex.

In many cases, the aim of an intranet is to make it faster and easier to get to information. Web viewers tend to have very little patience when it comes to drilling down through long lists of menus and sub-menus. The same is true of search results: viewers will only look at the first page or first few results and if they don’t find what they are looking for, they will go elsewhere and new tools will remain unnoticed.

For a long time, Salans’ intranet has focused on integrating a variety of tools into a simple, clean user interface. This means not overloading the page with items that people will not need regularly. There is no point in integrating an application into an intranet if it is simply replicating features that already exist in those applications, rather than giving them added value. Cluttered user interfaces tend to push users away and should be avoided at all costs.

Many intranets originally started as internal marketing tools, containing information about news and events, internal brochures, and so on. Over the years they have evolved into integration factors for knowledge, marketing, finance and IT in law firms, by making the information available to end users who don’t have to launch dedicated applications.

Take financial tools – for example, you can create easy access to matter information, billing details or even financial details for partners. This will help lawyers follow up on their clients as they are working with them, without having to launch a complex financial application. It also helps reduce the number of recurrent calls for information, with the extra work it means to the finance teams. Inaccessible and hard to understand, extra-long, extra-wide Excel spreadsheets can now be replaced with lively, colourful, always up-to-date data, where partners can get all information at a glance. One click from the main home page, and a partner can see statistics and details on his clients.

Last year was quite a busy one at Salans – we undertook an internal project called ‘eCollaboration’, which included a redesign of most of our IT systems. We implemented Microsoft Outlook as the firm’s standard e-mail system [replacing Novell Groupwise]. We implemented Autonomy/Interwoven Worksite and expanded our deployment of LexisNexis InterAction to all of our offices, introducing the concepts of document management and contact management for the first time in most places. As this meant starting from what looked a lot like a blank page, we had the opportunity to look at integrating the intranet with those applications right from the start. For example, we use some of Filesite’s empty screen real estate to display useful information to our users when they’re on their way to open documents. Each person’s page is personalised to show any information relevant to them ‘at a glance’ – for example, what they are working on, who is working on it with them, how the matter is progressing, and so on.

Assessing business needs
In order to correctly assess the business needs for a new application, it is particularly important to gather feedback on the existing tools. Gathering feedback is not the hardest task as you have an intranet at your disposal and feedback forms can be built fairly easily. However, as time is precious and lawyers may not have the time (or desire) to fill in a form, we strongly believe that talking directly to the business is equally important. You can also gather indirect feedback through support departments. For example, questions about financial tools will very often generate calls to finance departments, which makes them an important point of contact for feedback.

Constant re-evaluation of each component is essential, including statistics on visits and browsing habits, to see how each of the existing tools is being used over time. When creating new tools, you need to think of the existing ones and how they might be made obsolete by your new developments (or may benefit from them).

The following questions can help while defining your tool’s features:

What am I looking to add that the existing applications lack? and,
Who is my target audience, how will they use it and what else can I add that would be of help?

Knowing from the start who you’re targeting is crucial as it will ensure appropriate usage and adoption.

Communicating developments
Obviously, if you’ve assessed the business needs correctly, this process will be a lot easier. However, once they’re completed, you still need to make sure that the business understands what the tools are for. This is all about marketing tools to the business, which can be harder than it looks. It is important to generate buzz around new tools.

There are many ways to gather attention, including printed newsletters, special articles and short tips on the intranet itself. You can also do a lot with placing and prioritising links on the home page, temporarily or permanently. While you don’t want to end up with too cluttered an intranet, the placement of links on a home page is crucial.

In most cases, ensuring support from other departments is also key, as they can help you promote the new applications. This will often be the marketing or knowledge departments, but any kind of support, even indirect, will help.

A few years ago, we launched a new tool for partners to review their financial data. We decided to start with a beta form that was only available to our Paris office partners. We explained how to use it and asked for their feedback. After a few weeks we got quite a number of useful comments, some of which were then incorporated into the final version. However, what was most interesting was that we started getting calls from partners in other cities asking us about the tool and how to gain access to it – and that is the greatest feedback you can get: the partners themselves were generating the buzz. It has been one of our intranet’s greatest successes, and is now being checked daily, not only by a number of partners around the world, but also by the finance staff, who find it quicker when they need access to simple information (which came as quite a surprise as they own and understand the full-blown applications).

Setting timelines
When estimating delivery times, it is essential to take feedback into account and allocate some room for changes – it will always take longer than you think! I’m a keen proponent of setting deadlines that seem rather long, but then delivering the tools on time (sometimes even early). It makes people happier than if you’ve promised something and fall months behind – this will also help reduce pressure on the developer teams.

When setting out goals, keeping timelines and build descriptions open to changes is important, because additional ideas along the way will add to the requested feature list, and some of them may be very good and open you up to new ideas. Depending on how the build is progressing against its target date, you may want to include these ideas or decide to keep them for a later release. Whichever path you choose, make sure that you correctly assess any extra work required so as to avoid too many delays.

A full-blown software application needs clear milestones: at some point it needs a code freeze so that it can go to beta mode, and then eventually its release. With an intranet we believe that deadlines need to be much more open, as it is a constantly evolving tool. You need to strike the balance between getting it right and getting it out on time. If you want a set release date and you have to compromise too much on features to achieve that date, users will get to the new tool once, not like it and never go back. You’ll then spend months on a quest to revive interest. First impressions are important, so push deadlines where necessary to get it right.

You may still want to release beta versions of tools to select groups of users, as this will enable you to make improvements and get more ideas along the way before your tool is open to everyone. It is often easier for users to come up with ideas when they have something concrete to work with.

Integration
Integration is at the heart of an intranet. Having your intranet integrated with applications, as well as within itself, helps reduce the number of tools and links on your home page, therefore enhancing access to information at the same time.

Integration can reduce the time it takes to develop the tools themselves – although you may spend more time on integration, you will spend less time redesigning a whole new user interface.

When designing new applications for an intranet, you should think from the outset about what other information they can be linked to. In many cases, instead of building something completely new, you may find that the information you’re trying to bring can completely integrate with an existing tool – for example, clients can be linked to contacts, matters to your new business intake process, and so on.

Integration is key and in many cases it can also help you to maintain simplicity. A tool should only be brought in if it is going to make life easier for users or bring something completely new to the way the business operates.

Ongoing management
Before thinking of who will manage them, when building new tools you should try to make them as automated and as integrated as possible. Tools should need as little management as possible, as your intranet is there to help users, not to give them more work.

Automation can also ease your development process, since it saves on building all the interface elements that you need to put into a management system. Automation often requires very few interface elements, if any. It will make everybody happier as it means less time spent on management as well.

Sometimes, your tool will still need management. In many cases ownership should be fairly clear and management should be handled by the team which is responsible for the content. Obviously, IT should be able to help with the more technical tasks (and either keep them or hand them to the team over time), but IT should not become responsible for the contents. At Salans we are lucky to have dedicated teams that are very interested and therefore naturally take on most of the tools’ management.

User training
User training can get very expensive, particularly when you consider training users in multiple offices. As a general rule, most tools should be simple and intuitive enough not to require training.

When building the online help program for a tool, try to give short on-the-spot explanations so that people can click on a question mark right on the page, as opposed to referring to a long, hard-to-read user guide. Large manuals are too often left gathering dust on a desk before eventually being thrown away.

With a small intranet team it is hard to travel and train people in every office, and in the current economic environment you may find it is simply not possible. For advanced tools where more formal training is required, we are increasingly using champions – we fully train one or two carefully selected people in each office or team, so that they can spread the knowledge around them. Champions are particularly efficient because they are local, therefore they speak the same language and have the same culture as the people they are sitting next to, which makes them much closer to the end users.

This is an approach we used when replacing our desktop environment. Instead of taking up lawyers’ time and training them on the new systems (which would have taken days, even weeks when you count large offices), we opted for a two-hour presentation for all users, which is fairly brief but gave them clues so they could start working the day after migration. At the same time, we fully trained a number of champions or ‘floor-walkers’ (the number varied depending on the size of the office) and gave them complete two to three-day training the week leading up to the rollout.

After the weekend rollout of the new desktop, these champions helped users on the floors directly. The major advantage was that when our global teams left after the migration, champions were still there to help users grasp the new concepts.

An additional benefit is that if you keep the champions up-to-date and close to your development and upgrade processes, they can provide a lot of local feedback on your tools. Sometimes there are nuances in a country that you may not think of – information that is very useful for an English lawyer may be partly irrelevant to a Chinese lawyer, who may need something just a bit different. A remote user is not as likely to think of calling you, but he or she will more naturally talk to someone locally, who can then pass on the information to you.

In summary
The key to ensuring effective utilisation of intranet tools and applications is thinking about how they can make a difference. There is no point in forcing users on to an intranet – if there is no added value they will not naturally come back to it. Lack of interest is generally the result of a lack of interesting content. If the business understands the value of the tools, the users will be quick to embrace them naturally.

Julien Desmottes is head of software at Salans. He can be contacted at jdesmottes@salans.com.