Please enjoy this blog posted on behalf of the co-authors, Nadine Ezzie, Founder + President, ezzie + co. and Kenneth Jones, Chief Operating Officer, Xerdict.
Recently, we published a piece on change management via the prism of a legal tech matter management case study. In this ILTA blog, we drill down on the case study to provide six concrete suggestions – three user-facing and three more technological in nature – to assist those in the ILTA community to integrate strong change management principles in their technology efforts.
Three Tips - User Facing Aspects Of Change Management In Legal
Change Management for Legal Professionals - Communication
Imagine being in a relationship for years and realizing that things have grown stale. You know for continued success and happiness, something needs to change. You start to make big changes without communicating them to your partner, assuming that “of course they [should] know why I’m doing this!” Instead, your partner feels caught off guard, creating a narrative in their mind of what’s driving the change, leading to miscommunication, false assumptions, and tension and/or friction. Sound familiar?
All of this could be avoided with clear and concise upfront communication and expectation setting. Change management for legal professionals is no different.
The success of any change management initiative for legal professionals will depend greatly on the level of communication and expectation setting to the legal users. Lawyers are inherently risk averse and can be very much set in our ways. You can overcome this by:
Communicating the value proposition of the initiative to legal users as early and frequently as possible. These should come directly from the executive sponsor of the project to build credibility and trust. If that person is not a member of the legal team; a legal champion should be designated to work in tandem with the executive sponsor(s).
Properly setting the expectations of legal users. Change management is hard enough without creating unnecessary friction and there is nothing more frustrating than improperly set expectations. Avoid this by setting clear and honest expectations with legal users, e.g., expected time investment, timeframe to experience results, etc.
Create a forum for honest feedback from legal users. Users may have initial concerns about an initiative for legal transformation. Creating a forum for open and honest feedback will ensure users are heard, concerns are assuaged early, and transparency is provided to project sponsors that can aid in adoption later on (see below).
No one possesses more knowledge as to the behaviors and motivations of legal users than legal users themselves. As a result, any solid solution development should include:
Comprehensive user interviews. Assumptions should be made when designing a legal solution but those assumptions must be tested and refined through legal user interviews. You’ll be surprised at what incredible insight legal users provide when guided, ensuring your solution build will actually solve the problem at hand instead of creating new ones.
Beta/Quality Assurance phases. If possible, build in Beta phases to any deployment to allow users to try a solution for a period of time and provide critical feedback before a final deployment.
Phased deployments. Beware of deploying too large of a solution at once - greater rates of adoption come from phased, bite-size solution deployments. Identify what’s most critical as part of the solution’s foundation and deploy that first until successfully adopted. Repeat by deploying additional layers of the solution - doing so in this phased manner will decrease users’ apprehension to a new solution, increase the likelihood they will try it, and ensure sustainable adoption.
After all the hard work of successfully deploying a legal solution, continuous use and adoption will be driven by providing quality support materials legal users can access on their own when needed. Some best practices include:
Live refresher training/check-ins. It’s wise to schedule check-in sessions post deployment and once user training has ended to make sure users are supported as needed. Cadence can decrease to once a month or quarter as users become more comfortable with the solution.
FAQs and user manuals that are easy to understand and find, e.g., use images where possible instead of text. Make sure the materials are intuitively located such as within a deployed application or within an internal portal - avoid EMAILING materials at all costs.
The deployment of a learning management portal - this could include how-to-videos and guides specifically designed for your team and the solution deployed. While a more sophisticated approach, it serves as a great replacement for live training sessions with the benefit of being accessible by users at any time.
Three Tips - Technical Aspects Of Legal Tech Change Management
Change Management Systems
Production system changes are inherently dangerous. Tech teams need to know what is coming down the pike, what the changes are and understand potential rollback options in the event of problems. Core elements of solid practice in this area include:
Communicating changes in advance of execution.
An approval mechanism, routing the proposed change to a cross-section of technologists (technical, management, security staff) prior to execution.
Requisite detail to allow any skilled technologist to understand the changes taking place and the rollback procedure in event of problems.
Ideally, change management systems automate the function via workflow and notification technology.
Issue tracking systems
Somewhat obviously, most needs arrive in a single stream from end users (a Help Desk ticket, email, personal interaction, etc.). It’s a strong practice however to “translate” these into a task tracking system, assigning “issue tags” to each reported need.
By doing this, all needs are memorialized, can be prioritized (high, medium, low), can be categorized (bug, reporting, new feature, security) and assigned to the proper individual.
Benefits of maintaining a common departmental task repository are substantial. Tasks don’t fall through the cracks, status is maintained in a common system for collection team review, and it is easy to constantly revise priorities, employee workload and the like.
We are all busy, so it’s easy to sweep this item under the rug. But, for those who do, that’s a huge mistake.
Every project has a myriad of unique aspects. Application code storage locations and details, security settings, system accounts, tools which are implemented, vendors involved in a project are just a few of the items to be documented. The legal technology employment landscape is incredibly dynamic (both in terms of those will skills being recruited to other firms and all the employee reduction in force actions we are seeing in industry thus far in 2023).
Accordingly, without delving into gory details on how documentation should be developed, as a starting point be sure to carve out time on every project to at least give the generation of technical documentation the Good Ol’ College Try.