Search results for: simple

In Part 1, we explored changing face of internet and intranet collaborative communication platforms and the increased risks posed by outdated policies and technologies. My main concern over these systems is the unreasonable expectation that a typical corporate custodian could preserve relevant ESI stored in Sharepoint or another cloud based system. Despite recent rulings emphasizing written Hold Notification, most users simply do not have the tech savvy, rights or proper tools to either make a complete preservation copy or secure the items in place against expiry or accidents. That shifts the onus back onto Legal to effectively preserve these dynamic data sources.

I believe a good argument can be made there is much similarity between operating a traveling circus and operating a small to mid-sized law firm. And much to be learned from the former by the latter.

In several recent posts, Barry and I have called out the challenges of collecting dynamic content from web based collaboration platforms, focusing on Sharepoint as the market leading platform. It is definitely on the minds of corporate legal departments and providers alike. Our articles prompted the team at Kiersted Systems to request a demo and briefing on their newest Sharepoint collection and review offering. Although we do not do classic product ‘reviews’ at eDiscoveryJournal, I do like to explore the implications of new methodologies and technologies. Sharepoint 2010 itself is new to the market and brings new capabilities to manage legal holds on records as well as more robust search and export features. The new ability to make a ‘preservation copy’ within Sharepoint is probably the highlight feature to take note of. They have wrapped a bit more workflow and specific action templates around holds, search and export, but the basic item level functionality seems unchanged.

I had a chance to speak with Lance Sloves, a Director at Computer Forensic Services, Inc. about forensic collection. He points out that, first, it’s fairly rare for any organization to have well-rounded or proper policies and processes in place for good, defensible collection – that is just the way it is. Second, few organizations possess the expertise in proper data and forensic collection that is required in today’s eDiscovery market. The fact is that many litigators are getting smarter and smarter about collection – and some can smell blood when something has not been properly vetted. And I’ve yet to meet an IT manager who relishes the thought of being an expert witness.

In Part 1, I outlined the typical litigation profile questions that would support a realistic needs assessment for a solo attorney or small firm. From a the set of requirements, we explored the basic software packages through the EDRM lifecycle while calling out small firm perspectives. In the intervening weeks, I have tried to track down and get hands on new applications and SaaS offerings that might meet my challenge criteria. The nice folks at QD Documents got me a trial license for their $500 package. The product definitely gives a solo attorney the basic organizational space to code in documents, exhibits, transcripts, filings and all the other working pieces of a matter. Unfortunately, it is really just a nice, clean document tracking and management space, rather than an eDiscovery processing platform. I suppose that you could put URL links in field for native files, but that just feels too much like Concordance. So a good, cost-effective case management tool, but not an answer to my challenge.

On the heels of my writing about the perfect storm brewing in eDiscovery comes good news for all in the market. Recent survey results from the Cowen Group indicate a rise in jobs, plans to purchase software, and plans to purchase outsourced services. The good news is that the data points to wins all around in the market. Organizations benefit by taking proactive steps to reduce the cost of eDiscovery. Software and service providers benefit from increased revenue. And eDiscovery professionals benefit from increased work options and better employment.

During a recent software testing engagement, I ran into an interesting issue with date based searches that could impact your discovery search results. The root of the issue is based in the different ways of representing communication attachments or other multipart items such as Sharepoint/wiki page attachments. In the dark ages of eDiscovery, our software was designed to simulate the myriad physical attachment levels of scanned paper documents. I am not ashamed to recall coding levels of staple, clip and binder groupings back in IPRO ver. 1.5. The system enabled an attorney to determine the exact hierarchical relationship of that individual document to all the others scanned from that box retrieved from Iron Mountain. Newcomers to our field cannot imagine the labor required to manually code in Author, Recipients, Subject and other fields that are now extracted from ESI during processing.

The management and review of native files (ESI) generally requires the extraction of internal/external metadata and the readable text to be indexed for search. Most types of container or multipart files such as ZIP or PST containers must be broken out into individual files for this step and subsequent productions. This is the foundation of what our industry calls Processing. Most counsel, corporate IT and judiciary seem to operate under a presumption of magical perfection in these software and services of specialized eDiscovery providers. Most of these ‘built for purpose’ applications manage to avoid the basic MS Windows issues that drop or alter date fields, but the infinite variables associated with ESI formats and contents make it nearly impossible for any system to automatically get everything right, even if we could agree on what ‘right’ is. Although I had heard about Planet Data’s acquisition of the Cerulean Engine™, the time at the AIIM 360 Expo gave me an opportunity to understand the deep processing experience that accompanied the software.

My first article on corporate data collections focused on preserving the content, container and context of native files as found on network shares and desktop folders. Discovery requests are increasingly targeting email archives, content management systems and other semi-structured data sources. Most of these sources include search and retrieval features, so one could assume that this makes them a safer candidate for in-house collections. This is not automatically true and is definitely worth talking through some of the common problems that can lead to incomplete or altered retrievals. The first thing to realize is that these systems were not designed to comply with legal discovery requests as found in the United States. The search and retrieval functionality was added to support a business user seeking to find a few specific email or an IT administrator restoring a larger set of items that were either lost or need to be transferred to a new user. Both of these scenarios stress quick, simple search without needing to verify the accuracy or integrity of the search or restoration.

I spent the better part of this past week at the EDRM kickoff meeting in St. Paul, MN. For those of you that aren’t familiar with it, EDRM stands for electronic discovery reference model. The goal of EDRM is to “develop guidelines and standards for e-discovery consumers and providers…helping e-discovery consumers and providers reduce the cost, time and manual work associated with e-discovery.” A lot of great thought leadership has emerged from EDRM, including the well-accepted reference model that provides insight into all the activities that need to happen during eDiscovery.