Re-inventing the wheel - buying tech or building it yourself

The last few years have been an accelerator for technological advancement within businesses. 

There are many motivators driving the adoption of new technology, including: the necessary integration of eSignatures, the rise in low-code, no-code platforms or the efficiency gains from the adoption of AI-assisted contract review. With this technology boom, an already hard decision has been made even more difficult. When is it right to choose an out-of-the-box solution? When do you look to build your own? And when do you look to have a custom platform created?

When considering technology, the key point is that it must solve the problem that you have and it needs to work for you – not the other way around.  It is easy to get swept away by multiple features that look to solve other problems (even problems you might not be aware of yet) leading you to accept a half-solution on your original problem. This often leads to inefficiencies or opens a pandora’s box of issues for you in the future.  Enduring the frustration of a half-fix for the duration of a contract-length or to justify development time is not worth it when it could be easily avoided!

Be clear on your focus and know what you need

The analysis of any data available and creation of a requirements document with user stories helps with knowing what you need.

A requirements document should list high-level business requirements including required functions and features. For example, you may require single sign on or certain KPI analytic reporting capabilities. To prioritise the requirements, using a MoSCoW ranking allows you to highlight which requirements are ‘Must have’ and so imperative to the end-solution, ‘Should-have’ ‘Could-have’ or ‘Will not have right now.’

When reviewing whether potential technology meets requirements, requirements documents should be evaluated as black and white, with no degrees of grey. The technology either satisfies the requirement or does not. If a solution fails a ‘must-have’ requirement, the solution does not meet your needs.

While you may know what you need, it is important that all users and potential user types that will use the technology are considered within the requirements document. It is useful to hold a workshop with those involved in the process to include their pain-points and use cases. To encourage idea generation, it is important that these workshops are well-facilitated, and participants should be encouraged to bring forward any ideas or points to the table, regardless of status or usual level of participation with the process.

Creating user stories can be a very useful method of getting to the crux of a need for your requirement document, as it ensures you to talk about the functionality you want from the solution. Following the standard format of “As a <user>, I want <aim> so that I can <reason>” can help individuals to articulate their problems clearly in a few words. This can level the playing field when dealing with differences in subject-area knowledge.

Reviewing usage data, any available return on investment figures and other available data can also help paint a clearer picture on what exactly you need. Is it a major process that occurs occasionally? Or does it occur every few hours? Considering the knock-on impact of when the situations occur may also assist you with building your requirements and guiding your conversations with vendors.

Target your options

Write a list of new technology offerings and internal technology your business has already onboarded. If you have a particularly lengthy list of vendors, it is always useful to work through each of the vendors to create a shortlist to demo.

Most vendors have helpful customer teams that are more than happy to help you with working out if their offering is right for you.  Having a brief phone call with vendors to work through your requirements allows you to shortlist vendors that match your requirements before booking a demo with a wider team also ensuring you are keeping your original problem front and centre.

The technology already available to you is commonly overlooked. The Microsoft stack is a prime example of this. Lots of firms do not utilise Microsoft’s offerings to its full potential purely because they do not realise it is available to them. Most vendors operate on packages or contracts for specific configurations of their technology offerings, meaning that you may not get specific ‘add-ons’ from vendors without requesting these. Could your problem be solved by technology you already have onboarded? Does one of the vendors you regularly work with have something that could be added onto a pre-existing solution to solve your problem? Have you exhausted the capability of the technology that you already have, or are only certain features being used?

Suitability beyond paper

You know what you want, have finalised your requirements and shortlist of offerings that meet those requirements. What do you do now? Book demonstrations or have conversations about what a developed solution may look like?

An important part of any offering is the user experience. An offering that has a user experience that is too complex, hard to use or seems illogical to the end-user is likely to see adoption problems, lack of engagement and result in no-one using the offering, regardless of the efficiency gains (or even create further problems itself). Custom solutions, wireframes and prototypes are good ways to get a grasp on the user interface and the user journey and ensure everyone is on the same page.

It is best to use the same team of people for all the demonstrations or conversations, so that you consider every offering from the same viewpoint. The demonstration team should consist of people with subject-matter expertise (if the problem is rooted within a particular subject area) and people that work the process at varying levels. It might also be a good idea to include individuals from your IT department so that any IT issues (or potential dealbreakers) can be picked up early.

Following the demo, the evaluation of the offering should be subjective based on what the team thought about the platform generally but then should also be objective when you refer to the requirements list. The requirements document should be reviewed at regular intervals with regular re-evaluation.

Demonstrations also allow you to think about, and ask questions relating to potential future problems.

• What kind of training is provided?

• What level of training is needed to perform specific tasks?

• Is there documentation or a help base available?

• What kind of support does the vendor provide?

• What are your options for scalability?

• How long will it take to get up and running?

Asking these kinds of questions at this point reduces the likelihood of the process stalling or ending should a key member of the project team be taken out of the business, as well as being clear on exactly what the solution offers. 

Check your risks

Working in law, we are trained to constantly evaluate risk. It’s no surprise that the threat of potential risks can deter individuals from looking to onboard or consider building their own solutions. There are steps that can be taken to mitigate these risks sufficiently so that they are almost negated.

Your IT, InfoSec and Compliance teams are some of your greatest allies when it comes to evaluating technology. Getting in touch with them early in the process and keeping them informed as you work through the evaluation process allows you to cut nasty technical surprises and ensures that you meet any regulatory requirements. Wider firm involvement will also help with onboarding if choosing something new or could even assist with training if something is available for use within the firm already.

Your IT team may be able to assist you evaluate how you could use your current technology stack beyond how it is currently being used, as well as providing you with vendor risk forms. Your IT team should also be able to let you know about any existing technological development they are completing which may be beneficial to your particular needs. If there is a solution coming soon to the business, does the potential cost of installing a temporary solution over the shorter term outweigh the benefit?

Cost needs to be considered. Balancing installation, training and subscription costs against development costs, lost-opportunity costs and maybe even development training can be a tricky one! This is always best evaluated on a case-by-case basis and with your technology strategy in mind. What is your central driver? Is it cost, time to market or something else? Can you afford to take an individual out of other tasks to develop the technology, or would that individual be better focusing on other work?

Weighing up your priorities

Knowing your requirements, exploring vendors and involving your wider business will help you ensure you stay relevant to the problem at hand when deciding whether choosing an off-the-shelf solution or developing your own is right for you and worth the time or investment. Every technology evaluation is likely to have different weightings for different considerations but establishing a framework allows you to evaluate those considerations without having to re-invent the wheel every time.

TLT FutureLaw. Changing the future of law

We are a law firm changing expectations of what a law firm can do. We deliver solutions built on insight, process, technology and client need to ensure better outcomes for our clients.

We have years of experience working with clients to assess their needs and provide solutions to truly meet those needs. TLT’s FutureLaw team is multi-disciplinary group of specialists, including lawyers, process designers, technologists, knowledge management experts, data analysts, product and project managers and other professionals dedicated to meeting the changing needs of our clients.

Should you have any questions or wish to discuss any of the issues raised in this article please contact Carrie Brogden, Legal Technologist or Clara Howard, Senior BD Manager in our FutureLaw team.