Welcome to Kraft Kennedy

So you’ve decided to add Enterprise Search to your firm’s ECM arsenal.  You should all be familiar with the many benefits of Enterprise Search:  search consolidation, knowledge management, and quick, global search results, resulting in improved productivity and efficiency of the work staff.  You should also all be familiar with the drawbacks:  cost and complexity.

Let’s leave those drawbacks out of the equation for now, and focus on what should be a benefit:  the ease of finding documents across the enterprise.   How could this be bad, you ask?  The Enterprise Search utilities are designed to respect the security of whatever system the content lives in.   That’s good, right?  Well, what if the documents aren’t secured in the source repository?   Some older systems make it inherently difficult to find documents with the native search interface/engine.  Since it may be difficult to find documents, users start to skip the step of securing documents.   Their thinking is, “Well, no one can find the document anyway, so why do I need to waste 45 seconds and add security to it?”.   These unsecured documents could be financial statements, HR documents, or any other content that should be secured.

Enter Enterprise Search. Once Enterprise Search is introduced, that open level of security would now be apparent to all users of the system.   This could cause headaches in the enterprise, and put a black-mark on the Enterprise Search tool — even if it’s not the Enterprise Search tool’s fault.   This is just one example of the implications of adding new ECM functionalities to an environment.   The security example here can be alleviated by scripting a security update to the source repository prior to the deployment of the Enterprise Search; essentially resolving the issue before it can become a security nightmare.

In my previous post, I discussed ways of bringing the legal user community into the matter centric design process. That’s only the first battle. Once attorneys are able to visualize the concept behind the organizational folders of a matter centric WorkSpace, they may want the structures to mimic what they are used to — especially if they’ve never used a DMS before. They may want to stay within their comfort zone. And these may be the most powerful voices in the Firm.

Usually, what they are used to is an inconsistent, multi-level directory structure with custom folders containing perhaps a handful of specifically categorized documents each. This kind of structure makes sense when the only way of finding a document is by knowing which folder it’s in — as is the case without a DMS. In this scenario, you wouldn’t want to scroll through hundreds or thousands of documents in a folder. Rather, if you can limit the number of documents in a folder to a handful, then it is easier to find the document you need. This is what leads to the numerous directory levels and (in my humble opinion) overly specific classifications.

In the DMS world, there are much better ways of finding documents. The obvious option is the full-text search, which will provide efficient results (given the user properly knows how to perform a full-text search). In addition to the search, folder lists can be sorted and filtered based on any metadata column, and the WorkSite Miner is a nice utility to carve up the contents of a folder into more manageable groups.

iManage offers two levels of classification for documents — the Class (which generally corresponds to a WorkSpace folder) and it’s child Subclass. As the designer of the WorkSpace structure and metadata, you may get requests for numerous Subclasses. There are two main disadvantages of using Subclasses. First, requiring the Subclass adds dreaded extra clicks and keystrokes to each save action. If the Firm decides on using Subclasses, it is a best practice to make them required. If they are optional, they lose all value. There’d be no guarantee that searching for the “Loan Agreement” Subclass will return all loan agreements. This leads to the second key disadvantage — it will prevent the proper update of metadata when dragging-and-dropping documents from one WorkSpace folder to another, since it is up to the user to select a Subclass when saving into a folder.

So how do we get attorneys to accept not using Subclasses? Make sure they grasp all the different ways documents can be identified, sorted, filtered, and found in the system. Perhaps bring up the idea of a naming convention for the description of documents. Or perhaps make a deal — try it without Subclasses for six months, and then the issue can be re-evaluated. Chances are they will appreciate the ease of simply saving into a WorkSpace folder, and agree that there is no need for Subclasses. After all, less is more.