Technology is simply a tool. Just as tools are ineffective without guidance and execution, the cleverest software cannot help lawyers do their jobs better without the right combination of hardware, people, and process. Hammers are quite useful in pounding things; scissors are quite useful in cutting things; neither is a particularly good pencil. Creating a process where software is wedged into an inapposite use is unlikely to produce desired improvements, user adoption, or better results for the client.
Too often the instinct for solving a practice problem is to purchase software that is promised as a panacea. More often than should be the case, poorly designed and poorly planned acquisition and implementation lead to frustration and disappointment, underutilized software, criticism of the sponsor, and the creation of a negative example for the next technology consideration.
Over the last eight years, we have considered, designed, and implemented large- and small-scale practice innovations across disputes and transactional practices, typically with a technology component. That experience has led to several lessons for the adoption of technology to improve service delivery.
Successful selection and adoption of process improvement requires a multi-disciplinary team. To be sure, someone in the group needs to understand the firm’s existing technology infrastructure (people, hardware, and software), its limitations, and its potential expansion. A grand plan sponsored by the lawyers to adopt a software tool that cannot meet the firm’s digital security concerns is a potential train wreck of angry lawyers and frustrated staffers. Similarly, a grand plan sponsored by the information technology (IT) staff to adopt a software tool that does not consider how attorneys work or what client’s require is another potential train wreck. For example, creating a process that requires clients to access a digital portal, upload documents, answer a questionnaire, and incorporate a digital signature might seem grade-school-level techno-sophistication to the IT team. For a lawyer whose client base is technologically unsophisticated, however, the solution may well be worse than maintaining the status quo.
The key lesson is that selecting the technology should be the last step of the deliberation. One cannot evaluate software without understanding how it will fit into the existing technology infrastructure. One cannot evaluate software without understanding how it will interact with users and their methods of service delivery. If users do not understand the purpose of the software or do not believe their methods would benefit from using the software, evaluating (and implementing) the software is pointless. Moreover, forcing users to conform their process or abandon their historical process because of the requirements of a new piece of software often leads to resentment and “civil disobedience” (ignoring the new process and requirements). Reversing the first two elements of the traditional formulation of “people, process, technology” is the better course.
Every lawyer will recognize service delivery methodologies in their firms that proceed in a particular way because “that’s the way we’ve always done it.” It’s hard to imagine a worse justification. Instead, evaluation (and improvement) of a service delivery needs to happen in a structured, formal, and inclusive way.
The first step in evaluating how technology might improve a service delivery is deconstructing the process. Each step of the service delivery needs to be identified and mapped. Lawyers will be tempted to reach for their legal pads and draft a prose description of the process (as they understand it to happen). A legal pad isn’t conducive to a group evaluation or editing. A common way of collaboratively mapping a process is to use different sizes and colors of sticky notes on a large whiteboard (or even the glass wall of a conference room). The goal of mapping the process—as it really happens, not as the senior-most lawyers think it happens—is to visualize each step, looking for bottlenecks, re-workings, and inefficiencies. To map the process effectively, everyone involved in the service delivery should be consulted and provide input on the process map. It should surprise no one that lawyers, staff, and administrative assistants often have very different views of how a service is actually delivered.
The next step is to reimagine the service delivery from a blank slate. What would be the most efficient way to deliver the service, balancing the sometimes competing goals of speed and quality? This is more difficult to decipher than it seems. The challenge is summed up by a quote sometimes attributed to Henry Ford: “If I had asked people what they wanted, they would have said ‘faster horses.’” Reimagining a process might mean jettisoning “the way we’ve always done it.” This can be uncomfortable for some: old dog, new tricks, etc. It may well be that, through evolution, the examined process has become as efficient as it can be. If so, declare victory (making sure the process under review is fully documented before celebrating) and move on to the next process. But experience suggests maximum efficiency is rare.
Designing the new process presents the opportunity to introduce technology to facilitate quick completion of low-level cognitive tasks, speeding up the involvement of trained specialists to accomplish higher-level cognitive tasks. Software is faster and more accurate than humans for low-level tasks like inserting a name and address or remembering the last time the client needed the task completed or housing large volumes of data. But in redesigning the process, one should avoid the adoption of software just for the sake of adopting software.
Redesigning the process should ask what ideal combination of people, process, and technology will result in the most practical, accurate, and efficient service delivery. Members of the team who have spent time surveying the software market or who have expertise in adapting technology that is already in place contribute importantly to this phase of process design. What are the tools that can be readily adapted within time and budget constraints? What’s the next best alternative and what performance is sacrificed with that option?
Once the process is redesigned, those involved in the service delivery should be reconvened to review the proposal. This is the time for tweaks, but, more importantly, this is the time to convert the reluctant. Very few changes can be accomplished by fiat. Put another way, civil disobedience and snipers can quickly derail a new process. Don’t underestimate the effort involved in winning over the reluctant. The classic change management specialists’ articulation—WIIFM (what’s in it for me?)—is a guidepost in setting up your discussions. Putting the case in specific, personalized terms is powerful persuasion. Don’t overlook an influential constituency—having a client on board because the client is convinced of efficiency gains may persuade even the most unenthusiastic lawyer.
The first few post-conversion weeks are a crucial time for a new process. Your launch of the new process will have been preceded by training and perhaps will follow a period of side-by-side coexistence of the new and old processes. By all means, if the new process flounders because of faulty design or execution, immediately remedy that. But if users balk because the old process is more familiar or in the short term faster, stay the course. The last gasp of the snipers is to be expected. (“See, I TOLD you it wouldn’t work!”)
Change-management planning and techniques come into play. Successful change requires good people management. Celebrate in a public way the converts who are making the new process work. Have a contest or another recognition event to acknowledge the early adopters. Involving firm leaders or clients in this recognition will spur others to adopt in hopes of similar public praise. This is also a time to check in with the halfhearted. Public acceptance by actors who are known naysayers may convince the fence-sitters to join in.
Once the new process has been battle-tested, and not necessarily by all who will use it, retire the old process. Do what has been apocryphally attributed to the ancient Greeks and the Spanish conquistadors as a way to focus the attention of the troops on the amphibious invasion at hand: burn the boats. Focus attention on the new by making a return to the prior way of doing things unworkable. Of course, archiving old data in an accessible way is a prerequisite to decommissioning old processes or technology.
At an appropriate post-launch interval, review the new process to ensure it is being implemented in the designed fashion and that its blueprint is not flawed. Focus on the views of the people working the process and on the customers of the output. The user interface and the customer experience may need to be adjusted. Don’t be so in love with the original design as to ignore dissatisfied users and customers. No one, not even those on the implementation team, is 100 percent comfortable with change, but being proactive and flexible pre- and post-launch will help embed the new process.
Ultimately, the process is part of a customer service model—law firms exist to serve the needs of their clients. You don’t want clients to be stuck writing with scissors.
