THE UNNATURAL “NATURE OF THE INDUSTRY”, PART 3
In our last post we reviewed positive and negative feedback loops via intervention points 7 and 8 of the 12 Intervention Points in a System in order to unearth how to further augment our approach in regards to resolving the issues around the peaks and valleys that haunt the eDiscovery industry.
In this post, we will continue our deep dive into the intervention points by reviewing the Intervention 6: The structure of information flows.
We’ve made some serious progress over the last several intervention points. 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 to eliminate errors during onboarding. At Intervention 7: The gain around driving positive feedback loops, we identified how to kickstart the positive feedback loop in a desirable direction. And now, at Intervention 6: The structure of information flows, we will explore how to modify the structure of the approach in order to optimize how information flows in an organization.
6. The structure of information flows
The checklists and supporting documentation, the continuous improvement program, and the push for adoption of the approach can all be made or broken by one thing: the structure of information flows. If the checklists and documentation are confusing, then they won’t be properly used; if the inputs to the continuous improvement program are lost or unclear, the signal sent to fix the error gets lost or misdirects; if the approach is hard to adopt it will lose steam and potentially reverse course and be dropped. Thus, it is imperative that we properly structure the information flows in order to not only prevent these issues, but also strengthen the approach.
The starting point of our structure is the checklist. It needs to be a clean and clear summary of every step that goes into the process it outlines. No steps can be assumed to be known and every step needs to be its own entity. If you find an “and” in the sentence describing a step, it should be split into two steps — this avoids a team member from being disrupted in the middle of the workflow and forgetting to go back and finish the part after the “and”, as well as allows for another team member to take over a workflow and not have to worry if the previous step made it past the “and” part of the step or not. This is also important because at Intervention 8: The strength of negative feedback loops, relative to the impacts they are trying to correct against, we built a continuous improvement program that relies on logging errors in order to identify trends and patterns to signal a fix. If one of the inputs is a combined step then the analysis becomes unclear on whether it was part a or part b of the step. This lack of clarity weakens the strength of the continuous improvement program.
Each step in the checklist also needs to have a location for indicating whether or not the step was finished and who finished it. Tracking who finished each step helps in two ways: the first is that if a question comes up during the performance of a workflow, it’s easy to quickly identify who performed which part of the workflow and thus to interact with the source of the work in question; the second is related to the continuous improvement program: by including who performed the step and where the error occurred provides an input that makes analysis simple — if multiple team members make an error at the same step, the step needs to be updated; but if one team member repeatedly makes an error at the same step, it uncovers a training opportunity for that team member. Simply switching the structure from a checkbox to entering a name provides an information flow that augments the continuous improvement program.
With the checklists designed, it’s time to turn to the supporting documentation. The most common mistake when creating this kind of documentation is to cram all of the information regarding a workflow into a single document. Because here’s the thing — if I am on Step 7 of a workflow I don’t want to read Steps 1–6 in order to get my job done, I just want to read Step 7. There are ways to manipulate the format of a document to make it easier to navigate, but why bother when there is a simpler way? Instead, every step should have its own document. This makes it easier to identify exactly the relevant information to what you are doing, and it’s easier for the editor who is making the updates to eliminate errors as identified by the continuous improvement program.
Each checklist step having its own supporting documentation also provides another valuable opportunity: a chance to apply Just-in-time learning. By integrating the supporting documentation into each step, a team member has the relevant information for the step they are working on immediately at their fingertips, in the moment they need it. However, it’s good to note that we do not want to add the information from the documentation into the checklist itself, as doing so will clutter up the checklist and make it more difficult to navigate. Instead, we can maintain clean and clear digital checklists by providing a link or button in the checklist that will take the user to each step’s respective supporting documentation.
Additional to all of the above organizational awesomeness, there is one more component we can add to this design in order to help with the flow of information: any time a step is updated, we dictate that that step is highlighted in the checklist in order to notify every user that the best practices for that step has changed and they need to read the updated supporting documentation before proceeding. This simple addition removes the need for time-consuming trainings or the risk that someone misses and update via an email notification. Simply, highlighting a changed step ensures that the work done by the continuous improvement program is applied.
And, before we call it a day, one final note: all of the checklists and supporting documentation need to be stored in a centralized location. From the user’s perspective, this eliminates the annoying wild goose chase of searching across multiple locations for pertinent information. But more importantly, it maintains version controlling — if multiple versions of a checklist for the same workflow exist, then the continuous improvement program falls apart. If checklist A is updated but a team member is still using checklist B, then they are at risk of making the error that was supposed to be eliminated by the continuous improvement program. And then it all goes to hell.
So there you have it. By taking these proposed steps we can design a structure of information flow that makes our checklists and documentation easy to use, easy to adopt, and optimizes the continuous improvement program that makes things better all of the time. And likewise, failure to take into account these factors will undermine all of the hard work we have done to this point in our efforts to eliminate errors and alleviate eDiscovery staffing woes.
We’ve made it halfway through the intervention points with considerable progress. But we can still go deeper! Tune in next time to see how we can leverage Intervention 5: The rules of the system, to further address the issues that come with eDiscovery’s peaks and valleys.
