黑料大湿Posts

Skip to content
Digital Transformation & Operations

Recommended change management practices to plan, build, then deploy successful legal tech

Kenneth Jones  Chief Operating Officer / Xerdict / Tanenbaum Keale LLP

Nadine Ezzie, Esq.  Founder & President聽/ ezzie + co.聽

· 6 minute read

Kenneth Jones  Chief Operating Officer / Xerdict / Tanenbaum Keale LLP

Nadine Ezzie, Esq.  Founder & President聽/ ezzie + co.聽

· 6 minute read

The steps taken by law firms to engage their change management process to Plan, Build and Deploy new legal tech solutions are critical

Change management is like a prism 鈥 depending on one鈥檚 frame of reference, it can mean different things. To technologists, the term often applies to strong development and operational practices; while those in legal generally relate change management to process examination, training, and implementation refinements.

Regardless of your focus, effective change management is critical to a successful digital transformation. So, how can we demystify change management for various members of the legal profession and provide a framework for those in disparate roles to communicate effectively?

One way might be to examine a case study. Let鈥檚 imagine a need where a law firm or legal software company desired to build a matter management system for a client whose legal issues are truly unique, thus requiring either significant modifications to an off-the-shelf software product or a customized software build.

As we embark on this journey, we will identify three main phases of our case study: Plan, Build and Deploy. We will also define the key change management aspects of each phase as we create a customized matter management platform.

Plan

Nadine Ezzie: Ken, from your viewpoint on the technical side of the shop, what are the key change management points to be addressed during the planning phase of a legal tech build out?

Kenneth Jones: The initial phase of a project is one where business requirements are defined. Documenting these in a manner both technologists and legal professionals can comprehend is critical. Defining other essential elements of a project 鈥 such as the need to migrate over legacy data, reporting, data interfaces, and necessary workflow 鈥 is also vital at this stage.

Defining project scope, deliverables, timing (often in stages), and cost are elements of this project phase as well. Specifically as it relates to matter management, defining data points needed in areas such as legal venue, plaintiff information and allegations, the tracking of matter milestones and key documents, and company specific facilities and hierarchies required for reporting are all part of the mix.

In your legal experience, Nadine, what should happen next?

Nadine Ezzie: I find this period to be the most critical when ensuring a successful legal tech transformation or adoption. Attorneys, by our nature, are trained to mitigate risk where possible. Persuading us to change our ways is not easy, but also not impossible. Communication and transparency is key.

Communicating early not only about the scope of the project but also about how it ties into the overall business objectives of the firm or organization can foster greater adoption. I also advise tapping a legal champion of the project. This is someone from the legal team, usually mid- to senior-level, who is open to digital transformation, understands the value it can bring, and will help champion the project to other team members. This last part is critical as these are the users who will actually use the system and enter the relevant data (such as matters, report creation, processing tasks, etc.)

Having your ultimate end-users not only understand the value proposition of the project but also appreciate how it will improve their ability to perform their roles can decrease any sentiments of threat or reluctance to change. Remember, the less surprises, the better.

Defining end goals for a matter management project 鈥 for example, lowering the overall cost of a litigation by x% per year, or reducing the average settlement by y% 鈥 also are excellent approaches for defining the parameters of a large-scale project.

Build

Nadine Ezzie: Now, it鈥檚 time to build the solution 鈥 so, we鈥檙e in your wheelhouse, Ken. What change management considerations should be kept in mind during this phase?

Kenneth Jones: One vital element in this phase is transforming business requirements into a data model with functional specifications. One best practice during the build phase is to construct the new system, in short-cycle build phases often known as chewable bites, and offer frequent visibility to end-users in order to solicit incremental feedback.

Sharing system mockups is a great way to ask users if all the data points associated with a matter are being tracked or if reports created by the system will meet the needs of the client. In our example, this might mean sharing the matter-entry process flow and field list with users prior to moving on to reporting needs to ensure that the required litigation data points are integrated into the system.

And speaking of reporting, reviewing what is created with end-users for purposes like projecting legal costs for future years, filing insurance claims, or assisting with outside counsel evaluation and review processes in an iterative manner makes good sense, especially as reports are built. Indeed, it鈥檚 important to review not only the report content, but also the format (PDF, Excel, etc.) and the ability to export or transfer data to other systems. It鈥檚 also critical to get this feedback from those in various job functions, such as legal professionals, attorneys, or executives rather than just the technologists.

In the technical area, change management in the build phase also should include code repositories, reviewing code changes, and a formal test plan to better implement system changes.

Deploy

Nadine Ezzie: This is the phase we鈥檝e all been waiting for. I find that deployment in phases works best for increased adoption. I work with teams to identify which part of their existing process will be modified first, and then set a time frame for training and questions. Wash. Rinse. Repeat.

End-users need to know they have an advocate and support system during this time of deployment that can relate to this time of change. It鈥檚 also important to tailor messages to different workers through the process chain. For example, those in legal operations who enter and maintain data would get a different message than those in leadership roles who probably never log into a system but use data reports to project litigation impact and cost.

Well-designed and user-friendly support materials help tremendously as well. Make it so these materials are easily accessible so end-users can refer to them easily once live training support has ended.

Kenneth Jones: Clearly, a significant element of deployment is training end-users. They need to know how to address client questions about matters, efficient data update strategies, generating litigation reports, etc. On the tech front, using issue-tracking with tagging to categorize development needs and writing technical documentation are strong practices to follow.

Conclusion

Change management is an intricate process with many flavors 鈥 those coordinated by attorneys, legal professionals, or core technology professionals will likely show those differences.

The better those in the legal profession do, the more likely the result of our case study will be improved outcomes and lower costs that鈥檚 powered by the new technology which was successfully adopted, used, and even appreciated.

More insights