Why you must identify your firm’s problems before fishing for tech solutions

[Australasian Law Management Journal] April 28, 2019

The plethora of technology solutions available to support lawyers is impressive, but actually finding the problems you are trying to solve should never be overlooked when choices are being made, writes Mark Andrews.

I am reminded of an experience I had many years ago working with an organisation where the view from senior managers was that they had “done knowledge management” but that it did not work.

What had, in fact, happened was that the organisation had spent a considerable sum of money on a technology system which the vendor claimed could solve the challenge of knowledge management. Unsurprisingly, it didn’t solve anything as there was a lack of clarity on what problems the organisation was really trying to address. What struck me most at the time, and still surprises me, is how much money was actually spent on the technology system to solve the undefined problem.

With that story in mind, my focus in this article is on identifying problems and capabilities within firms before you worry about identifying applications or systems to tackle issues. This does not mean you should stop exploring new technologies and understanding what these technologies can bring to your organisation, but it does mean resisting the temptation to invest large sums in technology and then spend considerable time and effort trying to find somewhere to apply the technology.

Start by talking

As an IT professional, a lot of time can be consumed with operational and project requirements. Days can go by when the only people we speak to are those in IT or in other supporting areas of the business such as marketing, business development, finance or HR. Of course, this is important, but not at the expense of conversations with the timekeepers. In my own firm, I am driving a Technology Health Check program which includes a formal business engagement and feedback component that utilises individual and group interviews. The feedback obtained is wide ranging and highlights some problem areas and pain points.

Our firm has made it a priority to invest in technology that supports ‘legal project management’ training and best-practice frameworks. For example, we have recognised that complex multi-jurisdiction matters require effective coordination and management. They need to be treated as projects and, by doing so, we can provide better value to clients and a higher-quality service. The first step was to put in place a group of legal project managers. The next was to leverage existing technology and, as the discipline has matured, we are now investing in more bespoke technology. We tend to find that where there is demand in multiple locations, and where the demand has been persistent, then the uptake of technology is stronger. Success comes when sponsorship is broader.

A Technology Health Check is just one way to start talking. Other ways include:

  • focus groups – taking a particular issue or theme to a group and obtaining feedback through a deep dive on the issue or theme;
  • consultation groups – providing an open forum where you can take issues and questions and obtain feedback without there being a steering committee-type expectation;
  • structured and unstructured interviews;
  • drop-in training or support – not dissimilar to how Apple approaches support with the Genius Bar, a tech support station located inside its retail stores;
  • follow-ups from incident resolution; and
  • discussion of root cause analysis following more significant issues.

There are, of course, many other ways; my point is simply that as IT people we need to talk more with our entire user community.

As a lawyer it is also important to reframe conversations with IT people. The risk is that IT people are pigeonholed as either the people who fix problems or the people that you have to deal with to be able to buy that piece of technology or software that you know is perfect for your needs. This often produces a dialogue centred around fixing things and buying things rather than around solving business problems. Of course, IT remains the go-to team to fix technical problems, but it is incumbent on lawyers to have business-focused conversations with IT; conversations that start by talking about the work being undertaken, current challenges, client expectations, deficiencies with the current process and systems, the urgency of problems and a desire to work differently.

If you find that your conversations typically involve you saying “please buy me software X” and IT saying “we cannot because of Y”  it’s time to have a different conversation. Just as medical practitioners want to hear about our symptoms rather than what medication we want them to give us, IT people want to hear about business problems and not the system we should buy.

Through conversation you will see patterns and trends emerging – perhaps a common pain point, a shared desire to try doing something differently, and acceptance that a solution is coming and there isn’t a current urgency to make a change or any range of other themes.

Make a map

Think of your firm or in-house department not as an organisational chart but as a collection of capabilities – of combinations of people, processes and technology that provide the ability to achieve an outcome. Think in granular terms rather than in generalisations. Follow the life of a transaction or matter and use this to identify the various capabilities being used.

To bring this idea to life, let’s consider a simple example of recruiting people. At the highest level there is a capability around ‘recruitment and hiring’. This can be broken down into a number of distinct capabilities such as ‘planning’, ‘recruitment management’ and ‘on-boarding’. Drilling into ‘recruitment management’ takes us to ‘searching’ or ‘sourcing’ and ‘recruiting’. ‘Recruiting’ splits into ‘evaluation’, ‘screening’ and ‘Interviewing’, to name just a few.

There are a number of ways to depict this graphically, including those from formal disciplines such as Enterprise Architecture (EA), but my purpose is to illustrate the concept rather than prescribe a documentation method. What I would suggest is the use of colour coding on a capability map to indicate the maturity of the capability. In this example, if our screening process is purely paper based and we just ask the hiring manager to do their own screening with no guidelines, systems or support, then maturity is low and we may decide to depict this capability in red.

The idea is to build a more structured view of your firm or department that can be used to better determine where to focus improvement efforts, new systems etc. The capability map can also indicate where not to invest. When the capability map is paired with the themes and issues emerging from ongoing conversations, a very rich picture emerges.

EA is one discipline that can help enormously with capability mapping. There are a number of frameworks for EA, with TOGAF (it stands for The Open Group Architecture Framework) being a popular framework that provides an approach for designing, planning, implementing and governing an enterprise information technology architecture.

I would encourage readers with some interest in this area to explore TOGAF further as it is a commonly used framework.

Continue the technology exploration

It would be wrong to conclude that I am suggesting that an internal focus on talking and mapping is all that is needed. From a technology standpoint it is essential to know what the current crop of technologies can deliver, what future developments are planned and how this might impact your firm or department.

In this exploration it is important to be nimble and ready to change course as required. There will, of course, be some big bet systems that you know you need to replace – perhaps systems that support conflict checking and clearance, financial systems, HR systems and document management systems. These are going to be major projects that do require a commitment to a particular platform.

Aside from major projects, there is a lot to be gained from having a tech fund that lets you explore and experiment. I see this as being a bit like fishing – you throw several lines out and see if you get any bites. If there are no bites, perhaps you try a different area in which to fish or a different bait.

The advantage you have with starting by talking and making a map is that you will have a pretty good idea of where to fish. You cannot make the fish bite, but you can maximise the chances of a bite.

Enough of the fishing analogy; the point is that by continuing to explore you may well discover new problems and issues, you may discover gaps in capability or may spark new conversations. Your goal is not to turn into a product sales person, it is to unearth problems and prompt conversation.

While some of what I have outlined may seem to relate to larger firms and departments, there is nevertheless value in small-scale initiatives to address specific issues such as tracking a physical file through the firm, providing a simple tool to track client interaction, or providing a basic expertise directory of who is who in the firm.

Focus on demand pull, not supply push

As I hope is clear from this article, the idea is to identify and create demand rather than to push solutions out in search of a problem. If you do not have a clear understanding of problems and capabilities across your firm or department, you are likely to repeat some form of the experience I shared at the beginning of the article.

Knowing the problems and capabilities is an excellent foundation, but there is one other ingredient to demand pull – and that is the people in your firm or department. Serious problems and immature capability may not be enough to create demand if people are too stuck and not prepared to change.

This is where a combination of client and internal change agent is powerful. In talking to clients, we can frequently identify pain points and these do tend to translate into action – if a client is very unhappy about a matter, something happens and people know there are consequences.

Internal change agents are those individuals with the experience and gravitas to be able to generate energy and galvanise opinion. They demonstrate why change is necessary and make people willing to try something different.

I am of the view that we need a combination of internal change agents and change agents brought in with specific agendas. In my own firm, this includes areas such as legal project management and pricing, where we recognise the value in expertise from other industries and the need to drive even harder in these areas.

Conclusion

It’s all about the problem, people! I mean that with and without the comma. When it comes to the plethora of technology solutions, do keep abreast of them, but remember that you need to create the demand pull rather than rely on supply push. So start talking, make those maps, keep exploring and persist.

Mark Andrews is Director – Global IT Service Delivery at Baker McKenzie. He has a varied background, including time in the public and private sectors, along with considerable professional services experience. He has held roles ranging from HR to management consulting and has previously been a guest lecturer as part of University of Technology, Sydney’s Executive MBA program.