Legal process automation is not new.  In some areas of legal practice, most notably the so-called high volume / low value practice areas such as Personal Injury and Conveyancing process automation has been common since the mid 1990’s.

Nevertheless, the legal services sector as a whole still lags behind other sectors with investment in, and delivery of, process automation projects.

I have long experience of working on legal process automation projects and I am surprised to see people still trip over the same hurdles which have been on view for the last 25 years if not more.

Drawing on my experience, I have listed 10 tips to help you if you are, or are likely to be, engaged in a legal process automation project.

This article consists of two parts: five tips for understanding a legal process and five tips for automating a legal process.

 

5 tips for seeking to understand a legal process

1. How to convince people they are working in a process

Sadly, the first thing some of you will still need to do is convince your colleagues that they are in fact working in a process.

Some lawyers still contend that what they do cannot possibly be considered ‘a process’.  Apart from advocacy perhaps, and then only at the point of delivery, I think they are wrong.

Everything and anything can be represented as a process to some degree.  The key thing to explain to those who still resist the idea they work in a process is that a working process does not mean that human judgement is eliminated.

In plenty of processes there can be steps and decision points which call for human decision making, based on real-time knowledge, experience and expertise.  I think this is true even for automated processes.  There is nothing inconsistent in my mind with having a step in the automation which is a pause point while a decision is being made by a suitably qualified human being.

 

2. How to understand a process

The best way of understanding a process is to map it.

A ‘current state’ map should reflect the process as it currently works and a second, ‘future state’ map should reflect how the improved process ought to work.

You will need to give some thought about the level of granularity which you will need to display in your process maps.

If the end goal is process automation, then I think it likely you will end up with two kinds of future state maps.

The first kind (the ‘value stream’ map) should be produced as part of the initial mapping process, where everyone involved process improvement workshops (see below) explains what happens and how things could be improved, without needing to go into the detail of automation (software) design.

The second kind of future state map representation will be your automation software design map.  This will come later, as you are implementing the new process in your workflow software.

 

3. Involve the team

It is not a good idea to load the task of process mapping onto one person, no matter how familiar they are with the current legal service.  Team input is essential.

Different people will work in different areas of the process being mapped and so will be able to quickly provide a reasonable amount of detail about the steps they are most familiar with.

They are also likely to have some interesting observations and questions about steps they are less familiar with, most commonly: ‘why do we have to wait so long for step X to be completed before we can start work on step Y’?

Hence legal service process mapping is best done via a series of workshops, attended by representatives of every role-type found working in the current process.

 

4. Resource the mapping process properly

I am thinking of both skills and time here.

Whoever creates the process maps needs to be capable of working visually and logically.  They also need good facilitation skills to work constructively with the workshop team (see above).

Please don’t underestimate the amount of time and effort required for process mapping.  In addition to the workshops, I often find there is a lot of work to do before and after the workshops.

To be fair, this might be because I spend time clarifying the process in my own mind and drafting initial process maps to be used as baseline maps during workshops.  I know theory says that to create a process map, mappers should approach the exercise with a blank piece of paper and elicit the map from the workshop group.  Generally, though, lawyers are much better at picking holes in something than creating something new from a blank piece of paper.  I have always found it much easier to present my version of the process and let people point out where my understanding is inaccurate or plain wrong.  I welcome this, as the aim is always to help the team build their version of the current and future state maps.

 

5. Be prepared to call time on process mapping

You will never get everyone in the legal service workstream to agree that the current state map is 100% accurate, covering every possible scenario.  This is especially true when working with lawyers.  Our default mode is to leave no stone unturned.  But, as the saying goes, ‘perfect is the enemy of the good’.

As a rule of thumb, so long as the process workshop team can agree that the current state map is 70% – 80% accurate you should be confident you have captured the current state well enough to move on.

Similarly when considering process improvements, please be realistic.  If you had unlimited time and unlimited resources I am sure you could create perfect new processes.  Except you won’t have unlimited time and resources so it’s best to aim at improvements which are realistic given the real-world constraints you have to work with.

 

5 tips when automating legal processes.

1. Review the capability of your current software and systems

Don’t assume that because you are creating new processes that you will have to acquire new software to do so.

Review the software currently available to you in your organisation.  Talk to your I.T department and suppliers.  You may be pleasantly surprised and find that, in technology terms, you already have the capability to automate your new processes.

 

2. Approach the legal I.T. market realistically

If after completing the step above you do need to go to market for automation software, you need to get suppliers to focus on the key features and functionality which are important to you.  Try to avoid the temptation to load RFI’s and ITT’s with lots and lots of questions which are quickly seen for what they are: back-covering exercises.

I am not saying approach the market in a slap-dash fashion, but in all the documentation, conversations, presentations, and demonstrations, keep the focus on the core functionality which is most important to you.  This will help both you and potential suppliers.

 

3. Try before you buy

Ask favoured suppliers if you can try their product for a short while before you commit to buying it.

If you can do this then create a short process which is representative of the kind of process flows you want to create.  The aim here is to make sure you can implement the processes you want to create rather than implementing a process considerably constrained by the software’s functionality.

Every piece of software has constraints.  It’s highly unlikely you will find software which is a perfect 100% fit for all your needs.  But it’s important the automation software you choose will allow you to implement the processes which you and your colleagues have designed, rather than processes which the software ‘allows’ you to build.

 

4. Don’t treat workflow design as purely an I.T project

I noted earlier that workflow developers will almost certainly have to flesh out higher level process maps to help them understand exactly how to represent and implement the desired future state process.

Workflow developers will have to do much else besides but avoid the temptation to view the future state automation as ‘purely’ an I.T project.  It isn’t.

Even with the more detailed process maps to work from, workflow developers will need feedback and advice from people working in the process about a whole range of things such as how best to present on-screen information and printed reports.

Inevitably some of this inter-action will be ad hoc, but it is so much better if the interaction between the workflow developers and the process design team is structured and managed to keep communication flowing and avoid any unwelcome surprises.

The obvious thing to do is to arrange a series of short and regular workshops where the workflow developers walk through aspects of the development to date with the process design team.

 

5. Be prepared to do a lot of testing

When implementing new business software of any kind, a lot of testing is required.  Even more so when there is some internal development is involved – i.e. creation and deployment of new workflows.

Testing should not just take place at the end of workflow development.  It needs to take place during development too, to make sure quality is built in from the start.

Hence ensure that the following kinds of testing take place and take place properly:

• Unit testing during development – to make sure individual components work
• Integration testing during development – to make sure all the units work together as a group
• System testing, – to make sure the wider system as a whole (workflows, and all the software the new workflow software will work alongside) works properly and
• Acceptance testing – end-user testing to make sure the workflows are fit for purpose.

You can never do too much testing, but unfortunately this is an aspect of legal workflow automation that can get often skimped.

Moreover, the kind of testing that gets skimped most of all is the end-user testing.

This is because end-user testing usually involves some fee earner time, and fee earners often feel that they do not have the time to test new software.

If ever there is a false economy this is it.  It is essential the automated processes are tested properly by the end-user community before live roll-out of any kind (including any ‘soft launch’).

 

From legal process automation to legal products

I could write up plenty more tips about legal process automation, and perhaps the most glaring omission from the 10 above has been the absence of anything about client-side considerations.

I will discuss client considerations in a later article, where I will explain why lawyers should turn their processes into ‘products’ and how to make a start with this.