Here are my comments on the “ 10 Steps”:
First of all, where are some of the new prerequisites in this piece for effective enterprise litigation? Put an “effective” in front of all of these…
- Metadata Repository
- Enterprise Architecture
- Enterprise Search/Index
- Identity Management
- Content Architecture Standards
- Integration Services
- Role based Retention Schedules
- Enterprise Process Management
These requisites are essential to defending a lawsuit in court. Imagine investigating a crime, but not knowing how to drive or read a road map, you wouldn’t even know what type of crime occurred? Are the above not included because they haven’t been developed yet into the toolset? Or, because they are “too technical” for the readers? Or, not focused enough on litigation? I hope not. For example, eDiscovery products assume a great deal is working effectively with the above technology areas. Tell me one company that has IT running all of these initiative flawlessly…
Second, the big bucket, then smaller buckets approach is not addressed here because it negates a lot of the need to create an inventory, automate retentions and dispositions at a detailed level. If you don’t need to tag and control all of the insects in the jungle, then why would you need our tools? If you could start with a big bucket compliance policy and slowly identify and weed out the more sensitive content wouldn’t that make more sense? When you see an ant in your kitchen do you have to identify it to decide whether you are going to step on it?
Datamap: to make legal search easy, determine data source, figure out the who, what and why of content. This is all good, but needs a few more details of potential pitfalls to round it out. One huge issue is the legal department itself. Legal wants the map, but also has to make sure that vendor and the software being used is vetted out. This means that the process of getting approval to actually use the tools might take a lot longer than anticipated. Having an effective enterprise metadata repository, architecture and index/search in place would greatly benefit the datamap effort. And vice versa, the datamap would open the eyes of IT to the needs for enterprise level processes and frameworks.
In step 9, Reed mentions having a flexible process which is spot on, but there is no discussion of historical analysis of the data and process in order to develop a framework for change. It’s not enough to say there will be a periodic audit of the map and processes, you have to know what to expect based on the company’s cultural changes in the past, present, and future.
Step 2 is a good start but needs to be tested with scenarios. These scenarios are just as important as the policies. Using a Zachman framework may help with figuring out the details of the whens which are not covered here. In other words, what is the roadmap of this readiness? What are the different ways to roll this out? Also, access control policies and identity management are components of the policies which are usually left for the IT department to figure out, but should be detailed up front.
Getting buy in and executive support for Step 3 is right on. This is absolutely necessary and should be step one. However, the legal department as a sponsor may not have the clout needed to push all of the agenda through the organization, secondary buy in from governance groups would also be necessary. What would help tremendously is a previous litigation or a few drills that permeate through the whole company and highlight the need to get the house in order and more importantly save in huge costs associated with manual labor.
Step 4 and Step 7 are at odds with one another. On the one hand, know your users and on the other take them out of the process. Adding Step 6 (automating the process) here, what needs to happen is development of an automated process for preservation and disposition which is seamless to end users, but is very clearly understood and vetted by end users. One way of doing this is to create a pit stop mechanism which implements these policies at the integration level not the UI level. Also, if there’s an IT compliance department in your company then why not drop the process of applying retention there and add it to the other steps to adding storage to applications. A business partner within an enterprise has to justify adding storage and why not add it step to detail the retention schedule for the integration service?
Step 5, Build your team, should be a framework of roles not the actual team members which will form and disperse depending on the type of suit against the company. The in-house IT folks will need to shift priorities and delay other projects. This could create a wave of ramifications through the interrelated projects that are in progress.
The bottom line is that no one product suite or solution can possibly handle the myriad of issues involved with eDiscovery. The best case would be to develop scenario based approaches and frameworks with the knowledge that a hybrid solution will inevitably be developed. A comprehensive datamap could take years and is really an exercise in futility. The prerequisites listed above are necessary to get to the point where a map will make sense. The map will have to be a framework more than a blue print—the exact specifications will change based on the litigation at hand. Building integration services that regulate retention policies and control content processing will make dealing with the human intervention factor more straight forward and less of a burden on “repeatable” processes. Building and morphing a set of litigation scenarios all honing your processes to these will go a lot farther than buying one-size-fits-all software solutions. This may be where EMC’s Case Management and Microsoft’s Sharepoint projects collide into interesting hybrid (mashup) solutions.