When evaluating new technology, a proof of concept can be a very helpful way of ensuring you get what you think you are getting while avoiding unnecessary costs.

However, we sometimes see proof-of-concept projects that go off the rails, don’t achieve the expected outcomes, and cost a lot of money.

There is one particular mistake that we frequently see people make.

When scoping up a proof of concept, you need to be very clear about what you need to see for the proof of concept to succeed. What is the concept you need to see proved?

While it is often helpful to see something a little more complete so that end-user experience and adoption can be assessed, there are often some technical aspects that your chosen solution needs to be able to do, but there is currently some doubt about. It’s best to focus on these first. If you cross that threshold, then you can do more.

In a document automation proof of concept involving complex documents (not just the basic NDA or MSA that many suppliers want you to use), we suggest that people look at features such as the ability to do repeats within repeats, and perhaps within repeats. This can be very important - for example, when dealing with more complex party structures where there could be several parties of different types. Some parties might be trusts, with multiple trustees. Some trustees could be companies, and each company may have multiple directors. The real world can be surprisingly complex!

In this case, you would want to know that you can easily target any of the details within the party description at any level and use them at various points in the document while also being able to create complex strings of text that can be used to set out party names, legal descriptions, and addresses (individually and collectively).

Another key differentiator might be how easy it is to work with tables in a document. If you have created your Word templates to look great and to be very easy to navigate, read and understand through the use of a good layout and formatting controlled by tables, the last thing you want is for your document to need to have all that formatting taken out because the automation solution is not capable of handling tables.

A similar issue we encountered recently was where the browser based automation software wasn’t natively working with Word to build the document, so it couldn’t do automatic cross-referencing of clauses. A lot of effort then went into writing JavaScript to try and calculate what the cross-reference should be. Madness!

A third example might be integration. A vital point of the whole project might be that you need to get information from one system into your document automation solution through integration because that is how you will reduce risk, avoid unnecessary time and cost, and achieve your overall return on investment. If the integration is not possible, then the viability of the whole project may be in doubt.

I could go on. The specific things that must be checked for will vary from project to project.

If you don’t know what particular things to look out for in your proof of concept, we can help! Contact us to discuss your project and how we can assist you in focusing on what matters.

Where we see people then go wrong is that they ask the provider to automate a whole document (or even multiple documents) as the proof of concept. This is an expensive approach to take.

If there are particular issues you need to verify, a better approach would be to take the potentially problematic key features, put them on one page, and ask the provider to prove that they can do those things. If they can do all of them, then you have confidence that they can continue through the whole document and do everything else that is required to check user experience and adoption, or broader workflows.

Remember:

• Once you have pulled in the data for one text field via integration, there is little value in showing that you could also pull through the data for another 40 (or 400) fields.
• Once you have shown that you can work with one table, it can be safely assumed that you can also work with other tables.

However, if you can’t work with the first table that you encounter, it’s a pretty good sign that you’re not going to be able to do the rest. There is no point automating hundreds of simple text, number and date fields that can be done easily but with a lot of time, but won’t be of any use because the key requirements weren't met.

If the system being trialled can’t handle the party details in one document, you’ll probably not do any better in any of the other documents.

There are many other ways a legal automation project can fail, or cost more than expected, but this one is easily avoidable. Keep your proof of concept simple and focused on what really matters. You can quick evaluate and find the best solution, ruling out those that are not viable, and save yourself a heap of money.