Bridging Law and Technology

The internet was new to households like mine—it was new to almost everyone. Although the world, at dial-up speed, lay at our fingertips, the most we could manage was to insert a 5.25-inch floppy to play Wheel of Fortune, complete with Vanna, or write school papers. After viewing our schoolwork reflected in bright white font on a black screen, we would listen to the buzz of the dot matrix printer as it took the digital and made it physical.

By the time I was a teenager, my high school had bought a handful of Macs, which allowed us to create professional-looking graphics and to “professionally” edit photos for the yearbook. By the time I was in college, course registration was online, though you still had to go to the library to register on one of its computers. After graduating, I began working at a company that boasted about how much of the internet’s physical infrastructure it owned. There I learned everything from how to make cables and run them to our new routers, to how to use project management principles to implement almost anything, a skill that led to my project management certification in 2005.

After a few more stints with other tech companies and more projects under my belt than I could fit on my résumé, I decided to leave project management behind and pursue law. I soon realized, however, that I had not left project management behind.

The opportunities to implement technological tools in law are many, and successful implementation requires good project management. And as I’ve discovered, not all lawyers, even good ones, are good project managers.

Fortunately, it’s not hard to be a good project manager. And despite advances in technology, the hurdles to successful implementation have largely stayed the same. The following principles, gathered as battle wounds in projects large and small, technical and not at all techy, will give you a framework of how to use project management principles to clear common hurdles. So what do you need to do to be a successful project manager?

Pause. First and foremost, pause. Maybe you have been to conferences, read articles, or attended webcasts that pitched some amazing legal tech solution. It is an exciting time for legal technology; there seems to be a tool for just about everything. Instead of looking further into technology that sounds life-changing, just pause. Set the technology aside. This is the most difficult part, as instinct and the fear of being left behind often drive us to jump in without proper thought. Law is fueled by competition. But the best competitors (winners) evaluate and prepare before taking action. Implementing technology without the appropriate forethought leads to money wasted and technology that goes unused.

Start with the problem. Chances are that, as a lawyer, you enjoy analysis, which is an essential precursor to implementing legal technology. Conducting a business analysis will uncover needs and offer potential solutions. This process may involve surveying employees and clients alike on what isn’t working; what is time-consuming; and what would improve ease of use, speed, and accuracy. Don’t forget to tap into that mountain of data that you likely sit atop. Once you isolate a problem, you may find that the solution is indeed a new technology, or it may simply be a new process or possibly better utilization of a tool that you already have.

Assemble a “virtual” team. It is not as futuristic as it sounds. Assembling a virtual team means gathering representatives from all of the departments that may be affected or that may have subject matter expertise that will be helpful. Create a team culture that is independent of the team members’ titles and the company’s structure. The team should be assembled as you are defining the business problem you’re attempting to solve and should be integrated into that process, which will ensure that the solution does not have a buy-in problem down the road.

Let the project manager manage. If a project manager is viewed merely as a note keeper or meeting scheduler by others in the group, especially by those who are used to managing, the integrity of the team will be undermined. One way to ensure the project manager’s effectiveness is to adhere to the project manager’s communication plan. This plan may be as simple as an email distribution list and a regularly scheduled meeting, or it may be more complex. Whatever the communication plan is, stick to it. Resist the urge to have or call meetings without the project manager’s oversight. I have yet to be involved in a project that was plagued by overcommunication, but I have experienced plenty of instances in which off-the-cuff decisions by a select few have undermined not only the project manager but also the entire project.

Use methodology wisely. It pains me when I hear the word “agile” used to rationalize the absence of scope or requirements. What do I mean by “agile”? The “agile development method” is designed to allow for more flexibility in software development, building a solution in iterations rather than all at once. But it is not meant to allow for implementations devoid of expectations. In any case, you should determine if your project would be better implemented as a single larger project, using a “waterfall methodology,” or better implemented in numerous smaller deployments, using the agile methodology. If you find the agile method to be your best choice, you still must define the scope and requirements of the first iteration to ensure success.

Test. Verifying success requires a method of measurement. This is the most undervalued, but essential, area of project management. If the only testing you have chosen to complete is user acceptance testing, be sure to provide the test scenarios. Previously identified requirements provide the information necessary to map out test scenarios. Of course, the testing should fit the solution. A tool that will have only a handful of users does not require load testing (that is, testing to determine how the tool performs when it is being used by many users at the same time), whereas a client-facing tool likely requires more robust testing. Testing should always be done by someone in addition to the developer.

Train smartly. Training is often the deciding factor on user buy-in. Recognize that everyone learns differently and not everyone has the same desire to learn, especially if change to a comfortable routine is the outcome. Because no two people are the same and success requires acceptance, training should be approached in multiple ways.

• Make the change unavoidable. If you are rolling out legal technology that replaces another technology, create a plan to phase out the old one.
• Conduct hands-on-the-tool training. It is rare for an individual to learn better by watching than by doing.
• Train as close to implementation as possible and never sooner than two weeks prior. This is where good project management comes in. Training should have the appropriate contingencies in the critical path; if the implementation slips, so does training.
• Create experts within departments. A well-assembled virtual team consisting of all stakeholders provides necessary experts to help troubleshoot or train and ensure that the solution is actually solving the problem.
• Provide easy ways to find answers, like websites with frequently asked questions and video explanations, or provide cheat sheets. We all love a good cheat sheet, and while I try to never print anything that can be viewed electronically, sometimes a cheat sheet will be used so often that it just makes sense to laminate a sheet for the users.
• Design and write requirements with training in mind. A mouse-over with explanatory guidance may seem like an unnecessary requirement; however, the easier it is for users to obtain guidance, the more likely adoption will be.

Be transparent. It is difficult to embrace internal transparency in a field that places such a high value on confidentiality. But being transparent will prevent headaches that often result from false assumptions made from the unknown. It is unlikely that a single piece of legal technology will eliminate one’s entire workload, much less that of a team, but it is likely that individuals, especially those who are not part of the virtual team, will interpret the technology as a replacement for their skills. The logical response to this fear is to resist change.

Circle back. During a project, our greatest instincts are to jump in without the proper research and to wrap up hastily. Resist both. To close out a project, you need to be able to measure success and learn for the next time. Measuring success means verifying not only that the technology was implemented through testing but also that it solved the original problem identified. The added perk of circling back is that verifying success provides the momentum for the next project.

Repeat. By successfully implementing one piece of legal technology, you have created a baseline for future implementations. You will have learned what works and what doesn’t work for your organization. Discuss, document, implement, and repeat.

_{Copyright © 2020, American Bar Association. All rights reserved. This information or any portion thereof may not be copied or disseminated in any form or by any means or downloaded or stored in an electronic database or retrieval system without the express written consent of the American Bar Association. The views expressed in this article are those of the author(s) and do not necessarily reflect the positions or policies of the American Bar Association, the Section of Litigation, this committee, or the employer(s) of the author(s).}