Podcast Ep #46: Improving Legal Workflows without New Technology

If you’re a regular listener to this podcast, there’s a pretty good chance that you’re currently using a Kanban board of some kind to manage work in your legal practice. But if you don’t have one yet, don’t sweat. Well, when I first started Agile Attorney Consulting, which is over a decade ago now, that was definitely not the case. I spend a lot of my time teaching people how to build a very basic Kanban board, kind of like I did a couple of weeks ago in episode 44.
Today there are Kanban style interfaces built into software tools just about anywhere you look. Although, as I discussed back in episode 40, not all Kanban software is capable of helping you with some of the more effective parts of the overall Kanban method. But what if I told you, you don’t actually need a Kanban board at all to benefit from the Kanban method?
In today’s episode, I’m going to discuss a case study involving a client of mine who, for institutional reasons, didn’t have the option of implementing a Kanban style software tool at all, but who still has made tremendous improvements in both the speed at which they resolve their cases and the quality of their client experience. Ready to become a more Agile attorney? Let’s go.
You are listening to The Agile Attorney Podcast. I’m John Grant, and I help legal professionals of all kinds harness the tools of modern entrepreneurship, to build practices that are profitable, sustainable, and scalable for themselves and the communities they serve. A quick note before we get started. As I discussed back in episode 42, I’ve been working on a spreadsheet to help law firm owners and legal team managers better understand their gross profitability on a matter-by-matter basis and I’m really happy with how it’s progressing.
I actually used ChatGPT the other day to generate 100 rows of sample data, and that was surprisingly good, although it needed some massaging. But looking at the results of that data, it’s fascinating. For my fake law firm, it clearly shows that one practice area is bringing in a lot of top line revenue but is also pretty expensive to deliver from a direct labor standpoint on a cost of goods sold model. So, the profitability on that practice area is on the low side. I think the data says about 25%.
It also shows a different practice area using a different billing model, where the top line revenue is only about half as much as practice area one, but that contributes nearly the same amount of gross profit to the firm as the first one, because the gross profit margin is closer to 50%.
What that tells me, if I’m in charge of marketing for this fake firm is that I may want to adjust my strategies to focus more on attracting clients in that second practice area, because for every dollar the firm earns in top line revenue, I’m going to have more money flowing through to my bottom line. So, I’m starting to test drive this thing with a few of my current clients, and my plan is to invite a few other early adopters to try it out and let me know how it works for them.
It is still kind of a beta, and it requires a moderate amount of data entry, so it’s not totally free in terms of time and effort to adopt it. But I think the insights it can give are really powerful and especially timely as we sit here in the time of 2025 strategic planning. So, if you’d like to be one of those early adopters, shoot me an email at john.grant@agileattorney.com and put profitability spreadsheet in the subject line. I’ll get back to you and we can discuss specific next steps.
Alright, onto today’s topic. I’m going to give you sort of a case study of a client of mine, and this is an institutional client. This is a public agency involved in professional regulation. And the team I’ve been working with is essentially the public complaint department. They’re that first line of contact when someone has had a bad experience with a person or business in the industry that this agency oversees. And their job is to figure out the nature of the complaint and see if there’s a real issue there.
And often that means requesting information and context from the professional that the complaint was about.  And that means this team sort of acts as an initial mediator between two parties. They’ve got the member of the public who is annoyed or angry or justifiably concerned about something that has happened to them. And then a licensed professional who is now stressed, also probably annoyed and angry that someone has complained about their work.
But also, part of this team’s job is to refer cases up to the agency’s discipline committee if warranted so it serves an important public protection purpose. It’s also sort of the face of this agency for the general public. So, there’s a clear customer service need as well. And the thing is, only a very small percentage of complaints result in even a disciplinary referral, much less, disciplinary action. So, the trick is making sure that the member of the public feels heard and respected and cared for but also that the regulated professional is heard and respected and cared for.
Knowing that the specter of possible discipline definitely ramps up the stakes on the whole interaction.  So, I started working with this team in mid-2023. They had had a spike in volume during the pandemic. And so, they had an open case count, these were complaints that had come in but hadn’t yet been resolved one way or another. There was up over 600 and they had an average time to resolution for a case covering right around 200 days.
So that means on average it was taking more than six months for both the complainant and the regulated professional to get any kind of closure on the thing that came in. And the team members in the department were feeling overwhelmed. This is the most common sort of emotional state when people reach out and seem to find me is that they’re just drowning in work. They’ve got this never-ending conveyor belt of cases that they had to deal with, and they felt like they could never really catch a break.
And also, because the cases were taking so long to resolve, they had a ton of failure demand. This is people calling or writing to get information about the status of their complaint or the complaint against them, which meant now the team has to respond to those questions even though the status updates didn’t really do anything to bring the complaint itself to a resolution. And if you go back to episode five, I do a deeper dive on the concept of failure demand.
One other piece of background, the team is using an older software product to manage their cases that had undergone a lot of customization to meet their needs. So, switching tools isn’t really a good option for them. And public agency budgets being what they are, adding an additional tool like an online Kanban board to manage workflows wasn’t really an option either, especially in the near term, budgets were already set. Fortunately, they did have a budget to do some training and that’s where I came in and the specific training we did was what I call a static workshop.
And static is an initialism, it stands for the systems thinking approach to implementing Kanban, and there’s kind of two overlapping ideas in there. The notion of systems thinking and then the notion of Kanban or specifically the Kanban method. And this is a workshop I really love doing with teams. It’s sort of a combination of diagnostic tool. It’s a team training on the core concepts of systems thinking and the Kanban method.
And then we do some actual hands-on work to apply the tools and techniques that we’re learning to the team’s specific needs and workflows. Although we also do some games and some hands-on work where we’re using completely fictitious scenarios to help them learn those concepts. It’s what we call in Agile or the Kanban method, creating a safe to fail environment and games are a safe to fail environment, we like that.
And we do all of this over the course of about 12 to 18 hours of time in the workshop over two or three days. One of the rules that I’ve come for myself is a day never lasts more than six hours because I know how hard it is for legal teams, in this case, a quasi-legal team, to take even that much time away from their day-to-day work. I want people to be able to get a couple of things done in the morning and then wrap a few things up in the afternoon before they head home from work.
I love this workshop because it has almost an instantaneous impact on the team’s performance and also how they feel about the work. It really exemplifies one of the core principles of the Kanban method, which is to encourage acts of leadership at all levels of the team.
And because the workshop teaches everyone these core concepts and it gives them a common language on how to discuss them. It makes things much easier, and it makes it more likely for the team members to use the tools and concepts to improve both their day-to-day work where they have a lot of individual control. And also, the work of the team overall, team members working together to improve the work of the team overall.
Now, one of the core practices of the Kanban method is to make the work visible, and that applies equally to the work and the workflow. It is actually the first of the practices that come up in the Kanban method. Although I tend to think of the practices as bullet points, not ordinals, meaning you don’t have to start at one of these practices and then go sequentially through them. I think all of these practices are beneficial and actually we’ll illustrate that here in a minute.
With this team in the workshop, we definitely did some visual modeling of the workflow using a Kanban board. And this was one we just drew on a whiteboard in the conference room when and used sticky notes to represent columns and things like that. But we couldn’t actually put that board into production because of the software and budget limitations I talked about. But that didn’t mean we couldn’t use those other practices from the method.
Unfortunately, there’s one other thing that I really like to do with my private law firm clients that was off the table for this team, and that's an intake pause. And I talk about intake pauses back in episodes two and three of this podcast, but the general idea is that when your team is overwhelmed by the amount of work in your system, one of the best things you can do is pause, or at least slow down the rate at which new work is coming in. The metaphor I use is that if your bathtub is overflowing, the best thing you can do is shut off the tap. Then we can work on opening up the drain.
But again, this team being a public entity, they couldn't exactly shut off the complaint line. The local news would have had a ball with that one. We did wind up making some changes to the intake process that I’ll talk about in a few minutes but that didn’t actually come until a fair bit later in the overall improvement work of the team. So, two of my favorite techniques are off the table, making work visible using the Kanban board and implementing an intake pause.
So, what did we do instead? Well, it turned out we did quite a lot. And one of the first things we did was get really clear about defining the workflow phases for this complaint resolution process. We got really intentional about the intake phase, then the initial analysis phase, and then the phase involving communication to and response from the professional being complained about.
We initially described those phases using the modeled Kanban board in the conference room that I talked about. But we also learned how to use a SIPOC chart to clearly define the inputs for each phase, where they would come from, also the outputs or deliverables for each phase, and where they needed to go to. And I’ll review SIPOC is an initialism. It stands for suppliers, inputs, process, outputs, and customers. And it’s a way of modeling workflows a little more fine-grained than just in the columns of a Kanban board.
For a little more info around SIPOC charts, you can listen to episode 16, although I should probably do a deeper dive episode on that tool at some point.
The next thing we did was establish clear deliverables for each phase. These are the outputs in the SIPOC chart. And that included creating some clearer road mapping and mileposts for both the person complaining and the professional being complained about. So that they were better informed about where they were in the overall process and what the next steps were. One of the Kanban principles, not the practices and techniques, but the higher-level philosophies, is to see work through the lens of creating customer value and customer experience.
And so, we wound up creating both a high-level complainant journey roadmap and a respondent journey roadmap to help make sure that the team was adding value for both sets of customers. And also, so that both sets of customers could engage in their own sort of wayfinding and road mapping and understand what the process looked like. And we didn’t necessarily publish a true roadmap out to the users, but it was still really helpful from an internal guidance standpoint.
So, once we knew what the outputs were from our SIPOC chart and once we knew what the inputs were also from the SIPOC chart. We got really clear about converting those into a definition of ready on the input side and a definition of done on the output side for each of our process phases. And this is consistent with the Kanban method practice of making policies explicit, which I initially cover in episode 10 and I dive really deep into methods for writing good policies in episode 22.
We also embraced the principle of seeing work as a series of knowledge discovery steps and I haven’t actually talked about this principle much, but I want you to think about that for a minute. The work that we do in our practices isn’t sort of work for work’s sake. It’s all building to something. It’s building to, frankly, making us and our clients smarter about the situation that they’re in so that they’re better prepared to take an action of some sort and that’s true in litigation.
I mean, the discovery process is literally a series of knowledge discovery steps, but it’s true in the transactional process, it’s true on the client journey for just about any type of legal work you could do. We’re not just doing work. We’re doing work so that it makes us and our clients smarter. So, with this team, we specifically added two questions, not only to the definition of done for each workflow, but even to some of the subparts of each phase.
And the first question was, is there anything we learned in this step that tells us we can close this file? And that’s an interesting one because there are certain criteria that this team is evaluating cases against, these complaints against, that tell them whether there actually might be a need to investigate further. And if those things aren’t there, or if something truly disqualifies the case from qualifying for disciplinary work, you can close it.
So again, that first question, is there anything we learned in this step that tells us we can close this file? If the answer to that question is yes, then we take that case off of the main workflow pathway and we push it to an off-ramp. We can close that file and get it off our plates. Now, if the answer to that first question is no, and it often is, then we ask the next question, which is, what do we need to learn in our next interaction that would help us resolve this case one way or another?
And this helps us make sure that we’re making best efforts to push the case towards a resolution. Again, whether that’s closing the file with no action, pushing it forward to the discipline committee, or pushing it to one of a handful of other off-ramps that are available to this team, but it makes sure we’re not just working on the case. We’re actually intentionally helping it flow smoothly through our systems, through our workflow.
And again, if you’ve been listening to this podcast for a while, you’ll recognize that those questions are really consistent with the notion I talk about of close the closeable. We don’t want to close a file before it’s ready to be closed. That’s important. We still want quality. If we close a file too soon, that could result in a zombie effect where the case finds a way to come back to life. That’s a form of failure demand. But if we really and truly can get it closed, we want to make sure we’re doing that because of all of the good things that happen with closed files.
Both the complainant and the respondent have some certainty, and the team itself frees up capacity. Now, the next thing we did, and we were fortunate here, because the system the team was already using has pretty solid data reporting capabilities, and the team was already using them. So, we embraced the Kanban practice of using data to drive our decisions. This is using feedback loops. Data is a form of feedback.
And specifically, when we ran an open cases report, we noticed that there was a relatively high number of files that had been open for six months or longer. When we get into data analytics and the Kanban method, which often is sort of a later step, but again, this team had good data already, we refer to this as the long tail problem. There are often some really long outlier cases that are impacting the averages because they take so dang long to resolve.
And if we can focus our efforts on ways to move those cases through our system more efficiently, it has an important impact on our overall averages. And so why did we have that high number of files that had been open for six months or longer? Some of them were because the investigations were particularly complex or there were a lot of back and forth with the complainant and the respondent. Maybe the complainant or the respondent or both were particularly challenging personality types, and that happens. But a lot of those cases had just fallen through the cracks.
Again, consistent with that close the closable notion, we paid particular attention to those outliers for the first few months. And we made sure that everything that was still open in that long tail actually had a good reason for being open. The next thing we did, and this might be a little counterintuitive, but we looked at the number of cases that were in their first month of being open. And we actually found that a good number of them, and I say we, I mean the team, I was sort of guiding them through these questions, but they did all the work.
So, the team found that a good number of those cases weren’t really actionable, either the complainant wasn’t able to give much information, or the respondent had an ironclad response as to why whatever happened, happened. Or it was obvious that the whole thing was just sour grapes or even maybe an underhanded attempt to squeeze some money out of someone. But using that same close the closable theory, we actually made some good progress in closing some of those early files in ways that didn’t cause them to boomerang, they didn’t have failure demand afterwards.
So, once we had used some of the Kanban method techniques to better understand the stages of our workflow and try to control for the work flowing through those stages. And then we did that high-level look at the data to just establish the status quo. This is consistent with the Kanban principle of start with where you are now. Start with what you do now. So, we established the status quo.
Then we asked the team a question using the data. We established some goals that were rooted in the data. And the question we asked was, “What are the things that would need to be true for our total case count to go from 600 down to 590 by the end of the month?” Nothing huge. This is a 1% improvement, but it got the team thinking about hitting that target, and ultimately it worked. They were able to get down below 590. And again, I don’t have the full data chain in front of me, but I think it was actually a little bit better.
But we then did this in an iterative way. So, the next month we asked the same question, “What would it take to get down to 580?” And then a month later, 570, and frankly, for those first several months, the team had no trouble hitting or exceeding those targets. And that did a few things. Number one, it met the systemic goal, the overall department goal of reducing the total number of open files, which was a good thing. Second, it focused the team’s attention on that goal.
We used goals to sort of drive, not necessarily behavior, although ultimately behavior, but certainly get people looking at the right thing inside of the workflow. But most importantly, I think it did it in a way that really followed the smart goal format. We came up with a target that was specific, it was measurable, it was achievable, it was relevant, and it was time bound. That’s the initialism of smart goals. And when the team hit those goals each month, we celebrated, including with yummy food. This got the team buying into the changes that we were trying to make happen. And it got them excited to stretch for that next goal.
So, one other bit of info sort of before I give you the improvement punchline. One change that the team did make, and they actually had started this process even before our workshop, but I think the workshop helped inform some of the specifics of this effort, was, they made some changes to the intake form on the public complaint website. And one of the things that you’ve surely heard me talk about is that client homework is almost always a bottleneck inside of a team’s processes.
And in this case, what they actually did was, used changes to the intake form to strategically move their bottleneck earlier in their overall intake process. So, it used to be that it took very little information for someone to initiate a complaint. And then the intake team would process that submission and initiate a bunch of back and forth with the complainer to get the more structured information that the team needed in order to evaluate that complaint.
And then, if necessary, once they had the information, whether they needed to seek a response about the complaint from the regulated professional. And that back and forth with the complainant took a lot of time and a lot of effort from the intake team. It was a significant source of delay because it involved a lot of handoffs. And handoffs are almost always a source of delay because it winds up at the bottom of somebody’s to-do list and it has to sort of work its way back up to the top.
And then for the intake team itself, they’re having to keep track of all of this client homework and that produces a large amount of administrative overhead that isn’t directly adding value to the case. So, with these changes to the intake form, the team was able to push the structured information gathering forward into the complaint form itself.
So, a complainer couldn’t even start the complaint until they provided, at least at a high level, the essential information that the team needed to do their initial evaluation. And this change created three positive outcomes. Number one, it reduced the number of pure sort of sour grapes or harass my provider complaints because it made the complainer work a little harder to get something even started inside of the system.
Number two, it reduced that number of back and forth needed to get to a definition of ready for the initial evaluation phase. Was spending far less time in that even initial information ingestion that was before the true evaluation and that sped up the intake process overall.
The third thing it did, and this was partly because the team was really intentional about giving context and explanation on the intake form on that website about why the intake form required the various pieces of information, is that it made the complainant smarter about the overall process. The intake form was actually turned into something of an educational tool, a road mapping resource.
So that even if the intake team had to go back and forth with the complainer for more information, the complainer was a little bit more up to speed on why they needed to provide those things. They’d at least gone through them on the website, can’t control whether they read them or not, but they were there.
Alright, so here’s the punchline. As I record this episode, it’s been a little more than a year after that first workshop, and what the team has accomplished is pretty remarkable. Let’s start with the total number of open files, it was up over 600, it’s now down to 405 in the last dataset that I saw. That’s more than 33% improvement in that total open files, the carrying load of the team overall.
The other thing is that the average time to resolve a case, which was, as I said, up over 200 days, is now down to 109 days, so close to a 50% improvement. And if you think about that through the customer lens, that’s less time a member of the public has to wait to get a resolution on their complaint, and that’s less time that one of the regulated professionals has to live with the uncertainty about a potential disciplinary action. Either they know for sure that there won’t be one, or they know for sure that they’re in hot water, but that certainty is useful either way.
Now, you’ll notice that the goals I talked about didn’t have anything to do with time to resolution. They only had to do with reducing the total number of cases in flight, limiting work in progress. Again, another one of the Kanban principles or practices. And that’s because we know from Little’s Law that if we can reduce the number of total cases in flight, that we will almost always improve the average cycle time, the time to resolution on the case.
Remember, Little’s Law says that the average cycle time of the average work item in a system is inversely proportional to the total number of work items in that system. So, again, in other words, if you can reduce the total case count, then the cases themselves are going to flow through the system more quickly, and that’s going to improve your time to resolution. And a big part of the reason why that works is that it reduces the administrative overhead of holding cases open in your system.
That administrative overhead takes up capacity from your team, and when you reduce the total number of cases, they can now apply more of their capacity to actual productive work moving those cases forward as opposed to the non-productive administrative overhead work of just keeping track of stuff.
And I should mention that the total capacity of this team remained essentially flat during this whole period. In fact, I think it was actually smaller than normal for a while. If I remember correctly, there was one team member that was out on leave, and they were able to replace them on a part-time basis, but the replacement was less familiar with the work and less efficient at doing it. So, at one point, I think they actually were down a little bit in terms of human power.
But the thing I want to reiterate is that the team made all of these improvements without a Kanban board to manage the work. They’re using tools inside of the Kanban method and these principles of the Kanban method that were powerful enough on their own to result in these pretty substantial gains.
So, let me go back and review the main principles and practices that we used that contributed to this team’s success. Number one, as I just said, they worked to reduce the overall amount of WIP or work in progress that was in flight inside of their systems. And because we couldn’t do an intake pause, they instead had to get really intentional around the concept of close the closeable, including using smart goals around getting those cases closed.
Number two, they embraced the concept of making policies explicit in a few ways. One was describing the flow of work through their systems in a better way and then setting these clear definitions of ready and definitions of done for each of the phases. Next, they did a better job documenting their customers’ journeys through the system, both the complainant and the professional about whom the complaint was made. And then pushing information about that journey, which I see kind of as a form of a policy, towards those customers.
They also used explicit policies around their very first phase, that new case intake, to take the client homework bottleneck that frequently occurred in the middle of that intake phase, and they consciously moved it to the beginning of that phase, where it really was going to push a lot of the load onto the client upfront, before the team had to invest their own time and energy and capacity.
And I didn’t mention it before, but this idea of putting the bottleneck where you want it, was one of the key takeaways from my conversation several weeks ago with Clark Ching in episode 39 of the podcast.
The next thing the team did is they used data to inform their decision making, both in terms of setting goals and then most especially in monitoring progress towards those goals. The team really focused on improving things they could measure and measuring their attempts to improve.
And I don’t want to give the impression that the data was the end all be all, and like I said, we had the advantage that this team was already reporting a lot of this data, so it allowed us to sort of jumpstart these efforts. But I also think a lot of the momentum actually came from the team members’ more subjective feelings of progress and then the eventual feeling that they were getting themselves out of this mode of constant firefighting and into a place where they’re able to manage the work more proactively.
And the reports I get back from this team is that they really do feel way more proactive today than they did a year ago. The last thing I should say, and I’ve been using we this whole time, but as I corrected myself earlier, it really is a they because after that initial two and a half days of our workshop, I had very little to do with the day-to-day activities of this team. Almost all of the improvements came from the team itself. I taught them concepts. I taught them practices. I taught them principles.
I might have seeded a few ideas, but they were really from this workshop both encouraged and empowered to bring their own improvement ideas to fruition. So, I did continue to have a coaching relationship with the team leader, but frankly, even that slowed down after about six or eight months.
So, I want to make a point of saying that this wasn’t a situation where the organization hired me as a consultant to come in and fix things. It was one where they hired me as a coach and a teacher to help the team get unstuck and then teach them these new concepts so they could learn to fix things by themselves. And if anyone on this team is listening and recognizes yourself in this episode, holy cow, am I impressed with the progress you’ve made. You should be really, really proud.
Alright, if this sounds like something that you’d like to consider doing with your team, these workshops are truly one of my favorite things to do. So, if you head over to my website, click the Work With Me link, and then look for the option to book a discovery call. I would be happy to walk through your situation and explore options.
Alright, that’s it for today. As always, if you have any thoughts or questions, please don’t hesitate to reach out to me at john.grant@agilateattorney.com. And if you’re enjoying the podcast, it really does help me, if you go to Apple Podcasts or Spotify and leave me a review. This podcast is produced by the fantastic team at Digital Freedom Productions. And the theme music which you’ll notice I brought back is the song Hello by Lunareh. Thanks for listening and I’ll catch you next week.
Thanks for listening to The Agile Attorney podcast. I’m your host, John Grant. If you found today’s episode interesting or useful, please share it with someone who you think would benefit from a more Agile approach to their legal practice. If you have any questions, feedback, or maybe a topic you’d like to hear me cover, you can reach me at john.grant@agileattorney.com.
To help other attorneys and legal professionals discover this podcast, it helps a lot if you could rate or review me on Apple Podcasts or Spotify. And of course, be sure to subscribe in your favorite podcast app. This podcast gets production support from the fantastic team at Digital Freedom Productions, and our theme song is the instrumental version of Hello by Lunareh. That’s it for today’s episode. Thank you for listening and see you next time.