Litigation support is a unique field—and no easy job. Done right, it bridges the divide between attorneys and technical professionals, making for much stronger e-discovery. But what does it take to do it right?
The folks at kCura recently asked for my take on that question, but before I jump in, a bit about myself: I joined the legal industry in 1992 as a paralegal, starting my career drafting motions and performing legal research. Today, I help run the tech and strategy behind e-discovery projects for one of the industry’s largest service providers. I love this industry so much that, over the years, I’ve earned both my paralegal certificate and several e-discovery software admin certifications, and chose and received a bachelor’s degree in communication to enhance my career.
What I’ve learned so far is that having both a legal-minded background and technical expertise makes a world of difference for a litigation support professional in today’s e-discovery world, simply because we wear so many hats. Here are a few that I switch between regularly.
Hat #1: The Translator
Attorneys don’t always know what’s really being said when their software admins come to them and say “Hey, boss, this PST is corrupt.” Often, they’re going to nod their heads and move on—to find someone who can explain it.
Likewise, a software admin may well give me a blank stare when I’m explaining why the attorneys need a specific kind of audit history report to respond to a question from opposing counsel.
This is one part I love about being a litigation support project manager: I can follow what’s going on from both the technical backend and legal frontend and ensure those needs make sense to all of my colleagues and our clients. It’s a win-win, and educating myself in both areas makes my job a lot easier.
Hat #2: The Consultant
Knowing both sides of the house also means I get to act in the capacity of advising folks throughout a project’s lifecycle. For example, I’m often asked for my advice on how to, say, enrich data. Let’s walk through that example.
Say you receive data from third parties in a production and the submission includes nothing but static PDFs grouped according to bulk rather than document level. You inquire, and find out someone agreed to that format and there’s no opportunity to push back. We recently got such a submission and I advised my team, given the size of the data set—400 documents at more than 600 pages each—to take a close look at our most cost-effective options. I saw two approaches: have attorneys review them as is and risk a lot of headaches for counsel, who would then be without any sort of metadata as a guidepost in this process; or, have it unitized before importing into our review workspace. Unitizing—and while you’re at it, coding the most important fields such as data, author, and title—gives you much more information at the point of review. So even though there is an upfront cost in having the documents coded and broken to document level, it’s certainly not going to add up to the hours of attorney time wasted wading through page after page of bloated documents with no apparent beginning or end and no meaningful clues in the fields of the database. So in this situation, clearly the second option was a better deal.
As much as possible, you always want to get the data in the best, most information-rich format possible before you put it in the database. Standing as a gatekeeper, the project manager can prevent a lot of issues caused by putting “mystery files” in a database. We want to keep the database clean so we can parse and pivot and analyze it. As a Relativity Certified Administrator, I know what I need technically to do all of that—and a paralegal background provides the legal knowledge to pitch the value, too.
Hat #3: The Air Traffic Controller
As a project manager, it’s critical for me to direct “traffic”—or attention and energy spent—to make every matter I work on as cost effective as possible.
Sometimes, I can eliminate that traffic altogether. For example, it fascinates me how many case teams are using technology like Relativity and still create a totally redundant privilege log manually. When I stop the presses on manual processes and show teams the automated workflow in the software, I still hear people gasp.
The rest of the time, it’s about directing traffic efficiently. When I hear about problems or requests from stakeholders and clients with looming deadlines, such as depositions happening next week and exports that need to happen right away, I know immediately that those are just as real as a production deadline.
By the same token, I know that an attorney needing a printed export of documents he has in PDF format is not the same thing as getting a production out on time. When project managers can tell the difference and remain calm under pressure, it’s good for everyone involved because we can direct the team’s energy the right way.
If you don’t have a legal background or a solid understanding of what litigation lifecycles are like—and the end results they march toward—you’re in no position to push back on those requests, so everything becomes an emergency. That means your team’s time and energy is scattered instead of plotted, and that’s not a good place to be. With the right knowledge of the whys and wherefores of the e-discovery process, you can help your case teams on both the legal and technical side get to a better place.