A Matter of Timing: Your Adoption Problem Isn't Happening When You Think It Is
Published on Wed, May 18 byNicola Shaver

The problem of technology adoption in law firms has been a hot topic lately. This is not a new problem, nor is it one specific to technology. It’s a problem that likely dates back to the first time anyone tried to introduce new technology, new process, or indeed any change at all into a commercial legal environment. 


It’s also not a problem specific to legal. The problem of adoption is fundamentally a problem of change management, and the notion of resistance to change has been written about at length for decades.


Change management in legal organizations does come with its own set of particular hurdles. Many of these are structural: the billable hour, budget requirements, partnership culture. These hurdles must be addressed, but they are systemic and will take years to shift. Other sources of resistance are the result of immature procurement processes, and a fundamental lack of understanding or internal expertise regarding successful culture change methodology. This latter category of obstruction is easier to tackle, and all firms seeking to keep pace with changes in the market will have to do so.


The notion that there is some magic adoption tool or method that can be applied to turn things around when a solution has been rolled out unsuccessfully is, however, wishful thinking. That’s because the most significant reason for low adoption of technology and new process in law firms is timing. 


Most firms and organizations address adoption as an afterthought, or as the last piece in the implementation puzzle, rather than as the cushion in which every element of a project must be enveloped from beginning to end. Treating adoption as something that can be stuck on to the end of a project like pinning the tail on a donkey will ensure that the project has minimal impact on the organization. And yet in many legal organizations, that is what adoption has come to mean.


Law Firm Projects


Consider a typical technology onboarding process in many firms. A business unit initiates a project to implement a new technology platform. Frequently, the impetus for the project stems from one of the following:


  • A need to upgrade an existing system,
  • New circumstances (e.g., Covid) give rise to a need for new solutions (e.g., platforms allowing for remote collaboration), or
  • Hype around a new technology gives rise to a perceived need to invest.


Upon initiation of the project, the responsible department undertakes a brief scan of the market (usually by polling known professionals at similar firms) and undertakes an RFP process with three to five vendors. The requirements set out in the RFP are generated by the responsible department, focused around the needs of administrators of the technology, with minimal consideration for user needs. The perception usually is that it’s poor form to interrupt busy lawyers to ask them about a project that is considered a “business project” even when the end users of the technology will be lawyers. There is a similar reluctance to roll out new or newly configured technology until the configuration has been finalized. There is frequently a sense that showing imperfect or unfinished projects to the lawyers will reflect poorly on the business unit executing the project, which means that roll-out will occur only once the technology has been fully implemented, with bugs having been tested and ironed out. User acceptance testing, in this type of project, is almost always undertaken by a team within IT or a subset of users in another business unit – not by the actual end users themselves. Members of the IT department are often considered an appropriate pilot group. The first time lawyers see the new technology or interface is during training, once the roll-out has commenced. They frequently don’t know that the new technology is coming down the pipeline until they receive invitations to training sessions. 


I have seen this model of project implementation many times, not just for foundational software but also for solutions that were so obviously lawyer-facing that the absence of lawyers in the project framework seemed astounding. One such example was in relation to the roll out of a business intelligence platform designed to show lawyers key attributes about their matters – yet no one on the project team had thought to discover from the lawyers which attributes they considered critical.  


Organizations and business units operating in this way don’t intend to omit adoption or change management efforts from project planning. Indeed, it is usually built in to the plan as part of the roll-out. Once the software is ready, the executing business unit will apply their version of an adoption strategy – training and a communications plan with follow-up tips and advanced training available, for example. The expectation is that the training itself, and the communications around it, are sufficient to generate adoption and usage in the lawyer population. More than this – in many firms, “adoption” is defined in this way: it has come to be synonymous with a post roll-out communications program. The team conducting such training may even be called the change management team. 


After roll-out, if “adoption” hasn’t been done well or is proving unsuccessful, additional communications and training might be deemed necessary. Frequently, however, the organization will stop after the initial training program has been carried out. The training is often recorded and made available on a central learning platform. The project is deemed complete, even successful.


The Need for Change


From a usage perspective, however, the framework for project implementation outlined above almost always fails. It should surprise no one that the model does not work to drive adoption. It’s why so many document management systems have limited usage and why, after investing heavily in new timekeeping software that can automatically capture lawyers’ time, firms may find that few of their lawyers have switched on that capability. It’s why lawyers will frequently be surprised to find that their firm has licensed a particular technology solution, unaware of its existence even after what the firm has deemed a successful roll-out. 


The measures that law firms and business units running technology projects consider to constitute the adoption phase of a project are woefully inadequate. Project implementation in law firms is broken when adoption is considered an end game, an add-on, or even a fix applied post roll-out. 


Approaching adoption at the end of a project does not address even the basic initial steps of change management philosophy, and calling a team that conducts training or issues launch communications a change management team is an extraordinary misnomer. The organization has done nothing to explain to the lawyers in advance why the new technology or process is worth taking the time to learn, or what problem of theirs it is solving, or why they should care. At no stage of the project has the project team considered the lawyers – the users – as central to the project. As the end users of the technology, the lawyers are the most critical stakeholders of all, and yet they have been absent from the entire project. Ironically, the assumption made early in the project that interrupting the lawyers would be unwelcome has guaranteed that the project is undertaken in such a way as to make the lawyers feel like second-tier citizens. They haven’t been consulted about the new technology, and have been kept out of all decisions made about it – when instead, they are the users who should have been absolutely central to every such decision. Without the lawyers’ input, the organization has no way to know whether the technology selected or new configuration set up meets key user needs, or fits within legal workflows. 


When law firms talk about adoption problems, they mean that in spite of having done the “change” work at the end of the project, they are having difficulty getting usage on technology platforms. It is considered to be a problem that occurs after the roll-out of software. But anything done at the roll-out stage to “drive adoption” is paying no more than lip-service to change management. If you have an adoption problem, it started well before roll-out – it started before the project even commenced, when a decision to bring on new technology occurred in the absence of consultation with the end users of that technology. 


In order to be truly effective, adoption has to be addressed before a project has kicked off. Business units in legal organizations need to get over their fear of the lawyers – fear of interrupting them, fear of presenting something imperfect for their consideration – and instead step up and speak to lawyers like the critical stakeholders they are, from the very beginning of every project. 


To receive the next post in this series and learn about successful strategies for adoption and change management, subscribe to our newsletter at the bottom of this page.

We use cookies to monitor the performance of our website, improve user experience, and assist in our marketing efforts. By continuing to browse our site, you agree to our use of cookies.