THE UNNATURAL “NATURE OF THE INDUSTRY”, PART 4

In our last post we reviewed Intervention Point 6 of the 12 Intervention Points in a System. By implementing Intervention 6: The structure of information flows we were able to modify the design of our checklists + documentation in order to increase their easy of use, ease to adopt, and to optimize the continuous improvement program.

In this post, we will explore how modifying the rules of the system itself can further the effectiveness of the approach we have been building via intervention points 12–6.

As we descend through the intervention points we make increasingly significant progress — at Intervention 9: The lengths of delays relative to the rate of system change, we created a set of checklists and support documentation in order to reduce onboarding time; at Intervention 8: The strength of negative feedback loops, relative to the impacts they are trying to correct against, we created a continuous improvement program in order to eliminate errors during onboarding; at Intervention 7: The gain around driving positive feedback loops, we identified how to kickstart a positive feedback loop in a desirable direction; and at Intervention 6: The structure of information flows, we explored how to modify the structure of the approach itself in order to optimize how information flows through an organization. Now we will review Intervention 5: The rules of the system in order to guide behavior and further optimize our approach.

5. The rules of the system

Every organization is governed by rules; some written and others unwritten. These rules drive the behavior of the people within the organization: written rules dictate behavior in a deliberate manner, while unwritten rules inspire a more creative flow. Both written and unwritten rules have their place in a system, but when misapplied they can be disastrous. Furthermore, a written rule that drives the wrong behavior can be worse than leaving it unwritten. To this point, the approach we have built thus far is requisite on deliberate repeatable actions, so we have a distinct need to determine how to effectively deploy written rules within our system.

Now, organizations have plenty of written rules that we could explore, but for this post I want to focus on two specifically that will have the most direct impact on our approach.

Our approach per intervention points 12–6 relies on consistency, delivers consistency, and thrives on consistency. And while I won’t argue that every case in eDiscovery doesn’t have nuances that make it unique and special, I will argue that the handling of the operational aspect of eDiscovery for every case does not. As such, the first rule we need to establish is one designed to remove the nuance bleed over that plagues the industry — by doing this, we will increase the scope, impact, and success rate of the system we have been building.

The Archetype Rule

Two phrases that always make me shudder are, “eDiscovery Cowboy” and, “We are on the bleeding edge.” The former is an excuse for not knowing where you were going before you even set out; the latter is the excuse when you realize you didn’t know where you were going after you got there. Both exist in an organization because there is either an unwritten rule that proclaims, “just get shit done”; or there are weak written rules in place that govern only a small portion of the necessary operations, which leaves the rest of the ops to old Option A: Just get shit done.” I’m all for getting work done, but if it’s “just shit” then what’s the point?

The cure to “just get shit done” is an overarching rule that drives consistent, accurate, and predictable results for every aspect of eDiscovery operations. This is The Archetype Rule.

The Archetype Rule allows us to define a set of eDiscovery case strategy archetypes with corresponding predefined specs that everyone in the organization is dictated to follow. These archetypes need to cover every aspect of the operational offering — if a task falls outside of the archetypes, it needs to be reviewed in order to either A) be permanently added, or B) the task needs to be eliminated. The criteria for permanently adding a task is that it was either 1) an oversight that led to its exclusion in the first place, or 2) it’s actually a better approach than another task, which then needs to be removed. The criteria for stopping a task from being performed is that the predefined archetypes already have a better task in place, in which case the better option should be used.

The archetypes themselves are composed of the workflow, the best practices, and the specifications. These three components can all be built into the already created checklists and supporting documentation in order to ensure they are correctly applied. As much as possible, these archetypes should have overlapping workflows and content — this will make it easier to draft, upkeep, and improve those components.

The primary benefit of The Archetype Rule is that it converts workflows to being compatible with our approach. Initially the implementation will quickly sweep the low hanging fruit into candidacy for the checklists and supporting documentation. However, as the rule holds steady, more complex workflows that were previously considered unique “works of art” will start converting to compatible with the Checklist and Supporting Documentation format.

An example of a workflow where this will take place is the removing redactions from produced documents and reproducing them. This workflow can have a variance at the tracking of redactions, to their removal, to their reproduction, and everything in between — I’ve sat and listened as two Project Managers explain that they weren’t doing the same thing because one PM had one markup set in Relativity and added a branding stating, “Document Reproduced”, while the other had multiple markup sets and a custom workflow to insert custom Bates prefixes — these two had seemingly disparate workflows, but if The Archetype Rule had been in place then both would have been able to achieve their desired end goal utilizing the same workflow.

Beyond just increasing the scope of the workflows that can be covered, this rule also ensures that the three previous intervention points aren’t undermined by poor governance:

• The improvements from the continuous improvement program built in Intervention 8: The strength of negative feedback loops, relative to the impacts they are trying to correct against are applicable to the workflows that the inputs come from — if there are multiple ways to remove redactions and then reproduce, and an error occurs in Version A, the fix developed will not automatically apply to Version B, which means version B has not been improved. This minimizes the impact of proactively fixing errors and weakens the continuous improvement program. This rule cements the efficacy of the continuous improvement program and eliminates this concern.
• Furthermore, the more workflows converted means greater adoption, which drives the benefits we explored in Intervention 7: The gain around driving positive feedback loops — the more teams using the checklists and supporting documentation, the more feedback into the continuous improvement program, which results in more improvements at a faster rate. If there are multiple workflows being used by different teams, the elimination of the usage of anything but the archetype workflows creates de facto adoption.
• Finally, Intervention 6: The structure of information flows is a time-consuming structure to implement. Allowing countless workflows to exist either makes the cost of creating and maintaining the structure itself cost prohibitive, or leads to rogue workflows existing outside of the structure. Once again, elimination of superfluous workflows through this rule resolves this potential issue.

While the overall case strategy might vary from case to case, there is no need for the execution of the eDiscovery workflows to vary. There may be many ways to execute a workflow but application of The Archetype Rule increases the scope of our program while simultaneously ensuring the success of the previous interventions.

The Surge Rule

I remember missing a production deadline during my project management days that felt all too preventable… It was a busy week and the quality control department had a few team members call in sick. They were working as hard as they could but they simply had too few people to finish all the work. After launching the production, I had no pressing deadlines and offered multiple times to help with the QC workload to free them up to make sure my production made it through. My offer was turned down multiple times and I had to sit by and watch idly as the deadline was missed. Ironically, as a PM I was expected to perform an additional QC after the QC team to double check their work — the skill set was available but a rule prevented it from becoming actionable. Which leads us to The Surge Rule.

The Surge Rule allows team members to help across departments during surges. Now, every department has it’s area of expertise that can be hard to replicate, and as a result walls are often constructed between departments to stop interdepartmental help from occurring. The rationale for this is a concern about team members from other departments not being able to perform the work due to a lack of onboarding; but lucky for us, we’ve already addressed this issue at Intervention 9: The lengths of delays relative to the rate of system change — because we created the checklists + supporting documentation designed to drastically reduce onboarding time, we can quickly staff up beyond a single department’s capacity by leveraging other departments.

Of course, the goal of The Surge Rule should not be to consistently help across departments, but instead to allow the capability as truly needed. Allowing teams to help across departments by leveraging checklists and supporting documentation frees up the opportunity to help with surges in workload. That being said, some tasks cannot be transferred for a variety of reasons — legal, permission limits, technical aptitude, and so on… still, having this rule in place before surges in workload comes into play forces a review and a real understanding of exactly who can help with what in which circumstances.

The Surge Rule expands the scope of available resources and as a result increases the impact of the interventions we have implemented to this point by creating a temporary increase in the available team members to perform a task. It’s a simple rule that doesn’t have much pizazz to it, but the solution it creates directly solves the issue of peaks and valleys in eDiscovery.

The Archetype Rule and The Surge Rule both increase the scope and impact of the previous interventions in different ways. Whereas The Archetype Rule expands our scope by limiting behavior, The Surge Rule expands our scope by removing limits on our behavior. This may make determining which rules to apply seem a little tricky, but a deliberate approach to driving behavior toward a specific goal can cement the strength of our approach at the same time that it continues to optimize it.

Next week we will look at Intervention 4: The power to add, change, evolve, or self-organize system structure and discover how diving deeper will reveal best practices for handling the approach we have built. This step will take us from merely creating an effective system, to creating something vastly more powerful: a learning system.