The process of purchasing legal technology could elicit emotion from the most analytical legal practitioners. From excitement and wonder at the near-endless possibilities, to overwhelm and astonishment at the depth and breadth of available solutions, to fear and uncertainty about the process and outcomes. Legal technology presents so many amazing potential benefits for practitioners, but it can be so hard to select, implement, and reap the rewards. 

Lawyers face many hurdles when purchasing legal technology. It can be hard to sift through the legal technology landscape, which has exploded with a range of new solutions and developing capabilities. It’s difficult to maintain momentum because legal technology requires an up-front investment of time and energy to create long-term efficiencies, while lawyer performance is often measured on a short-term basis (i.e., hours billed, contracts reviewed/drafted). And a big part of the problem is that lawyers are often not equipped with the skills, tools or information necessary to act as a Moonlight Procurement Manager.

Despite the many challenges that legal technology projects bring, lawyers are recognising the upside and investing accordingly. A recent survey by Gartner reported that General Counsel and Chief Legal Officers predict a three-fold increase in legal technology spend for in-house teams by 2025. Another survey from Acritas found that 87% of partners expect their law firms to increase investments in technology in the future. It seems unwise to bet against technology as an integral part of the future fabric of legal practice - warts and all.

So how might we better access the right legal technologies? How can we avoid failed legal technology projects, wasted resources on sub-optimal solutions, or poor ROI for shiny new toys?

This post, and two more to come, will outline how to choose the right technology for your legal practice as a three stage process. Together, these posts will provide a plain-English guide to help lawyers navigate this journey and the tools, checklists and questions you’ll need along the way. Ultimately, I hope that you can love the tech you’re with - or find another one quickly.

Stage one: Prepare

Preparation is the first stage of any successful legal technology project. My suggestions for this pre-purchase stage include visualising the end goal, preparing a one-page plan, mapping key processes, collecting relevant data, and engaging key stakeholders. Many of the principles outlined in this stage are reflected in two of the most popular problem-solving methodologies: Design Thinking and Lean Six Sigma.

1. Set Up a Project Team

Successful legal technology projects are carried by teams with clear roles. Even in smaller legal functions or law firms, the project participants wear various identifiable hats to help drive the project to completion. If you don’t consult IT, you’re likely to encounter massive implementation challenges; similarly, if senior management aren’t consulted early, you’ll risk wasting precious time and energy pitching a business case that has no support. Assembling a project team and assigning roles is the first step in the legal technology process.

Empathy, a component of design thinking, is a useful concept to frame the process of building your project team. According to the Interaction Design Foundation, empathy involves building a deep understanding of the problem at hand by consulting experts (e.g. IT), engaging with those affected by your project (including all end-users) and empathising with the motivations and experiences of all involved. An empathetic frame will help you select a team that is affected by, and deeply understands, the problem you are trying to solve.

While the nature of Project Team roles differ, you might consider utilising the ARCI/RACI framework, which has been adopted by Legal Project Management (LPM) Professionals (see for example the Corporate Legal Operations Consortium (CLOC) LPM for Legal Teams guide):

Legal technology projects are often multi-disciplinary affairs, involving management, finance, IT, HR and Learning and Development. While drawing in too many people too early can hamper progress, it is also a mistake to run hard alone. Sharing your problem and potential solutions with likely end-users and potential project team members is critical to ensuring you have captured the right guiding principles. An open, transparent, and interactive process is more likely to garner widespread support from the right people.

It’s also useful to take an iterative and non-linear approach to building your team. In the early days, you are not hoping to assign titles and responsibilities, but rather to seek input from various stakeholders, consult widely, and formulate a deep understanding of the problem and project from multiple viewpoints. Once you have begun this process, the next step is to start summarising the various inputs into a list of requirements.

2. Define the problem & build your wish-list

While consulting with your team, you can begin formulating a problem statement and building a wish-list, which will ultimately form the basis of your project plan. The key is to focus on your problem and on the requirements, rather than on potential solutions.

Defining the problem involves collecting all the information gathered from the process of establishing and consulting with your project team and crafting a problem statement to guide the process. Here’s a useful framework for articulating problems:

Building a requirements list requires scoping out all interested stakeholders and understanding what would be required to solve the problem from their perspective. This means, for example, understanding IT requirements (such as integrations and APIs) or identifying functionality that might be relevant across other teams (such as plugging into the Sales Team’s Customer Relationship Management software). Your requirements list should also be a ‘wish-list’ of sorts, detailing all the features and functionalities that would help solve the problem you and your team have identified. Whether you build your requirements list through a brainstorm, workshop, or over time in a shared document, this will become a critical tool in your one page plan (more on this next) and will help you measure the success of your project.

3. One page plan

Before turning to the legal technology market, it will be helpful to collate the information gathered from your team, your problem statement and a summary of key requirements into a one page plan.

Vendor-lead technology projects are all about solutions. Most legal technology products claim to increase efficiency, automate workflows, and reduce manual tasks. But those benefits are only valuable if they address a problem that is tied to strategic goals and underpinned by key stakeholders. To avoid being strung along by marketing claims, it will be necessary to develop your own guideline in the form of a short plan.

In particular, a one page plan should answer the following questions:

1. What problem are we trying to solve?
2. How do we know this is a problem? What data do we have?
3. What is our proposed solution?
4. How does this problem and solution relate to our team’s mission/goals?
5. How will we know we have been successful?
6. What will our process look like?
7. Who will be involved?

One page is all you need to outline the big picture and the key aspects of your legal technology solution - it’s also more likely to be read than a longer document. This is also a good time to implement the LACI framework outlined above, assigning roles to assemble the one page plan as part of a collaborative process.

4. Process Mapping

While assembling a business use case can help clarify your reasoning and streamline the process, it can also unearth more problems to solve - all of which demand time and attention. Many legal teams begin by trying to solve an isolated process issue, with billing for example, but find that issue is entangled in numerous other inefficiencies.

Lean Six Sigma’s DMAIC Framework suggests Process Mapping to help illuminate the most pressing problems. A graphic display of steps, events and operations within a legal process can break down the core components of any problem that a legal team faces and provide a ‘current state’ against which the desired tech-enabled ‘future state’ can be contrasted.

Within an in-house legal team, for example, a legal process might look like this:

1. Notification of client issue
2. Collect facts and information via email or a phone call
3. Triage or assign matter to appropriate team member
4. Apply risks analysis/legal analysis
5. Draft contract/provide advice
6. Negotiate with counterparties or collaborate with team members
7. Execute/seek relevant approvals
8. Store the contract/advice
9. Retrieve and analyse

Inefficiency can arise at each point along this journey. For example:

1. Client notifies the legal team at the last minute
2. Inefficient intake and ineffective briefing, failing to capture all the relevant information
3. Manual triage, lag time in assigning to the right lawyer
4. Inconsistent application of risk over time and throughout the business
5. Perpetual redrafting of the same advice/contracts
6. Version control issues making it difficult to negotiate/collaborate
7. Slow and laborious manual execution or approval
8. Manual storage of contracts, limited search or audibility
9. Minimal data and analytics, manual retrieval of contracts
10. Risk of missing post settlement obligations

Process mapping is a helpful exercise to apply to any work flow within a legal business. It can apply at a much more granular level (e.g., billing or intake) or to more lengthy processes (e.g., all the relevant steps in e-discovery). The key is to unearth all the relevant steps that each person takes, so that you can pick the most important issues and evaluate solutions against those problems. It’s critical to ensure you have a great process in place before you start down the tech purchasing path – tech can support a bad process as well as it can a good one - but it only produces the sort of efficiencies and effectiveness you will be looking for if you have good processes!

If you are looking for software to map processes, you might find the following useful:

• Microsoft Visio
• Lucidchart
• Miro

The question then becomes one of prioritising - which of these problems is most pressing, most costly, or the biggest barrier to achieving our mission/goals? To answer that question, you will need to measure.

5. Measure

A compelling business case should be backed by data. This includes data about the size of the problem you are trying to solve and its potential impact on key metrics (such as revenue and profitability). Without data, it will be hard to create metrics of success and justify the cost of investing in technology (ROI) as opposed to the status quo.

In the Lean Six Sigma methodology, the Measure Phase looks at the current process and asks: what is the size of the problem? How bad is it? This means creating a baseline, a standard which can be used in the future to assess the impact and value of solutions. In the example of an in-house legal function above, measurements might include collecting data about:

• Time to complete a legal matter, from intake to execution
• Time to complete individual steps within the process (e.g., from intake to triage, from approval to storage)
• Customer satisfaction with the current process, and with individual steps within the process
• Opportunity cost of current processes (i.e., tasks which are left incomplete as a result of the time-cost of the status quo)

When adding measurements to your proposal, consider readily available data. Many law firms and legal teams have access to troves of useful information that is rarely tapped for projects. For example, billing records can give an indication of time spent on particular issues. IT ticketing systems provide information about which processes end up involving IT unnecessarily. Don’t be afraid to include qualitative data, such as interviews with people impacted by the process. Best-guess estimates and first-hand reports from senior professionals are valuable considerations to take into account.

Without wanting to mince methodologies, I would suggest that the Design Thinking concept of Empathy is a valuable framework for this stage of the process. Empathy involves observing, engaging and empathising with people to understand their experiences and motivations, as well as immersing themselves in the physical environment so you can gain a deeper personal understanding of the issues involved from the user’s point of view. This deep understanding of the issue will help set your technology project up for future success.

Your measurements will give weight to your one page plan, and will also help you address a key consideration for any legal project: should we build, buy or borrow?

6. Build, borrow or buy?

Build, borrow or buy is a strategy consideration, initially popularised by Laurence Capron and Will Mitchell, and applied to legal technology by Eric Chin of Alpha Creates, that poses three potential options for legal technology procurement:

• Build: Develop new capabilities internally. This will be a viable option where no existing solutions are available, but relevant resources (such as software developers, data analysts and coders) are on hand.
• Borrow: Licence existing legal technology solutions, or repurpose existing platforms from other parts of the business.
• Buy: Acquire legal technology and integrate into practice.

When evaluating these options, it is essential that you have sufficiently analysed the current state of play. Many law firms and corporations have huge amounts of tech solutions available - some of which may have been purchased for a particular purpose, but can be applied to wider issues.

As you evaluate existing solutions, you may also consider a fourth option: bending. Most major platforms have numerous additional features and applications (and often more in constant development) that can be bolted on to increase capability. In some cases, bending existing solutions could potentially be quicker and more cost effective than starting from scratch. Here are some examples of bolt-ons to existing platforms:

• Microsoft Suite: Microsoft Teams and Sharepoint are common solutions used by law firms and legal teams, and are increasingly being altered and built-upon to create semi-tailored solutions to various problems, from communication to document management, to matter management and docketing. Bending Office 365 can range from simple to complicated, for example, from facilitating communications between clients and team members (see for example the American Bar Association’s Second Edition of Microsoft Office for Lawyers), to custom-built Matter Tracking solutions. There has recently been a rise of vendors selling technology built on popular platforms and consultants who specialise in tailoring existing software. For example, Epona helps firms turn Sharepoint, Office 365, and the Microsoft Suite into document management systems for legal teams. Arrow Consultants helps firms design Office 365 Case Management Systems.
• DocuSign: Many firms and legal departments have adopted e-signatures to meet the requirements of remote working, and DocuSign is the leading platform. DocuSign’s Contract Life Cycle Management (CLM) solution integrates with the e-signature tool and with DocuSign’s Agreement Cloud, creating a streamlined end-to-end solution for contract management.

When evaluating available technology solutions, consider sharing your one page plan with relevant internal stakeholders and asking the following questions:

1. Do we have access to existing solutions that might meet our requirements?
2. Would our existing solutions require tailoring?
3. If so, can you give an indication of how much tailoring might be required?
4. Are you aware of any other planned purchases or solutions in the pipeline?
5. If we were to go ahead with this project, would you have capacity in the next 6-12 months to assist?
6. How much time will each user need to spend to be upskilled in any additional features?

There’s also an opportunity to engage with friendly external stakeholders at this stage. Valuable insights can be drawn from connecting with other professionals in different organisations who have been through the technology procurement process, or speaking with senior innovation, procurement, or legal business management professionals who understand the issues you are grappling with. We will explore this process further in the next blog post.

While there are certainly benefits to exploring your firm’s/organisation’s existing technology, it should be guided by the principles of user experience, saving time and money. Custom developments and bolt-ons can be costly (especially when specialist consultants are involved) and may require multiple rounds of input from you and your team, with no guarantee that the solution will end up meeting all your requirements or being used. Ultimately, you will be better able to answer the ‘build, buy or borrow question if you are equipped with the tools outlined in this post.

7. Crowdsourcing

Consulting with stakeholders beyond your project team is the beginning of the final process of phase one. In this final step, you will consolidate the information you have gathered, pressure-test and pilot your ideas, and seek support for the next phases of the project.

Here are some of the key questions to ask decision makers when discussing your one page plan:

1. What do you think the impact of this problem is? What will happen if it’s left unsolved?
2. What are your thoughts on our proposed solution?
3. Are there any other projects running across the business that might be relevant to this project?
4. How does this align with your strategic objectives/KPIs?
5. What do you think the biggest barriers to success will be?

The crowdsourcing process, like many of the steps in phase one, should be iterative and ongoing. Capturing feedback at each phase of the legal technology purchasing journey is a worthwhile long-term investment to ensure that the solution you ultimately choose is the right one - and you are building buy in, understanding and commitment to it from all relevant stakeholders along the way.

Conclusion

Purchasing legal technology is a big project for lawyers. Unfortunately, big projects often fail - even those run by professional project managers (which lawyers certainly are not). Indeed, as Project Management Expert Peter Dombkins has said, most projects fail “not because they deliver late or over budget, but because they deliver the wrong thing.”

The strongest defence against failure is preparation. The aim of this post has been to detail the process of preparing for a legal technology project and to show that it needn’t be overly complicated, time consuming, or costly. In fact, my hope is that the steps in this three part guide, if implemented correctly, could save legal businesses from wasting precious resources on the wrong platform, or on technology that is already available somewhere else in the business.

Lawyers will continue to purchase legal technology and drive legal technology projects, despite the increasing complexity of the legal technology landscape and despite the lack of training and information about the legal technology purchasing process. Hopefully, this guide helps alleviate some of the confusion and worry around the first phase.

In the next post in this series, I’ll turn to the legal technology market and examine phase two of the legal technology procurement process: Evaluation.

About the Author

Sam Burrett is a legal professional working across law, business, and technology. Sam manages key client relationships at Clayton Utz, a leading Australian law firm, where he has frontline exposure to the latest innovations in legal service delivery. Previously, Sam helped in-house legal teams navigate legal technology and agile talent models at Plexus, and began his career as a law graduate at LegalVision, Australia's largest NewLaw firm. Sam is motivated by a personal mission to accelerate the future of legal practice by advocating for new technology and legal business models that benefit lawyers and clients.