Every year, law firms spend millions of dollars on new products and platforms, in addition to the ongoing and substantial costs of maintaining and updating existing IT infrastructure, all to improve the quality of the client services they deliver and to increase internal efficiency.
However, for every technology initiative that succeeds, at least as many law firm and corporate law department tech projects “fail to launch” and are quietly abandoned after the user community declines to adopt — or actively rejects — the tool or service. Why are some projects a resounding success and others an abject failure? Change Management offers one possible methodology for winning over a skeptical user community and increasing the odds of success.
Almost all technology projects disrupt an organization’s productivity — even those that are fully embraced and eagerly awaited. For example, new laptop computers will require software to be reinstalled and reconfigured, and key data files may need to be migrated from the old computer to the new one. All of this reduces, at least temporarily, the laptop user’s productivity, at least until the new computer is sufficiently configured so that it can be used for work. In the case of computer workstation upgrades, however, most users happily accept short-term pain for the long-term benefits that the new device will offer. It’s an easy sell.
Change Management acknowledges that there are barriers to virtually every organizational change. By doing so, CM offers a structured way to proactively anticipate, articulate, and address these barriers.
On the other hand, systemic law firm and law department tech initiatives (case management systems, CRM platforms, etc.) do not necessarily offer users an equally obvious cost-benefit result, leading to user pushback — and sometimes, project failure.
Enter Change Management
Change Management (CM) is a term that describes something that many professionals do instinctively every day. Wikipedia defines Change Management as “all approaches to prepare and support individuals, teams, and organizations in making organizational change.” At its most fundamental, CM is simply a formal name for the strategies and techniques we use to prepare human beings (e.g., clients, co-workers, supervisors) to accept change.
While the changes discussed here typically involve updating or replacing infrastructure and technology, the approaches used to educate the user community are not fundamentally dissimilar from a lawyer advising a client about developments in a lawsuit or briefing a client representative on consequences from newly negotiated terms in a deal: i) identifying points of discomfort or tension; ii) explaining the long-term benefits of short-term pain; and iii) getting the user or client excited about the path forward.
Change Management acknowledges that there are barriers to virtually every organizational change. By doing so, CM offers a structured way to proactively anticipate, articulate, and address these barriers. For example, imagine a scenario in which a law firm is deploying a comprehensive case management platform for the very first time. Project management on the technological side will have focused on ways to compile existing case data, populate the underlying database, prepare helpful analytics for case-team use, and usefully report out data from the new platform. CM, however, will focus not on the many technological tasks required to deploy the system, but rather on the human side of the project.
Thus, CM might identify the following issues (along with many others) as key questions that must be answered as part of a successful deployment:
- Who within the organization will have their daily tasks changed as result of the new system?
- Will any positions or categories of staff have significant changes to their daily work?
- Could anyone believe that their position is losing status or authority as a result of the new platform?
- Will anyone be able to opt out of using the new platform?
- What should be the consequences of not using the new platform?
- What are the rewards of using the new platform?
These questions have little to do with the technology solution itself, but they have everything to do with how the new tool(s) will be used within the organization and be perceived by users.
Integrating CM into Technology Projects
Change Management processes should run concurrently with the technical analysis being performed. Ideally, each will inform and support the other. For the technical side, feedback from CM outreach can provide valuable insight into how operations and system permissions should be configured — the workflow that makes perfect sense for the technologist may not integrate as easily into an existing user community as workflow more similar to existing processes.
Conversely, regular reports from the technical side of the deployment can provide the basis for ongoing system status updates to the user community and rolling opportunities to advertise the benefits of the new system. These same updates can also be used to preview workflow changes that will ultimately take place so that they aren’t a surprise when the changes are finally rolled out.
Change Management processes should run concurrently with the technical analysis being performed. Ideally, each will inform and support the other.
On a practical note, project sponsors should decide early only who will lead the CM side of a technology deployment. The technical experts configuring the new tool or system will undoubtedly perform some user outreach as they gather user requirements and conduct alpha and beta tests with early adopters. However, these tasks, while supportive of CM goals, are designed to drive system performance, not build user enthusiasm and acceptance of the new technology. Some experts in the CM field have suggested that organization leadership must be the first to accept the need for change, but it’s equally critical that the everyday system users also understand the need for the change and accept the short-term disruption necessary to achieve a longer-term, larger goal.
Depending on the nature of the technology being deployed, organizations should consider whether their CM Lead should be an organization leader or someone more junior who may have more credibility explaining the benefits of the impending change.
With Change Management, communication flows both ways, and the CM Lead should expect to be a lightning rod for user concerns and complaints. Indeed, the CM Lead should encourage users to voice their concerns, as this can actually benefit the project; it’s much better to deal with timely-received complaints and questions that can be addressed as part of the deployment, not as after-the-fact corrections. In addition, timely acknowledgement and response to valid user concerns can help reinforce that the user community has an important voice in how the technological change is being implemented. This can help with critical “buy-in” as the project progresses, or, as can happen, when a project encounters an unexpected complication or delay.
Change Management is explained through several different models, each with slightly different organization and baseline topics to be addressed. Common to all approaches, however, is the idea that identifying and articulating why a given change is necessary is critical for driving the user community to want this change.
Selling a significant organizational change makes perfect sense, and the absence of this step is common in many post-mortem analyses of failed technology deployment. It also makes logical sense that the more disruptive (and initially painful) the change, the more important it will be for the user community to want to see the process through the disruption to the final rewarding conclusion.
“Practice Innovations” is a quarterly, online newsletter that examines best practices and innovations in law firm information and knowledge management.