I saw an interesting bit go by on Twitter this morning regarding the trend of in-house law departments conducting technology audits on their law firms. This started about a year ago with an ABA Journal blurb reporting that 0 of 9 law firms had passed Kia Motors GC Casey Flaherty's basic technology test.
If you missed it (like I did) at the time, Flaherty elaborated on his program on the ABA Legal Rebels Blog, and his guest post links to other discussions about it.
The tweet I saw this morning cited an editorial by Charles Christian, editor of the Legal IT Insider website and newsletter. (H/T to Ron Friedman). In his essay (on page 9 of the linked PDF), Christian suggests that lawyers aren't really to blame for their poor IT adoption. Instead, he says, the reason more lawyers aren't tech savvy is that most legal software products have poor usability. If only legal packages worked like Google or Facebook, then lawyers would be flock to those products and unleash their inner techno-whiz, he claims.
Now my wife is a UX designer so I'm sympathetic to that argument, but as I see it poor UI is pretty far from the critical path when it comes to legal productivity. In fact I initially thought that Christian's editorial was going to say something else entirely; I got excited when I read the words
"What we are now seeing is every legal IT training company on the planet jumping onto the we-can-teach-your-lawyers-technology-competency bandwagon but nobody addressing the more fundamental underlying issue of ..."
To me, the obvious conclusion to that sentence is "bad process!" (Christian went with "usability"). Granted I'm an ops guy: process improvement is my hammer and a lot of things look like nails. Still, any business consultant who has worked on any sort of technology implementation will tell you that the technology won't fix the problem if you don't improve the process. Tech tools can sometimes be the trojan horse that forces improved workflows, but without the improved process the technology effort will be for naught.
The main reason the discussion caught my attention, however, is that the "technology audit" being used by Kia (and emulated by others) is the right idea, but the wrong test. Let me explain...
I've had a couple of consulting projects over the past year for businesses whose delivery functions had "gone Lean." They had streamlined their manufacturing and delivery systems, they defined processes and used Kanban to maintain optimal flow, and they conducted Kaizen events to discover weaknesses and opportunities. But both businesses were frustrated with their current rates of improvement—they seemed to have made some solid initial gains from Lean but the rate of progress had slowed.
To me, the root cause in both cases was the same.
The Theory of Constraints teaches us that any workflow is only as Lean as its least Lean component. For both of these businesses, their delivery systems were Lean, but their back-office functions were a mess. Upstream of delivery, sales and marketing were still doing business the way they always had, shoving orders into the system more or less willy-nilly and conducting fire drills as they deemed necessary. And when the delivery teams needed to access shared functions like procurement, legal, or HR, their well-defined workflows hit a wall of uncertainty.
For every step in the delivery workflow, the system managers had defined what inputs were necessary, had arranged tools and workstations to maximize throughput, could tell you how long the step would take once all of the inputs were ready, and could guarantee that the completed product would be free of defects. For every step, that is, that was under their control.
Once a particular piece of work involved, say, Legal, all bets were off (I'll pick on Legal since this is a legal blog). Business owners viewed Legal as a black box. They didn't really know how to engage them (call the lawyer you like the most), didn't know what the lawyer needed to complete a piece of work ("this feels legaly, can you take a look?"), didn't know when the work would be done ("I'm really slammed right now but I might be able to get it to you by EOD Friday"), and didn't know if the work would truly be finished when it did come back ("we may need to go back-and-forth a few times on this").
Here's the funny thing: I heard a lot of these same complaints (and more) from nearly all of the in-house lawyers I talked to, only they were expressing their frustrations with outside counsel!
So even though I like the idea of a technology audit—and to be fair, Casey Flaherty's test went after skills that really should be elementary to legal practice—I'll argue that a process audit is even more important. Attention to effective process encompasses, but does not presume, the use of technology tools to improve the overall value delivered by your function. Technology can be helpful, but many process improvements can work on their own.
Not only that, for in-house legal departments your audit should probably begin with a mirror (held by your internal business customers). If you need somewhere to start, I'd suggest understanding your customer's user stories and using some other Lean tools to understand your internal value stream. Even if your overall business isn't Lean, you can still work to find and alleviate your process bottlenecks to improve your overall delivery.
Once your in-house team is beginning to optimize its delivery to your internal customers, then you'll undoubtedly demand the same of your outside counsel. Conversely, law firms who get out ahead on process improvement may actually be able to sell those services back to their clients, a la Seyfarth Lean. The bottom line is that businesses understand that improved process, Lean or otherwise, is the key to delivering improved value to their customers. Forward-thinking law departments and law firms should realize (and some are starting to) that the same is true for them.
As always, I love to talk about this stuff. So if you want ideas on how to find your bottlenecks or begin a process improvement process, feel free to contact me to set up some time to chat.
© 2014 John E. Grant.