Garbage In and Garbage Out: The Importance of Source Data When Categorizing Matters

When working with a database driven application, engineers are often asked to automate certain tasks based on information from another data source. A common example that our clients see is pulling metadata about clients and matters from an accounting system, and using that information to drive matter-centric folder structures in HP WorkSite iManage.

Queries could be run against matters in the source database, and all sorts of information can be retrieved, such as:

With this kind of information and third-party tools, you can do all sorts of automation and customization to the matter-centric environment to make the system more efficient.  You can update already existing workspaces in iManage with changes to matter descriptions from the accounting system. You can automate the creation of specific sets of workspace folders based on the Practice Area. You can publish workspaces for an attorney’s recently billed matters to their My Matters area, or you can publish workspaces for any matter listing the attorney as the “originating attorney”.

This all sounds well-and-good and is straightforward with the right tool. However, the process relies on data within the accounting system and if the data is wrong there, users are going to see unexpected results. Here are a few common tickets and questions you may see trickling into your Helpdesk queue:

Many times it is best to trace the information back to the source — and I don’t mean the database. Where did the data really come from? Usually that involves some sort of Matter Intake Form. This form typically has fields and choices to identify the appropriate practice group and attorney for the matter.  In some environments, the Practice Group is driven by whoever the Originating Attorney is. In other environments, these two can be two completely separate choices. The key is understanding how this data is entered and ensuring that it is accurate. Sometimes attorneys are designated to the wrong Practice Group. It happens. Maybe there was an accounting upgrade or data restructuring that caused several thousand matters to be classified with the wrong department or practice code.  Sometimes attorneys are creating documents for matters that are closed in the accounting system — now that the matter status can be synched, maybe that matter is now disabled in iManage.  These sorts of data errors are often invisible to the end user — until, that is, it is shoved in front of their face due to some automation script or third-party tool.

We can do many things to make iManage and other DMS systems more efficient, automated, and customized.  But we are only as good as the data that is provided to us. Keep this in mind when planning a new integration or automation task into your environment. Make sure that everybody knows where the data is coming from and try to run some validation queries and send the results to responsible stakeholders.

One possible solution is to divorce the practice group from the workspace folders, and go with a much more general approach to the folder design: Emails, Drafts, Final Documents. Who could argue with that? Other solutions, such as Prosperoware Milan, can allow users to pick from a predefined list of optional folders that can be used to customize a structure on a per-matter basis.

This may be a great time to review the matter intake process with key stakeholders engaged in the strategy of the firm, and perhaps suggest changes that can more accurately define information on each new matter as it is created. Discussions could include how and why matters are currently categorized. Are matters categorized to ease the organization of attorneys, the assigning of work, or for marketing and reporting efforts?  How often are your current matter types being used, and are there some that can be consolidated to make the ongoing management of them easier. This may involve surveying representatives from each practice group.

These are just a few of the potential issues we have seen when integrating accounting data to the DMS. However, these sorts of problems can occur with any automation script that ties two different systems together.