Perhaps you've realized that keeping your case information in notepads and Word documents isn't a good idea. You've seen how hard it is to search, filter, and collaborate with these tools, and you want something more structured — because you understand that structuring your case is the key to mastering it and doing your best job for the client. You may be tempted to use software you already own (Excel, MS Acess), heavily discounted software that enables you to pay later (AirTable), or free software (Google Sheets) for managing cases. Before you do so, read on.

Spreadsheets

Spreadsheets are extremely useful to attorneys (we've written about their utility in litigation before), but they fall short as tools for tracking what happened in a case and how you're going to prove it. The main problem with spreadsheets, in this context, is they are generally not relational. For a data system to be "relational," it must be possible to connect certain kinds of records, such as facts, to other kinds of records, such as contacts or legal issues. In contrast with a relational data store, a spreadsheet stores information in a "flat" manner.

The disadvantage of flat data is that you're typically forced to refer to other entities by name only. For example, you can only indicate that a fact is related to the issue of causation by writing the word "Causation" in an "Issues" column. This works fine for one fact, but when you have 200 facts and need to filter to see only those that relate to causation, you'll be in trouble.

You'll also have difficulties if you ever need to change the name of an issue. You'll have search through and find every place it is written and update it. Finally, (and this will be covered in more detail later) you'll be missing out on the benefits a streamlined interface targeted to fact creation and other "power" features offered by a purpose-built solution.

Homemade Databases

With so much tech available for so many purposes, some lawyers opt to build their own fact-management systems using a relational database. The most common tools for this are Microsoft Access and a web-based program called AirTable, but there are many other tools that serve this purpose as well.

The good news about these options is that is is possible to use them — albeit with some difficulty — for creating a relational database that tracks case facts. Unfortunately, there's a lot of downsides, too.

First, you have to figure the data model. Some programs facilitate sharing database templates, but most of the templates we've seen model the data incorrectly. The most common flaw in data modeling deals with the way facts are related to evidence. The naive way of linking a fact to a piece of evidence is through a simply many-to-many relationship: a fact can be related to many items of evidence, and an item of evidence can be related to many facts. In this case, it's critical for the data model to allow users to record how items of evidence relates to facts, and specifically which page of a source of documentary evidence proves the fact in question.

Documents with hundreds of pages are often linked as evidence for facts. Knowing that such a document proves a fact without knowing which page to turn to will leave you in the lurch when you're impeaching a witness, drafting a brief, or preparing for a hearing or trial.

Second, you won't have a fluid interface for entering facts. Your primary difficulty will consist of creating the relationships that are the lifeblood of your chronology. You'll need to link each fact to the the correct contacts, issues, and documents that it relates to. For each document (if you've modeled the database properly) you'll also want to record page numbers.

Best-case, you'll have to do a lot of pointing, clicking, and typing to create the relationships. Even with the best-designed interface, creating links between documents and facts that also include page numbers will likely be extremely tedious. In the worst-case scenario, you'll have to enter values called "foreign keys" for the related records — and you'll either need a cheat sheet or a very good memory to keep up with your list of foreign keys.

Third, you'll be unable to create facts directly from documents in your case. In Timelines, we have a feature called Highlights, that enables users to upload multiple documents, open them within a browser, and create facts that are directly tied to the specific sections of the document that the user highlights. This feature is an immense time saver because it helps users create facts at the same time they are reviewing documents in a case. Unifying the document review and chronology building processs helps you be more thoroughly prepared and confident you've extracted all the necessary information from each document.

Fourth, your reporting isn't tailored for legal. While some programs enable exporting data to CSV, Excel, or PDF, I'm not aware of any that export data in MS Word format. Why create a database if you can't get your data back out in the exactly format you want. A chronology with well-defined relationships to contacts, legal issues, and evidence has all of the ingredients needed for creating very useful work product, such as statements of fact, pleadings, deposition outlines, and memos.

If you've tried one of the above options and experienced any of these frustrations, leave us a note in the comments below. If you're looking for a solution built for lawyers, try out Timelines for free.