THE UNNATURAL “NATURE OF THE INDUSTRY”
Last week we covered The 12 Intervention Points in a System, and in this post we will review some of the weaker intervention points and why they fail. Then, we’ll identify more impactful intervention points that would prove vastly more effective; busting the myth of eDiscovery’s peaks and valleys for what it is: poor intervention.
Picture this: an exhausted team has been working around the clock for so long they can’t remember what a normal work week looks like; hustling like hell to get a last minute production out the door… again.
It’s a familiar sight in eDiscovery. Even worse, it’s come to be expected: the effects of the workload peaks and valleys of eDiscovery are considered, “just the nature of the industry”. As the same weak intervention points are repeatedly tried and continue to come up short, the myth that these peaks and valleys require long stretches of inefficiency followed by late nights has perpetuated itself. So, what are these weak interventions that allow this myth to exist?
12. The constants, parameters, numbers
Plenty of action goes on at this least effective of intervention points, but not much impact ever comes out of it. Changing policy on criteria for team size, redefining expected hours worked, updating service level agreements… plenty of tinkering takes place, but nothing happens. So, why then do these elements continue to get attention? Because they are easy to access: reports can be run, policies can be quickly updated to reflect a change based upon those reports, and you can pat yourself on the back for coming up with a solution — only to do it all over again next time, because the same problems keep popping up. These numbers can be changed over and over again, but no real, valuable change will ever take place. Moving on…
11. The sizes of buffers and other stabilizing stocks, relative to their flows
The most common intervention point to address a workload is attempting to match it to team size. This is intervening at The 11th most impactful intervention point, “The sizes of buffers and other stabilizing stocks, relative to their flows”. In this example, the “flow” is the work coming in, and the team size is the “stabilizing stock” that ensures the work flows from requested to complete. Standard logic is that increasing the size of the team then increases the amount of work that can be done on time. However, the expense of the team can quickly become an issue: in order to be profitable, the team can’t cost more to run than the amount of revenue coming in from the work they perform.
At this intervention point, the solution is straightforward: identify the average amount of work needed, and make the team size just big enough to handle all of that work but not any bigger, so that a profit margin can be maintained. The issue with this solution is that eDiscovery is a highly volatile and cyclical industry. From one day to the next the team can go from overstaffed to understaffed; from one month being overworked, to the next having nothing to do. On average the team might be appropriately staffed, but that average doesn’t matter when there are multiple competing deadlines during an upswing in workload. That work has to get done on time regardless, so the team hustles into the night and thus the myth perpetuates itself.
“The sizes of buffers and other stabilizing stocks, relative to their flows” is the intervention point that has been most commonly applied to this team size issue, and serves as the sticking point to maintain the myth of unavoidable overwork. So, let’s dive deeper.
10. The structure of material stocks and flows
The 10th intervention point is “The structure of material stocks and flows”. In other words: changing the technology used by the team. And while improving your technology is great and should always be a consideration, it has a minimum effect on helping your team with the human tasks — even if automation or AI takes work away from the team, all that does is reduce the average amount of work for that team, which in turn reduces the team size and maintains the issue relative to peaks and valleys as previously discussed. We need a human specific solution. So, deeper we go…
9. The lengths of delays relative to the rate of system change
The rubber really starts to hit the road with intervention point #9, “The lengths of delays relative to the rate of system change.” When I first started in eDiscovery, the expectation was that I would be prepared to fully contribute to my team 6 months(!) after my hiring date. In other words, the onboarding delay time was 6 months; which means any surges my team faced in the meantime would be handled by the same size team as before my hire. Teams aren’t understaffed during a surge because of a lack of desire to grow a team to match the workload; instead, they remain understaffed because by the time a new team member is ready to contribute, the surge is gone and with it the need for a larger team. The onboarding delay is too great relative to the workload shifts in eDiscovery, which means that if we can intervene per this delay, we have the potential for a significantly more impactful solution to the peaks and valleys.
So, how do we intervene to reduce delays in onboarding to match the rate of change?
The first step is to identify a practical entry point to reduce the delay in contribution: the depth of complexity and nuance in eDiscovery isn’t going to shrink any time soon (in fact quite the opposite trend is taking place). However, the fundamentals remain the same: data is identified, gathered, processed, reviewed, and produced.
The nuance and complexity grows out of this foundation — this foundation may be just 20% of what makes up eDiscovery, but it’s 80% of the work that is taking place. If you haven’t looked up the 80/20 rule, do yourself a favor and take a look — it states that that 80% of consequences come from 20% of the causes — I’ve run the numbers and this holds true in eDiscovery.
These fundamentals need to be run as repeatable and sustainable tasks. Handling each set of data in a new way (intentionally or not) is begging for issues. By focusing on a smaller knowledge base and requiring a structured approach, this entry point becomes manageable and the fact that it applies to 80% of the work being done makes it highly effective, which makes this scenario a prime candidate for an intervention point.
The next step in this intervention is to translate the opportunity into an applicable solution. Clear and concise documentation that defines the processes and best practice for the case at hand can be a highly effective approach. A simple solution is to utilize checklists in order to outline every step of the workflow, and drafting supporting documentation that even a layman could follow in order to execute those steps. This sounds (and is) time consuming, but it’s a proven solution: I’ve personally implemented this very straightforward system of checklists and documentation, and seen onboarding new hires drop from 6 months down to 2 weeks. The new hires weren’t fully versed in every nuance of eDiscovery, but they could efficiently execute the fundamentals that composed 80% of the work required by the team. In fact, with proper delegation we were able to leverage them as a fully functioning team members almost immediately. Furthermore, the documentation allowed team members from other teams in the organization to jump into our all-hands scenarios and help immediately if we requested the assistance. This reduction in onboarding time reduced the delay time enough to match the volatility of the caseload so effectively that we were able to cut the team size in half and leverage the intervention point to handle any surges.
Overworked teams in the eDiscovery space have been an accepted reality, but this expectation has only persisted and thrived because of solutions that have stemmed from weak intervention points. Exploration of an even slightly more impactful intervention point reveals a solution that begins to dispel this myth.
But the question remains: could we drive the impact even further by diving deeper into the intervention points? Tune into the next post to find out!
