With a little help from my friends

Knowledge management activities in UK law firms depend very heavily on people power — being more reliant on Professional Support Lawyers (PSLs) than their US and continental European counterparts. Despite this, the recent Knowledge Management in Law Firms conference had a noticeable technology focus. I’m afraid I set the tone in the first session with a couple of case studies on KM/IT implementations, but in my defence I did concentrate on the people issues rather than the technology. After that we had many screenshots of systems, mashups, search tools, RSS blogs, wikis and more. All the time we kept telling ourselves that KM wasn’t all about technology, but I wonder whether the historically divergent US and UK law firm traditions are moving closer together. We are using more technology and they are using more PSLs (or KM lawyers).

And then the final question silenced us all. One of the two search engine suppliers at the conference mentioned that they were accustomed to hosting conferences with the IT directors of their main customers — to find out what keeps them up at night and to gather information to drive development of their products. Coming at the end of a panel discussion focusing on how we meet client needs for KM support, I think many of us expected this statement to be followed by a suggestion that law firms might do something along similar lines for their top clients. But no — instead the question was whether the suppliers of the IT tools that we had all been discussing for the previous two days should be speaking to us instead of our IT directors. And, more pointedly, how did we feel about our project spend being controlled by someone who did not necessarily know (or at least understand) the strategic objectives underpinning our KM projects?

The supplementary question was probably a bit provocative. I hope most IT directors do understand and buy into their firm’s KM strategies. However, there is a bit of truth in the assumption behind it. KM projects have to fight for IT time and resources along with everything else that the firm needs — from recurrent and inevitable hardware replacement to big infrastructural projects or change driven by other parts of the firm. How do we feel about that?

Actually, is that the right question? Like the lawyer-client relationship, the IT/KM relationship is just that — a relationship. In order to prevent it becoming disfunctional (or to rectify it if a breakdown has already happened), I think it is helpful to remember two key points. Neither of them refer directly to how we feel. The two points are these:

1. If something is wrong in a relationship, you cannot change it by focusing on someone else’s behaviour. The only behaviour you can guarantee to change is your own.
2. The changes you make will have most impact if you understand what preoccupies the other person and play to it.

Let’s elaborate these two points, using the IT-KM relationship as an example.

It’s not you, it’s me…

One of the things that we often forget to take account of in our relationships is that what is important to us in not necessarily a priority for the other person. Just as our jobs give us a full workload, and many challenges, those whose services we need to call on are equally burdened. If we are lucky, they may respond well to a simple plea for attention, but this is most likely when our needs are already important to them. If a simple plea does not work, it will not be any more successful if it is just repeated more loudly. The toddler having a tantrum on the supermarket because they have been refused the sweets they demanded has yet to learn this lesson.

If we change our approach, we may be more successful in getting attention and changed behaviour on the other side of the relationship. If our needs are not a priority for someone else, we might be able to get what we want by framing our request so that it appeals to them more. A demand for more IT resource for KM is likely to fall on deaf ears, but a suggestion that IT and KM (perhaps together with BD) might develop products for knowledge sharing with clients (for example) is likely to command more interest. That would allow IT to demonstrate alignment to the firm’s strategic objectives. This is a similar (although more finessed) approach to that adopted by the teenager who argues that use of the family car would give them a safer return from a late party than waiting for a night bus.

It is rare in a relationship that any difficulties are due solely to the behaviour of one party. There is usually a balance of responsibilities. If we accept that, and consciously change our own behaviour, we can swing the balance in our favour.

What do you want?

Bearing all this in mind, what should KM people know about their IT colleagues? What are the pressure points for technology in law firms? It is difficult to generalise — firms and culture differ — but here are some suggestions. Think scalability, robustness and support.

Scalability: What are the implications of your proposed KM solution for more than a handful of users? OK, you can knock up a quick blog or wiki installation on your home PC, but how does that compare to a platform to support the needs of a thousand or more users? Does your ‘free’ software actually come with significant costs when scaled up beyond more than handful of users?

Robustness: Law firms are not unique in needing high levels of IT security, but that does not mean that the demands of a resilient technology platform should be minimised. It takes time and effort to keep a system running 24/7. At the moment, you may be comfortable that your new system does not need that kind of resilience, but you probably want it to integrate with existing security systems so that users do not have to log in afresh. Likewise, IT will need to be comfortable that no harm is done to the existing critical systems.

Support: Are the technologies that your favoured solution depends on known or unknown within your IT team? It is easy to underestimate the challenges involved in supporting new things. Once your new system takes hold, your less technically-savvy colleagues will expect the same levels of personal support that they currently get for the firm’s established systems. Behind the scenes, your apparently simple blogging platform (for example) is probably actually quite complex. Without an established body of knowledge in the IT team, supporting that platform is expensive — either in training or external consultancy. Whose budget is that coming from?

Bearing those concerns in mind, it becomes easier to understand the IT professionals’ exasperation at comments like those of silicon.com’s resident devil’s advocate, the Naked CIO, when s/he refers to IT’s weasel words. This comment is particularly telling:

But the part of this article that us foot troops are most likely to disagree with is the idea that we are scared to tell the real story. Not scared, but fed up. Fed up with being told that we are making it deliberately complicated. Fed up with our words being distorted by those that don’t understand our jobs. Fed up with our senior managers not having the courage to fight our corner after those distortions.
It takes two to tango. If colleagues in other functions were prepared to treat IT with respect, long suffering troops wouldn’t be driven to evasive tactics. We obfuscate because non-IT colleagues are getting worse in their assumptions about what is and isn’t a simple problem in IT. “I’ve knocked something up in Access, how hard could it be to make it work for 1000 concurrent users in a distributed environment with no performance issues?” People don’t challenge how hard it is to construct a major building or manufacture a car. That’s because those things are tangible. They can see that it’s difficult. IT is almost invisible, so otherwise sensible people somehow equate invisible to simple “because I can imagine how to do it in my head”.
Until we find a way to address the almost wilful lack of trust and understanding of IT in non-IT colleagues, this situation will worsen.

So the ball is back in our court. Trust and understand your IT colleagues — cooperation and effective collaboration will follow.

(Having said all that, I still have no idea why Neil Richards’s experience of IT projects in a bank was so different from his previous life in a law firm.)