Legal teams often begin a technology project by looking at products.
They attend demonstrations, compare features and ask vendors how their platforms could improve the way the team works. But if the team has not clearly understood its current processes, documents, data, stakeholders and decision points, it may not yet be ready to make an informed buying decision.
In a recent episode of In-House Matters by Lawcadia, Lawcadia co-founder Sacha Kirk spoke with Jane Platt, Founder and Principal Consultant at Streamline Legal Ops, about the foundational operational work legal teams should complete before buying or implementing technology.
Jane brings more than 20 years of experience inside public company legal departments, with roles spanning contract processes, data migrations, compliance programmes, records management, discovery and legal technology implementation.
Her central message was clear: technology cannot fix a process that the team does not properly understand.
Legal Tech Readiness Starts Before Vendor Selection
The pressure to adopt technology is real.
Legal teams are managing increasing workloads, tighter resources and growing expectations around efficiency, governance, reporting and AI. When the existing way of working is creating delays or frustration, starting with a technology demonstration can feel like the quickest path forward.
Jane explained why teams can fall into this trap:
“There are a lot of vendors out there. And there’s a lot of shiny stuff out there. Vendors have great looking software and everybody wants to see what AI can do to make their lives better. And so that just feels like a shortcut.”
Technology platforms often reflect common practices from other organisations. They may include established workflows, templates, fields and reporting structures.
But another organisation’s process may not reflect the legal team’s risk profile, decision-making structure, stakeholder expectations or operating environment.
A General Counsel who approves every contract requires a different workflow from a team that delegates authority across business units. A regulated organisation may require controls that are unnecessary elsewhere. A team managing complex services agreements will have different requirements from one primarily purchasing goods.
The platform may be capable of supporting these differences, but the legal team first needs to understand what those differences are.
If You Cannot Describe the Process, You Cannot Build the Workflow
Jane’s understanding of legal tech readiness was shaped by an early career experience building a contract management system internally.
As soon as the project began, the technology team started asking practical questions:
- What should the workflow be?
- Who needs to be involved?
- When should they become involved?
- What information should the system capture?
Jane realised that these questions had to be answered before the technology could be configured.
As she put it:
“If you can’t describe what you do, how can you possibly build a workflow for it?”
One way to test whether a process is understood is to imagine explaining it to a new employee.
Could the legal team clearly describe how a request enters the department, who assesses it, what approvals are required, where information is stored and how the final outcome is recorded?
If the answer changes depending on who is asked, or the process operates in five different ways, the team has identified an operational issue that needs to be addressed.
Jane recalled advice from a former CFO:
“It’s impossible to be consistently excellent without a process.”
Consistency matters because technology formalises processes. If key decisions around processes have not been made before implementation, they will need to be made during implementation, often under greater time pressure and with more people waiting for answers.
Start With Who, What and Where
Jane recommends beginning with three basic questions:
- Who is involved?
- What information, documents and materials are required?
- Where are those materials currently stored?
These questions may sound simple, but they often reveal complexity that has developed gradually over time.
For contract processes, legal and finance may be obvious stakeholders. However, the business owner responsible for the relationship with the counterparty is also part of the process. Executive assistants, procurement teams, information security, compliance, IT and senior leaders may hold information or perform tasks that are not visible to the legal team.
Documents may also be spread across multiple locations.
Jane described experiences finding contracts attached to purchase orders, saved in email accounts, sitting in DocuSign, stored on local drives or held as paper copies on an executive’s desk.
This highlights that before a team can migrate its documents or maximise technology, it needs to know what it has and where it is.
Centralising documents and creating a basic register can therefore be a valuable first step, even before a larger technology investment begins.
This work helps the team identify:
- What documents exist
- Which documents are missing
- Who owns the relevant business relationship
- What information is available
- What data will need to be cleaned or migrated
- Which patterns and gaps appear across the document collection
A document register may also pinpoint information gaps that are difficult to identify when documents are reviewed individually.
For example, a team may compile a list of 100 contracts and then realise it has no reliable description of what each agreement covers. That insight can inform future data requirements and reporting.
Collect User Stories Before Writing Requirements
Before writing detailed requirements, Jane recommends speaking with the people involved in the current process and collecting their stories.
The starting point is a simple request:
“Tell me how this works.”
As stakeholders explain the process, you can identify who is involved, where information and documents are held, where work becomes stuck and which parts of the process cause frustration. This provides a clearer picture of how the work operates in practice, rather than how the legal team assumes it operates.
Jane said these conversations are better conducted in person or by video call. This allows the project team to ask follow-up questions and see and hear the frustration associated with particular parts of the process.
It is also important to look beyond the most obvious stakeholders. In a contract process, for example, legal and finance may be involved, but so is the person within the business who manages the relationship with the counterparty. Jane also highlighted executive assistants, who may see the process from several different perspectives.
Her advice was clear:
“Get the right people. Get more people. At this stage when you’re gathering stories, you want more people, not fewer.”
Collecting these stories early can also help engage busy stakeholders. Asking how the process affects them demonstrates that the project is intended to address their problems as well as those experienced by the legal team.
The information gathered can then be used to identify common problems and develop requirements that reflect how the organisation actually works. As Jane explained:
“Talk to people and find out what they know because they know things you don’t know.”
The aim is to involve the people who hold relevant knowledge early enough for that knowledge to shape the technology decision.
Use AI to Analyse and Build Requirements
AI can support the requirements process, but the quality of its output depends on the quality of the information provided.
Jane suggested using an AI tool to analyse the user stories and identify patterns, recurring pain points and common needs.
This can help the team move from a broad collection of stakeholder experiences to a more structured set of business, functional and technical requirements.
However, this is different from asking an AI tool to produce a generic requirements list for a legal technology project.
Generic requirements may look comprehensive, but they may not reflect how the organisation actually works.
Sacha explained that vendors are sometimes provided with AI-generated requirements that look valid at first glance but on closer investigation and discussion with the legal team do not align with actual business needs and processes. The risk is that the legal team and the vendor head down the wrong path, wasting precious time.
A stronger approach is:
- Gather real user stories
- Use AI to identify themes and draft potential requirements
- Review those requirements with the relevant stakeholders
- Confirm which requirements are genuinely important
- Prioritise them according to business impact and risk
AI can accelerate the analysis but cannot replace the underlying discovery work.
Collect the Data You Will Actually Use
Technology projects can also become overcomplicated when teams try to collect too much information.
Once a team sees the reporting and automation possibilities available, it can be tempting to create long forms and capture every potentially useful data point.
Jane’s advice was to find the right balance.
Teams should ask:
- Why do we need this information?
- What decision will it support?
- Who will use it?
- When should it be collected?
- Does it need to be mandatory?
- Is the correct information available at that stage of the process?
The timing of data collection matters.
Jane gave the example of a contract effective date. The final effective date may not be known when the request is first submitted, so asking for it during intake can produce inaccurate information that needs to be corrected later.
The process should collect information when it becomes reliable and relevant.
Legal teams should also begin with the reporting outcome in mind. If senior leaders need visibility over risk, workload, cycle times, external spend or engaged law firm, the required data needs to be built into the process.
Implementation Is Also a Change Management Project
Buying the right technology does not guarantee adoption.
Jane has seen strong technology fail, or take 2 years to succeed, because the organisation did not properly address the people affected by the change.
She described three broad groups that tend to appear within an implementation.
The first group is the early adopters. They understand the problem, feel the pain of the current process and are ready to try something different.
These people can become valuable allies. They are often willing to test early versions of the process, identify problems and help other users understand the change.
The second and usually largest group are the “persuadables”.
They may not be excited about the project, but they are willing to participate when they can see how it will help them.
For this group, the implementation team needs to explain the practical trade-offs. Submitting a request through a structured form may take slightly longer than sending an email, but it can reduce repeated questions, improve visibility and prevent information from being lost later.
The third group is made up of resistors.
Jane acknowledged that some people may never be persuaded. Her recommendation was to contain that resistance where possible, while still listening to the concerns being raised.
As she explained, resistors may have valid points that the implementation team should consider and address where it can.
Involve Users in Demonstrations and Testing
Stakeholder involvement should not end once requirements have been collected.
Jane recommends involving representative users in vendor demonstrations and testing.
This gives them an opportunity to understand the available options, see why particular decisions are being made and provide feedback before the system goes live.
Testing together is particularly valuable as this gives the implementation team direct insight into how users respond to the system. By working through the process together, the team can identify what users find difficult, adjust the configuration where appropriate and focus training on the areas that require more support.
Early involvement also creates greater ownership.
When stakeholders understand that the project began with their problems and that their feedback influenced the outcome, they are more likely to support the change.
Jane explained:
“What you’ve [effectively] said is, I care about how this process works for you. Tell me how it works for you, and let’s see if we can make some of that better for you.”
That is a stronger basis for engagement than asking stakeholders to react to a nearly completed system shortly before launch.
Know When the Team is Not Ready to Buy
A legal team may recognise that it needs technology without being ready to select a vendor.
Jane recommends a two minute readiness assessment built around questions such as:
- Who is involved in the process?
- How does the process currently work?
- What documents and data exist?
- Where are they stored?
- What problem is the team trying to solve?
- What budget is available?
- What is the expected timeframe?
- Who should participate in demonstrations and decisions?
If the team cannot answer these questions, it may need to undertake more foundational work before starting the buying process.
As Jane said:
“If you can’t answer those questions, you can’t pick a vendor.”
She also noted that readiness is not necessarily all or nothing.
Most teams will be well prepared in some areas and less advanced in others. The readiness checklist helps identify where further work is needed and provides a practical next step before the team begins speaking with vendors.
Better Preparation Leads to Better Vendor Conversations
When a legal team has completed the foundational work, vendor discussions become more specific and useful.
Instead of asking whether a platform can manage contracts or legal matters, the team can explain the exact process it needs to support.
For example:
- The business user must complete a structured request form
- Legal must assess the request before it progresses
- Different approval paths are required depending on risk or value
- The system must capture particular information at defined stages
- Documents need to be stored in an approved repository
- Specific stakeholders need visibility without receiving access to the full matter
These are requirements that a vendor can demonstrate and respond to directly.
The team can evaluate whether the platform supports the actual process, rather than being guided primarily by the features the vendor chooses to show.
Preparation also makes implementation more efficient.
Documents can be organised for migration. Data gaps can be identified earlier. Stakeholders understand the purpose of the project. Decisions that would otherwise delay configuration have already been considered.
The objective is to make informed decisions and build enough flexibility into the system to adjust over time.
Final Thoughts
Legal technology can improve how legal teams manage work, information, risk and relationships.
But before they start looking at technology the legal team must begin with a clear understanding of the problem, the process, the people involved and the outcome the team is trying to achieve.
Teams that undertake this foundational work early are better positioned to ask vendors specific questions, select technology that fits their environment and support stronger adoption after implementation.
Legal tech readiness is ultimately about identifying and addressing knowledge and process gaps early, before they become expensive implementation problems.
