Stop me if you have heard this one. A law department says that it wants to “increase efficiency.” Not really sure what that means, the department leaders decide that it must include moving some things they do manually—or things they don’t do at all—onto a computer system. All agree that computers make things efficient and by using technology, the law department will be perceived by those outside the department as “with it.”
The department proceeds to spend a lot of time developing “specs,” researching possible solutions, vetting vendors, and bringing home the idea. The planning process stretches over months, the paperwork is drawn up, the GC makes her pitch, and the department gets authorization to move forward.
Now the fun begins! The vendor comes in and helps the department plot how to bring the software online. The software is introduced (no need to get IT involved, this is software as a service (Saas))so all you need to do is reach out over the Internet, configure the system, integrate it with your existing processes, train everyone, and make sure all happens as it is supposed to happen. Naysayers are shot down as Luddites committed to a way of life no longer acceptable in an enlightened law department. Within the time budgeted the project goes from idea among law department leaders to implemented software doing its thing.
And then the other shoe drops. All agree the software helped. But it hasn’t helped as much as everyone thought it would help. There also is the time. The software wants information to do its job, so people in the law department get caught up feeding the software. Also, the business changed while the software was being implemented. North is now South, East is now West, and Southeast is now part of the corporate family. All those changes meant the software had to be re-jiggered.
Some questions have come up. Since the software is a data hog and everyone now feels like a data entry specialist, people want to know what is being done with the data. In many cases, the answer is: not much. It is being collected for the very good reason that it can be collected. And by the way, when they said the software “works” with the twelve software packages already used by the law department, they meant “does not aggressively destroy.” It seems “works” is a squishy concept.
All-in-all, people now use the software, the software has changed how people do things, people don’t waste time on things they did before, but they do seem to spend a lot of time on new things, and no one can definitively say whether the new things are better than the old things, but they sure are different. The key is that the GC can proudly report the law department is tech savvy.
Follow the Data, Not the Pack
The story may sound familiar because it is one repeated often by law departments. Many departments other than law fall into the same trap, but I’ll keep my focus on law departments. This also isn’t a “who is to blame” essay. Software vendors are in the business of creating and licensing software, so we really can’t blame them for doing what they do. It is tempting to blame the law department, but that wouldn’t help, and they really aren’t to blame anyway. They followed a traditional path trod by many for bringing software into a department. So what went wrong?
In lean thinking, we prefer to focus on the process not the people. When things go sideways, we look to the process and how it could be changed. The people were just implementing the process and we should not blame them because they did so. We should change the process so the next time the people implement it things do not go sideways.
We can identify some process problems in the law department story. First, it seems they jumped the gun in going to software. Rather than learning and improving existing processes, reducing waste along the way, they went to software as the silver bullet. Put in process improvement terms, they went to software before they had reached the limit of process improvement. Second, in going to software, they went big. The decided to go for the platinum, all bells and whistles, cooks your breakfast while making coffee and feeding the dog, version of software. Third, they did not test the software hypothesis before jumping to implementation. The hypothesis was that software would improve efficiency. But, instead of running some experiments they acted on the assumption.
Since these are process failures, we can improve the process to reduce waste and improve the likelihood of a better outcome next time. In the next three sections, I’ll briefly look at how the processes could be improved.
Jumping the Gun
Every law department delivers legal services using a bundle of inter-related processes. Those processes vary by department (often by lawyer) and so there is no one-size-fits-all. The processes vary by corporate culture, historical precedent, who is performing the processes, and constraints imposed by the organization (e.g., processes other departments use). The first step should have been to identify and document existing processes. Then, the department could have used process improvement techniques to eliminate waste. If nothing else comes out of the exercise, it means the law department will not “institutionalize waste” by building it into an expensive software program.
Of course, documenting and improving processes can do much more. Often, you eliminate many steps, so neither people nor computers need to do them. Simplifying steps may mean that existing software can handle the job. Documenting processes means that everyone can follow the processes, which eliminates problems caused by conflicting ways of doing things. Finally, process improvement is quick, low cost, and flexible. When the business changes, it is much easier to change processes than to change software.
For law department leaders, there seem to be two goals to software: zero or big. They justify big on the grounds that everyone in the department must use the software. Most lawyers may work on contracts, but those contracts vary across the board. Despite the variance, everyone must use the contract management software which has a workflow designed for the lowest common denominator. That may make sense, but seldom do I find a law department that learned their processes well enough to make that decision before plunging into expensive software. Conversely, I often find law departments who learned that the one-size fits all assumption did not work well.
This is where the lean concept of “cells” comes into play. A cell can be a group or team that does a contract type. A lawyer may belong to many cells, but a cell is devoted to one thing. The team that does distribution contracts should work out their processes and, if software fits into those processes, look for simple software that fits the purpose for their cell. Perhaps some Word macros, or simple implementations of workflow logic or document automation would work best. The software tools will be easier to program (and re-program) and will handle the tasks needed, without interfering with other areas of the processes. The cost is much lower, quality is easier to control, and the department leaders will not be forcing everyone to do data entry or learn tools that don’t help them. Training someone new to the cell is easier, because the software is simpler to learn. Even if you do need to go big (e.g., everyone uses the same package to store and retrieve documents) you can focus on a tool that does that one thing well, instead of the multi-purpose tool that does many things not very well.
Test Your Hypotheses
As I said, law department leaders view the world in binary fashion when it comes to software: zero or big. There is an alternative. Instead of jumping to the big software, law department leaders can look at the adventure as a startup. Again, always start by learning and documenting existing processes. Yogi Berra’s admonition, “If you don’t know where you are going, you’ll end up someplace else,” is a good one. Then, instead of going big, start small by testing hypotheses.
One online grocer started this way. Instead of building out the software so people could go online, fill their cart with food choices, pay, and then sit and wait for the groceries to be delivered, the grocer went small. It put up a simple web page describing the service and a phone number. When a customer called, a real person took the order. Another person went shopping, delivered the food to the customer’s home, and took payment. Hardly a scalable model, but a great way to gather data and test hypotheses. The startup founders knew they could build the software. But they didn’t know if the idea would work.
The manual system allowed them to test their ideas at very little cost. Would people call (they could always move to online orders)? What would people order (keep track on a spreadsheet)? How frequently would they order (another spreadsheet)? What features would they want from the service (keep a list of desired features)? These and many other questions were easier to test in “small mode.” As they understood more about what the customer wanted, they could (and did) start building the online business. Eventually, they transitioned out of the manual approach and into the online approach, but by then they had answered many critical questions.
Law department leaders can follow the same approach with software ideas before going to software. Instead of boiling the ocean, pick a small group and have them “manually” do what the software would do. Keep testing, asking what features you need, learning where there are rough spots in processes, and gathering data. At some point, you may be ready to look at software. Now your focus will be on what you need not on what vendor’s sell. You may find that a much simpler package, or perhaps two or more very simple packages, will do what you need for less money, with better quality, and give you more flexibility, than the one big package.
Why Go the Lean Path
It is easy to spend money. It has gotten easier to spend money and successfully install software. It still is difficult to hold off, assess what you really need, clean up processes, re-think how you do things, and then spend only what you need to spend, not what you are authorized to spend. Going the lean path yields greater and more sustainable results, often getting results well before the traditional path of plan then spend big. It also fits much better with the modern, flexible business.
Running a law department efficiently, one of the keys to getting greater responsibility within the modern corporation, is much more than trimming costs. It involves knowing how to do things differently, innovate, and create new models to replace old methods. Having seen the fallout from those who simply pursue the traditional path, I have found that many programs intended to create efficiency end up creating more waste (especially when you add in the costs of having to redo the efficiency effort). For your next adventure, think lean startup and follow a new path to a better outcome.