At the tail end of last year, I poked a bit of fun at lawyers in a piece about the problems we now face as a result of lawyers belatedly embracing technology. All kidding aside, the fact that, lawyers have, generally speaking, adopted and now rely on technology is of course encouraging and beneficial for the industry as a whole.
It does, however, introduce other important considerations when it comes to selecting which technology to use, the methodology around how it is deployed, and our expectations around results and performance. We also have to acknowledge that not all lawyers and legal professionals have the same level of understanding and experience with technology. Some may have a strong working knowledge of what is available in the market; others might still be fearful of what “failings” might result, and many still fall into the mind-set of “a little knowledge is a dangerous thing”, or make the mistake that technology is a “silver bullet”. I do not mean this to be in any way cynical. On the contrary, I propose that we all do what we can to assist lawyers (and judges), whatever their depth of technical knowledge and ability might be. It comes back to one of the most important facets when seeking to advance, defend, or determine legal issues and processes – Communication.
Communication v. Assumption
I have long extolled the virtue of open communication in the legal process. Cooperation within and between legal teams has always been beneficial and is now mandatory – expressly required by Court rules. Cooperation is only possible if there is good communication. All too often, communication is overlooked or limited. Even worse, is when replaced by a far more dangerous concept – the assumption.
There is a real danger, when following some long-awaited case law on use of technology in legal proceedings, that we believe that all lawyers (and judges) are knowledgeable on the in the ins and outs of, for example, TAR (Technology Assisted Review), CAL (Continuous Active Learning) and Predictive Coding. This is both a dangerous and unfair assumption.
The above is an example of a high-level instance of a dangerous assumption. When dealing at a more granular level, making assumptions can cause real problems. For example, it is important to understand the legal team’s experience and not assume that each member has previously been involved in a document review project. The reality is, they may have little or no understanding of how the process works, or even how a document review is carried out from a practical perspective. In this instance, it is vital to take matters back to the basics.
Another common assumption and misunderstanding in the document review setting is when the review feeds into a technology’s Continuous Active Learning programme. Here, it is essential that the review coding decisions be solely based on what the reviewer sees on the face of the document in front of them. The fact that the reviewer is only paying attention to the document at hand, and is not influenced by other attachments and contexts, is likely to be lost on the instructing lawyers who will soon lose confidence in the process unless the reasoning is explained to them in advance. Again, a dangerous assumption is that they already know that this course of action has been adopted and why.
There are many other such examples — too many to deal with here, but particularly around de-duplication, propagation, and the logistics and consequences of such options for the review and/or production.
Legal Speak and Tech Speak
Another area for consideration is translation. Over the years, I have experienced many instances of lawyers making a request and the tech provider blindly running the requested searches only to result in the requesting lawyer being frustrated by the documents returned.
While many law firms have the benefit of in-house Litigation Support/eDiscovery teams to help ‘translate’ instructions from legal speak to tech speak (and vice versa), it would still be remiss to assume all is clear and collectively understood. Rather than blindly accept and action an instruction at face value, a good eDiscovery professional will seek to understand and validate what exactly it is the lawyer is seeking to achieve and then move forward to construct their own searches or actions accordingly. A very basic example of this (and, to be fair, this was many years ago, not long after the introduction of eDiscovery platforms) was when a lawyer did not appreciate the difference between the “AND” and the “OR” search operators. “I want everything sent to X and Y”. Instead of requesting the search to be run as an OR search, it was requested as an AND search. Consequently, the results were much smaller than expected. I also recall an instruction from a regulator to run a set of searches across a dataset, “expressly as set out in (their) letter”. I could see at a glance that in doing so, we would not catch many of the expected documents. Again, were there to be a line of open and collaborative communication between the law firm and the regulator ahead of the instruction, we could have restructured the searches and the results would have been far more productive.
Communication Within the Team
I have always been a proponent of having the entire team attend the project kick-off or planning call to, I as I like to put it, “ensure we have the right people around the table”. This might result in a high-attendance meeting, but the value of each attendee bringing their own skillset and aligning their understandings and strategies across the team early provides context and cohesion that will pay dividends further down the line.
Teams will vary from one case to the next, but should include combinations of:
· Client legal team · Client IT experts (mail and file share systems experts, etc.) · Law firm legal team (partner, senior and junior associates, project manager, trainee, paralegal, etc.) · Law firm eDiscovery expert · External eDiscovery expert/provider · Document Review provider (usually a senior project manager)
Further, some combination of the above should be reconvened at various stages of the proceedings to check-in and address any new and emerging issues.
Suggestions for an Effective Team Meeting:
- Never under-estimate the value each team member and discipline can bring to the table. If involved early enough in the process, the eDiscovery Provider and Document Review Provider can bring their respective experiences to bear to ensure efficient workflows, ensure data is structured sensibly and advise on analytical processes that can readily bring pertinent documents to the fore. The Review Provider PM will also be able to advise and feed into the structure of the Briefing Protocol, such that it will be of maximum benefit to the review team. They can also provide reassurance as to the complex processes and quality control checks that will be applied to the review task.
- All team members should be treated as equals when it comes to the value of their contribution. Those at the end of the chain should not blindly accept instruction and “get on with it” if they think it is flawed in some way, or perhaps not doable in the required timeframe; regardless if the person giving the instruction is more senior or higher up the pecking order. All participants should be given the opportunity and supported to speak up and suggest an alternative course or explain any feasibility issues. To do otherwise, would be to assume that the person instructing already knows of the issues when in fact they may be blissfully unaware. Likewise, those making decisions that impact strategy, scheduling, etc., should not commit to them before they have heard from all team members.
- Always maintain a comprehensive record of the meeting. Obtain sign-off of meeting minutes or notes to reduce the risk of misunderstandings and, dare I say it…assumptions.
Tips to Aid Communication
- Don’t walk on eggshells – If you are not sure whether the person you are dealing with (at whatever level) has the same understanding as you, ask the question and be ready to explain your understanding.
- Don’t be overly-sensitive and offended – If someone you are dealing with (at whatever level) questions your understanding of a particular technology or process, take the feedback and work together to get on the same page.
- Don’t be afraid to ask for clarification – It’s ok not to know! It doesn’t matter if you think the other person might expect you to know. It is far more important that you fully understand the technology and processes.
- Don’t alienate others – Be open and approachable at all times. It’s a two-way street and you don’t want team members to feel unable to voice their questions, concerns, and need for clarifying information.
- Don’t think it’s too late in the game to ask questions – Work on the basis of a “clean slate”. It is never too late for you to query how something works, what it does, how it does it or why a process or course of action is being taken. It is dangerous not to seek clarification because others assumed that all was already understood.
Having said all that, don’t ask questions for the sake of it or solely to demonstrate that you “know your stuff”!
Communication Between Teams
These aforementioned observations, tips, and rules also apply to communication between teams – be they litigating parties, regulator/responding entity, or court/parties. It is always a best practice to open a dialogue with the party or authority that is making a request, rather than simply ploughing on with it. If you are able to give them confidence that you understand what they are seeking and can see a better way of getting to the desired end result, it makes for a far smoother and even more cost effective engagement.
It’s worth restating, don’t assume that the requestor understands the problems that you might foresee when carrying out their request. Instead, be ready to challenge the request in a constructive way. The requestor might mistakenly assume that technology is a silver bullet” or they may not realise that they are being wholly unrealistic in their expectation. I recall a regulator insisting that a document-by-document linear review be carried out for a particularly large dataset unless a 100% cast-iron guarantee could be given that not one document would be missed. Though we employed a methodology that consisted of analytical processes, validation searches, and sampling, that guarantee was, of course impossible to give.
A key element to gaining mutual understanding is addressing the terminology and sufficiently defining each party’s understanding of various acronyms and technologies.
In a litigation context, the need for strong communication and technical, legal speak, and terminology clarification and translation takes us back to a key requirement for the success of the Disclosure Pilot. There are many references in the Practice Direction and associated forms to technology and technological processes. It is crucial that all parties – and the court – have the same understanding of what the words and phrases mean and any consequential effects that might flow from them. In particular, it is important for all concerned to appreciate and acknowledge that there might be restrictions to how different technologies can be applied to certain types of data. It is not a one size fits all – and some data types will need to be analysed separately and by a different means.
Just as a judge might rely on an expert witness to guide him/her on complex specialised issues on which he/she might not have a deep knowledge, it is not unreasonable for him/her to also require litigating parties to better inform him/her on technological processes and abilities that might assist in the collation, production and presentation of evidence. Accordingly, parties should be ready to better communicate how they arrived (or propose to arrive) at their trial bundles and evidence sets.
Technology is now soundly established and being efficiently deployed to assist in managing the vast pools of potential evidence in an efficient and cost proportionate manner. We are also beginning to benefit from the Court rules that have now caught up with the technology that allows us to trawl through those data sets, the size of which continues to grow exponentially. To achieve maximum benefit from both, all we need now is for common sense to prevail and for parties, judges, and regulators to engage in productive communication.
Now that we have a profession that has come to not just embrace, but rely on technology, developers will forge ahead with even more impressive innovation and analytical functionality, safe in the knowledge that they have a responsive audience. Success, however, will be predicated on legal clearly expressing their requirements and ensuring developers fully comprehend real world needs and challenges.
Published by LegalIT Insider